#dusk $DUSK
@Dusk_Foundation antes yo asumía que una cadena de privacidad significaba que cada transacción quedaba protegida de forma predeterminada, sin excepciones.
luego leí lo que Moonlight realmente hace en Dusk.
Dusk ejecuta dos modelos nativos de transacciones en la misma capa de liquidación. Moonlight es basado en cuenta, público: el remitente, el destinatario y el monto se ven. Phoenix es basado en notas: está protegido; los fondos se mantienen como notas cifradas en lugar de un saldo en funcionamiento, más cerca de unidades gastables que de un total por cuenta. #dusk
esa es la “de forma predeterminada” que cambió la manera en que leí esto, y volví a releer esa sección dos veces solo para estar seguro.
una sola transferencia elige uno u otro modelo, nunca una mezcla. envía DUSK por Moonlight y es totalmente transparente, diseñado para flujos que necesitan seguir siendo observables; algún escenario de tesorería o de informes es el tipo de ejemplo al que apuntan los documentos. envíalo por Phoenix y el monto, el remitente y qué notas específicas se movieron permanecen ocultos; se comprueba que es correcto mediante pruebas de conocimiento cero en lugar de mostrarse de forma explícita, aunque una clave de visualización puede revelar esos mismos datos ocultos a quien el validador decida mostrárselos. $DUSK
un solo contrato de transferencia gestiona ambos: enruta cada carga útil a la lógica de verificación adecuada, manteniendo el estado global consistente en cualquier caso.
así que la privacidad aquí tampoco es binaria a nivel de protocolo; es una elección por transferencia, y hasta la opción protegida tiene una forma documentada de volver a hacerse visible si se solicita.
esa elección recae en el remitente, no en el protocolo.
en cambio, ¿dar a los usuarios una opción pública socava el discurso de privacidad, o una privacidad opcional y revocable es en realidad el diseño más honesto para mercados regulados?
¿la privacidad opcional sigue siendo privacidad?
@Dusk_Foundation antes yo asumía que una cadena de privacidad significaba que cada transacción quedaba protegida de forma predeterminada, sin excepciones.
luego leí lo que Moonlight realmente hace en Dusk.
Dusk ejecuta dos modelos nativos de transacciones en la misma capa de liquidación. Moonlight es basado en cuenta, público: el remitente, el destinatario y el monto se ven. Phoenix es basado en notas: está protegido; los fondos se mantienen como notas cifradas en lugar de un saldo en funcionamiento, más cerca de unidades gastables que de un total por cuenta. #dusk
esa es la “de forma predeterminada” que cambió la manera en que leí esto, y volví a releer esa sección dos veces solo para estar seguro.
una sola transferencia elige uno u otro modelo, nunca una mezcla. envía DUSK por Moonlight y es totalmente transparente, diseñado para flujos que necesitan seguir siendo observables; algún escenario de tesorería o de informes es el tipo de ejemplo al que apuntan los documentos. envíalo por Phoenix y el monto, el remitente y qué notas específicas se movieron permanecen ocultos; se comprueba que es correcto mediante pruebas de conocimiento cero en lugar de mostrarse de forma explícita, aunque una clave de visualización puede revelar esos mismos datos ocultos a quien el validador decida mostrárselos. $DUSK
un solo contrato de transferencia gestiona ambos: enruta cada carga útil a la lógica de verificación adecuada, manteniendo el estado global consistente en cualquier caso.
así que la privacidad aquí tampoco es binaria a nivel de protocolo; es una elección por transferencia, y hasta la opción protegida tiene una forma documentada de volver a hacerse visible si se solicita.
esa elección recae en el remitente, no en el protocolo.
en cambio, ¿dar a los usuarios una opción pública socava el discurso de privacidad, o una privacidad opcional y revocable es en realidad el diseño más honesto para mercados regulados?
¿la privacidad opcional sigue siendo privacidad?