Seguí notando que @Dusk no fuerza que cada transacción pase por un solo modelo.

Moonlight usa una estructura basada en cuentas, mientras que Phoenix toma un enfoque UTXO. Al principio, eso parece una complejidad innecesaria. ¿Por qué mantener dos formas de representar transacciones en lugar de elegir una y mantener la arquitectura más simple?

Cuanto más lo miraba, más sentido tenía esa separación. El estado basado en cuentas es directo para los saldos y la lógica de la aplicación. Phoenix le da a Dusk una estructura de transacciones diferente que puede soportar flujos más orientados a la privacidad.

Esa flexibilidad es útil.

Pero hay un costo que no creo que se discuta lo suficiente. Cada modelo adicional de transacción agrega otro modelo mental para que desarrolladores y usuarios lo comprendan. La arquitectura puede volverse más capaz mientras que el sistema, en general, se vuelve más difícil de razonar.

Entonces, ¿tener modelos de transacciones distintos realmente le compra a Dusk una flexibilidad útil, o la complejidad extra eventualmente supera el beneficio?

#dusk @Dusk $DUSK