Primera vez que vi a @Dusk desarrollando al mismo tiempo dos modelos de trading, Moonlight y Phoenix. En realidad tuve una pregunta muy directa:
si tu enfoque principal es la privacidad, ¿por qué no hacerlo todo de forma que sean transacciones privadas?
Transparente y privado a la vez, ¿no es más complicado?
Luego revisé con más detenimiento el libro blanco y, al contrario, me dio la impresión de que esa especie de “desequilibrio” podría ser precisamente lo más parecido a las finanzas reales.
Moonlight es sencillo: utiliza un modelo de cuentas similar al de Ethereum.
Saldos, Nonce, estados de la transacción... todo se ve públicamente.
Las transacciones dependen de la verificación mediante firmas.
Phoenix, en cambio, sigue una lógica completamente distinta.
Es un modelo UTXO: introduce direcciones stealth, nullifier y pruebas de conocimiento cero.
La red no necesita ver directamente en qué gastaste cada moneda ni cuál es tu saldo; solo necesita validar esa prueba ZK:
que realmente tienes los activos, que el saldo alcanza, que no hay doble gasto y que la transacción no fue alterada.
A primera vista, parece que el sistema se vuelve más complejo.
Pero la realidad es que las finanzas por sí mismas no son de un solo “nivel de permisos”.
Los depósitos y retiros en las bolsas quizá encajen mejor con cuentas públicas.
Las transferencias de valores entre instituciones, las posiciones de activos y el trading de clientes, en cambio, podrían requerir privacidad.
Y en auditorías, además, es imprescindible poder revelar información.
Si metes todo tipo de negocio a la fuerza en un único modelo de transacciones, al final o la privacidad no alcanza o la normativa es difícil de cumplir.
Por eso, Moonlight + Phoenix me dan la sensación de una entidad financiera que tiene, dentro del mismo banco, tanto un “hall” como una “bóveda”.
En el hall no hay necesidad de ocultar nada.
En la bóveda, tampoco hace falta mostrarle todo a los transeúntes.
La clave no es que sea totalmente transparente o totalmente privado, sino que el dinero distinto se trate con reglas distintas.
Esto también explica por qué Dusk ahora sigue trabajando, por un lado, en L1 nativo y, por otro, en DuskEVM y Hedger.
DuskEVM le da a los desarrolladores de Solidity la ruta familiar de EVM, y Hedger aprovecha la encriptación homomórfica y las pruebas de conocimiento cero para completar los flujos de transacciones confidenciales.
En lo personal, creo que esta ruta es más realista que la idea de que “todos los desarrolladores deben aprender obligatoriamente todo de nuevo”.
Por supuesto, el problema también es evidente.
Cuantos más módulos haya, más complejo será el sistema.
Que el L1 nativo, DuskEVM, Hedger y Dusk Trade puedan formar finalmente un ciclo cerrado real, y no que sean cuatro productos que cuentan historias distintas por separado, es precisamente lo que seguiré observando.
$DUSK #dusk
si tu enfoque principal es la privacidad, ¿por qué no hacerlo todo de forma que sean transacciones privadas?
Transparente y privado a la vez, ¿no es más complicado?
Luego revisé con más detenimiento el libro blanco y, al contrario, me dio la impresión de que esa especie de “desequilibrio” podría ser precisamente lo más parecido a las finanzas reales.
Moonlight es sencillo: utiliza un modelo de cuentas similar al de Ethereum.
Saldos, Nonce, estados de la transacción... todo se ve públicamente.
Las transacciones dependen de la verificación mediante firmas.
Phoenix, en cambio, sigue una lógica completamente distinta.
Es un modelo UTXO: introduce direcciones stealth, nullifier y pruebas de conocimiento cero.
La red no necesita ver directamente en qué gastaste cada moneda ni cuál es tu saldo; solo necesita validar esa prueba ZK:
que realmente tienes los activos, que el saldo alcanza, que no hay doble gasto y que la transacción no fue alterada.
A primera vista, parece que el sistema se vuelve más complejo.
Pero la realidad es que las finanzas por sí mismas no son de un solo “nivel de permisos”.
Los depósitos y retiros en las bolsas quizá encajen mejor con cuentas públicas.
Las transferencias de valores entre instituciones, las posiciones de activos y el trading de clientes, en cambio, podrían requerir privacidad.
Y en auditorías, además, es imprescindible poder revelar información.
Si metes todo tipo de negocio a la fuerza en un único modelo de transacciones, al final o la privacidad no alcanza o la normativa es difícil de cumplir.
Por eso, Moonlight + Phoenix me dan la sensación de una entidad financiera que tiene, dentro del mismo banco, tanto un “hall” como una “bóveda”.
En el hall no hay necesidad de ocultar nada.
En la bóveda, tampoco hace falta mostrarle todo a los transeúntes.
La clave no es que sea totalmente transparente o totalmente privado, sino que el dinero distinto se trate con reglas distintas.
Esto también explica por qué Dusk ahora sigue trabajando, por un lado, en L1 nativo y, por otro, en DuskEVM y Hedger.
DuskEVM le da a los desarrolladores de Solidity la ruta familiar de EVM, y Hedger aprovecha la encriptación homomórfica y las pruebas de conocimiento cero para completar los flujos de transacciones confidenciales.
En lo personal, creo que esta ruta es más realista que la idea de que “todos los desarrolladores deben aprender obligatoriamente todo de nuevo”.
Por supuesto, el problema también es evidente.
Cuantos más módulos haya, más complejo será el sistema.
Que el L1 nativo, DuskEVM, Hedger y Dusk Trade puedan formar finalmente un ciclo cerrado real, y no que sean cuatro productos que cuentan historias distintas por separado, es precisamente lo que seguiré observando.
$DUSK #dusk