#dusk $DUSK @Dusk Al principio asumí que una blockchain de privacidad debería ocultarlo todo. Mientras estudiaba Dusk, me di cuenta de que quizá esa era realmente la pregunta de diseño equivocada.
La mejor pregunta es: ¿qué partes de una transacción financiera deben permanecer visibles?
Dusk separa esos requisitos. Moonlight admite transacciones transparentes basadas en cuentas, mientras que Phoenix usa notas protegidas y pruebas de conocimiento cero para ocultar los detalles de la transacción a la vez que demuestra la validez. Ambos modelos se liquidan a través de DuskDS.
Eso crea una dependencia interesante.
Las aplicaciones financieras pueden necesitar confidencialidad para posiciones sensibles, pero los reguladores o las contrapartes aún pueden exigir información específica. Por eso, Dusk aborda la privacidad como divulgación controlada, más que como secreto permanente.
Creo que ahí es donde la arquitectura se vuelve interesante.
La criptografía puede proteger los datos protegidos, pero no puede decidir si una aplicación eligió el modelo de transacción correcto o si reveló información de forma accidental a través de su lógica circundante.
Así que la limitación no es necesariamente el propio mecanismo de privacidad. Es la complejidad de gestionar la visibilidad correctamente.
Dusk acierta en algo importante: la privacidad no tiene que ser todo o nada.
La pregunta que estoy observando ahora es más sencilla:
¿Pueden los desarrolladores controlar de manera consistente qué se vuelve visible, para quién y bajo qué condiciones? $DUSK
La mejor pregunta es: ¿qué partes de una transacción financiera deben permanecer visibles?
Dusk separa esos requisitos. Moonlight admite transacciones transparentes basadas en cuentas, mientras que Phoenix usa notas protegidas y pruebas de conocimiento cero para ocultar los detalles de la transacción a la vez que demuestra la validez. Ambos modelos se liquidan a través de DuskDS.
Eso crea una dependencia interesante.
Las aplicaciones financieras pueden necesitar confidencialidad para posiciones sensibles, pero los reguladores o las contrapartes aún pueden exigir información específica. Por eso, Dusk aborda la privacidad como divulgación controlada, más que como secreto permanente.
Creo que ahí es donde la arquitectura se vuelve interesante.
La criptografía puede proteger los datos protegidos, pero no puede decidir si una aplicación eligió el modelo de transacción correcto o si reveló información de forma accidental a través de su lógica circundante.
Así que la limitación no es necesariamente el propio mecanismo de privacidad. Es la complejidad de gestionar la visibilidad correctamente.
Dusk acierta en algo importante: la privacidad no tiene que ser todo o nada.
La pregunta que estoy observando ahora es más sencilla:
¿Pueden los desarrolladores controlar de manera consistente qué se vuelve visible, para quién y bajo qué condiciones? $DUSK
