¿Por qué Dusk mantiene deliberadamente las transacciones públicas?
Una red orientada a la privacidad que deliberadamente mantiene un modelo de transacciones transparente suena a una contradicción. DuskDS hace exactamente eso. Moonlight utiliza saldos públicos basados en cuentas; Phoenix utiliza transferencias protegidas basadas en notas con pruebas de conocimiento cero. Ambas, en última instancia, se liquidan en la misma cadena de Dusk.
Ese diseño sugiere una visión distinta de la privacidad: no un interruptor a nivel de toda la cadena, sino una elección a nivel de transacción. Moonlight encaja en flujos donde los saldos y las transferencias deben ser observables. Phoenix oculta los valores transferidos y los participantes, mientras sigue demostrando que el gasto es válido.
La clave es el contrato Transfer. En el nivel de DuskDS, acepta cargas útiles tanto de estilo Moonlight como de Phoenix, las enruta hacia la lógica de verificación correspondiente y mantiene el estado global consistente. Por eso, Dusk no necesita un sistema de liquidación separado cada vez que cambia el requisito de visibilidad.
La implicación de segundo orden es que la transparencia se convierte en una capacidad intencional, no en un fallo de privacidad. Las propias carteras de Dusk admiten tanto DUSK público como protegido, de modo que la arquitectura puede exponer información cuando sea útil la observabilidad y protegerla cuando no sea necesaria una divulgación amplia.
Esto replantea el debate habitual sobre cadenas de privacidad. La mejor pregunta no es “¿Cuánto puede ocultar Dusk?”, sino “¿Qué información debería revelar un flujo financiero, a quién, y en qué capa?”. Para mercados regulados, poder elegir el modelo de visibilidad sin abandonar la misma base de liquidación puede importar más que maximizar el secreto en todas partes.
@Dusk $DUSK #dusk $BTW $MAGMA
Una red orientada a la privacidad que deliberadamente mantiene un modelo de transacciones transparente suena a una contradicción. DuskDS hace exactamente eso. Moonlight utiliza saldos públicos basados en cuentas; Phoenix utiliza transferencias protegidas basadas en notas con pruebas de conocimiento cero. Ambas, en última instancia, se liquidan en la misma cadena de Dusk.
Ese diseño sugiere una visión distinta de la privacidad: no un interruptor a nivel de toda la cadena, sino una elección a nivel de transacción. Moonlight encaja en flujos donde los saldos y las transferencias deben ser observables. Phoenix oculta los valores transferidos y los participantes, mientras sigue demostrando que el gasto es válido.
La clave es el contrato Transfer. En el nivel de DuskDS, acepta cargas útiles tanto de estilo Moonlight como de Phoenix, las enruta hacia la lógica de verificación correspondiente y mantiene el estado global consistente. Por eso, Dusk no necesita un sistema de liquidación separado cada vez que cambia el requisito de visibilidad.
La implicación de segundo orden es que la transparencia se convierte en una capacidad intencional, no en un fallo de privacidad. Las propias carteras de Dusk admiten tanto DUSK público como protegido, de modo que la arquitectura puede exponer información cuando sea útil la observabilidad y protegerla cuando no sea necesaria una divulgación amplia.
Esto replantea el debate habitual sobre cadenas de privacidad. La mejor pregunta no es “¿Cuánto puede ocultar Dusk?”, sino “¿Qué información debería revelar un flujo financiero, a quién, y en qué capa?”. Para mercados regulados, poder elegir el modelo de visibilidad sin abandonar la misma base de liquidación puede importar más que maximizar el secreto en todas partes.
@Dusk $DUSK #dusk $BTW $MAGMA
