#dusk $DUSK @Dusk
Mi papá llevó dos libros contables separados durante años para su pequeño negocio: uno para las ventas en efectivo y otro para las cuentas de crédito. Una vez le pregunté por qué no los combinaba. Me dijo que el efectivo necesitaba ser simple e inmediato, que el crédito necesitaba llevar el control de los plazos y los seguimientos, y que obligar a un solo sistema a hacer ambas cosas lo empeoraría en cualquiera de los dos trabajos.
Yo asumí que Dusk eventualmente convergería en un solo modelo de transacciones, como la mayoría de las cadenas que terminan adoptando un único enfoque. Esa suposición se derrumbó cuando en realidad rastreé por qué existen Moonlight y Phoenix.
Moonlight es basado en cuentas, público y directo: la documentación de Dusk lo describe como el modelo para los saldos y la lógica de aplicación que no necesita protecciones. Phoenix usa el enfoque UTXO, y existe específicamente para respaldar flujos orientados a la privacidad: transferencias blindadas, divulgación selectiva, las piezas que la finanza regulada realmente necesita cuando no se acepta la transparencia total.
Fusionarlos en un solo modelo significaría o forzar que cada transacción pase por una carga de privacidad innecesaria, o eliminar las opciones de blindaje para todos los que las necesitan.
La prueba real para DUSK es si mantener ambos modelos realmente sirve a los creadores que necesitan garantías distintas para flujos diferentes, en lugar de solo añadir complejidad conceptual que la mayoría de los usuarios nunca toca.
Lo que no he encontrado documentado en ningún lado es con qué frecuencia una aplicación única realmente necesita ambos modelos simultáneamente en la práctica.
Mi papá llevó dos libros contables separados durante años para su pequeño negocio: uno para las ventas en efectivo y otro para las cuentas de crédito. Una vez le pregunté por qué no los combinaba. Me dijo que el efectivo necesitaba ser simple e inmediato, que el crédito necesitaba llevar el control de los plazos y los seguimientos, y que obligar a un solo sistema a hacer ambas cosas lo empeoraría en cualquiera de los dos trabajos.
Yo asumí que Dusk eventualmente convergería en un solo modelo de transacciones, como la mayoría de las cadenas que terminan adoptando un único enfoque. Esa suposición se derrumbó cuando en realidad rastreé por qué existen Moonlight y Phoenix.
Moonlight es basado en cuentas, público y directo: la documentación de Dusk lo describe como el modelo para los saldos y la lógica de aplicación que no necesita protecciones. Phoenix usa el enfoque UTXO, y existe específicamente para respaldar flujos orientados a la privacidad: transferencias blindadas, divulgación selectiva, las piezas que la finanza regulada realmente necesita cuando no se acepta la transparencia total.
Fusionarlos en un solo modelo significaría o forzar que cada transacción pase por una carga de privacidad innecesaria, o eliminar las opciones de blindaje para todos los que las necesitan.
La prueba real para DUSK es si mantener ambos modelos realmente sirve a los creadores que necesitan garantías distintas para flujos diferentes, en lugar de solo añadir complejidad conceptual que la mayoría de los usuarios nunca toca.
Lo que no he encontrado documentado en ningún lado es con qué frecuencia una aplicación única realmente necesita ambos modelos simultáneamente en la práctica.
Genuinely useful split
67%
Unnecessary overhead
33%
3 Votos • Votación cerrada