#dusk $DUSK
Al modelar transacciones de @Dusk , siempre tuve una duda:
Si Phoenix puede ocultar sender, receiver y amount, ¿por qué todavía conservar Moonlight, que es completamente público?
Siguiendo leyendo la documentación de integración, la respuesta es bastante realista.
Hay escenarios en los que se necesita que sea público.
Por ejemplo, cuando un exchange cobra DUSK.
Necesita escanear los depósitos que ya están finalizados, saber cuánto y qué cuenta depositó, y además hacer coincidir el registro on-chain con su ledger de custodia.
En ese caso, el account model de Moonlight resulta incluso más sencillo.
Phoenix sigue otra lógica. Los fondos existen como shielded notes y, mediante una prueba ZK, se demuestra que la entrada es válida y que no hay double spend; no hace falta mostrar en el navegador para todos a las partes de la transacción ni los montos.
Ambos modelos al final se gestionan en DuskDS, pero no resuelven el mismo tipo de necesidad.
Este detalle cambió bastante mi forma de ver el diseño de privacidad de Dusk.
Antes pensaba:
Cuanta más privacidad, mejor.
Ahora ya no lo veo así.
En los sistemas financieros, lo público tiene usos propios, y la privacidad también tiene sus propios usos. Para la conciliación de depósitos, la transparencia es necesaria; pero para transferencias normales o flujos de fondos sensibles, tal vez no haya razones para que queden permanentemente públicos.
Aún más interesante: la Dusk Wallet, por sí misma, también admite la conversión entre Moonlight y Phoenix.
Así que no está obligando al usuario a elegir bandos.
Cuando se necesita que sea público, se usa Moonlight; cuando se trata de un flujo shielded, se entra en Phoenix.
Ahora más bien siento que conservar estos dos modelos a la vez es más práctico que forzar que todas las transacciones se metan en la etiqueta de “privacidad”.
Lo “público” aquí no significa que la privacidad no esté bien hecha, sino que es una funcionalidad que se conserva de manera deliberada.
Al modelar transacciones de @Dusk , siempre tuve una duda:
Si Phoenix puede ocultar sender, receiver y amount, ¿por qué todavía conservar Moonlight, que es completamente público?
Siguiendo leyendo la documentación de integración, la respuesta es bastante realista.
Hay escenarios en los que se necesita que sea público.
Por ejemplo, cuando un exchange cobra DUSK.
Necesita escanear los depósitos que ya están finalizados, saber cuánto y qué cuenta depositó, y además hacer coincidir el registro on-chain con su ledger de custodia.
En ese caso, el account model de Moonlight resulta incluso más sencillo.
Phoenix sigue otra lógica. Los fondos existen como shielded notes y, mediante una prueba ZK, se demuestra que la entrada es válida y que no hay double spend; no hace falta mostrar en el navegador para todos a las partes de la transacción ni los montos.
Ambos modelos al final se gestionan en DuskDS, pero no resuelven el mismo tipo de necesidad.
Este detalle cambió bastante mi forma de ver el diseño de privacidad de Dusk.
Antes pensaba:
Cuanta más privacidad, mejor.
Ahora ya no lo veo así.
En los sistemas financieros, lo público tiene usos propios, y la privacidad también tiene sus propios usos. Para la conciliación de depósitos, la transparencia es necesaria; pero para transferencias normales o flujos de fondos sensibles, tal vez no haya razones para que queden permanentemente públicos.
Aún más interesante: la Dusk Wallet, por sí misma, también admite la conversión entre Moonlight y Phoenix.
Así que no está obligando al usuario a elegir bandos.
Cuando se necesita que sea público, se usa Moonlight; cuando se trata de un flujo shielded, se entra en Phoenix.
Ahora más bien siento que conservar estos dos modelos a la vez es más práctico que forzar que todas las transacciones se metan en la etiqueta de “privacidad”.
Lo “público” aquí no significa que la privacidad no esté bien hecha, sino que es una funcionalidad que se conserva de manera deliberada.