Probé esa doble cuenta para transferencias cruzadas de Dusk y sentí un escalofrío en la espalda: la privacidad se hace para los usuarios, no para que los desarrolladores se desahoguen insultando
Anoche vi un post de pruebas. El autor movió algunas operaciones entre Moonlight y Phoenix de Dusk, y cuanto más jugaba, más raro se ponía.
Dos direcciones derivadas de un mismo conjunto de frases mnemónicas: una es transparente como un acuario de vidrio y la otra es una caja negra donde ni siquiera puedes ver el saldo. En el lado del usuario, tocas “cambiar” y ya pasa; pero en la capa base del protocolo, se siguen por completo dos lógicas de contabilidad: Moonlight es un modelo de cuenta, con el saldo escrito directamente en el contrato; Phoenix es UTXO con note, y se “arma” con compromisos de Pedersen y el nullifier. @Dusk
¿Te parece buena esa idea? Es buena. Pero intenta escribir encima un contrato de préstamos: en la liquidación tienes que gestionar al mismo tiempo dos estados; el saldo de ETH y los nullifier de las notas de privacidad deben calcularse juntos. Escribir la lógica de Moonlight te preocupa que a los grandes les hagan “caza”; escribir la lógica de Phoenix te preocupa que la regulación te corte la interfaz directamente. En la documentación lo despachan con una frase ligera: “elige según necesidad”. Los desarrolladores la leen y solo quieren maldecir: esto no es modularización; es tirar la pregunta al ecosistema para que lo paguen.
Lo que más me eriza la piel es otro análisis. La historia de los tokens de valores en NPEX suena bastante bien, pero al final todo acaba refugiado en Moonlight. Los de MiCA ni siquiera confían en que las reservas de stablecoins pasen sin auditorías trimestrales; y tú les dices: “tengo zk-proof para elegir una vista enmascarada”. La reacción del regulador siempre es la misma: ¿el código puede exportar un Excel con un clic? La “divulgación selectiva” de Phoenix, para un abogado, es una caja negra técnica: si algo sale mal, ¿quién firma? Las instituciones no son tontos. Con cosas de verdad que valen dinero, prefieren ir sin armadura—pero que exista trazabilidad y responsabilidad.
Ahora la tasa de staking en cadena está al 36%, y se ve bien, pero la gente del sector sabe que todo es nodos festeándose a sí mismos. DuskEVM ya se lanzó; pero si el año que viene el listado de Dapps sigue dejando vacío el espacio de Phoenix, este proyecto se degradará a una cadena EVM con plugins de privacidad y la narrativa se derrumba por la mitad.
No estoy diciendo que la tecnología sea mala—el acoplamiento de UTXO con ZK es realmente exigente. Pero que el producto no dé una respuesta predeterminada es el mayor fracaso. Un usuario normal ni siquiera recuerda la frase mnemónica; y encima quieres que antes de cada transferencia se debata “¿hoy abro la privacidad?”
Quería dejar una orden de observación, pero la retiré. A ver si aparece el primer caso donde alguien se atreva a tirar el pool de liquidez principal a Phoenix y, además, reciba un respaldo por escrito de la regulación de la Unión Europea.
#dusk $DUSK
Anoche vi un post de pruebas. El autor movió algunas operaciones entre Moonlight y Phoenix de Dusk, y cuanto más jugaba, más raro se ponía.
Dos direcciones derivadas de un mismo conjunto de frases mnemónicas: una es transparente como un acuario de vidrio y la otra es una caja negra donde ni siquiera puedes ver el saldo. En el lado del usuario, tocas “cambiar” y ya pasa; pero en la capa base del protocolo, se siguen por completo dos lógicas de contabilidad: Moonlight es un modelo de cuenta, con el saldo escrito directamente en el contrato; Phoenix es UTXO con note, y se “arma” con compromisos de Pedersen y el nullifier. @Dusk
¿Te parece buena esa idea? Es buena. Pero intenta escribir encima un contrato de préstamos: en la liquidación tienes que gestionar al mismo tiempo dos estados; el saldo de ETH y los nullifier de las notas de privacidad deben calcularse juntos. Escribir la lógica de Moonlight te preocupa que a los grandes les hagan “caza”; escribir la lógica de Phoenix te preocupa que la regulación te corte la interfaz directamente. En la documentación lo despachan con una frase ligera: “elige según necesidad”. Los desarrolladores la leen y solo quieren maldecir: esto no es modularización; es tirar la pregunta al ecosistema para que lo paguen.
Lo que más me eriza la piel es otro análisis. La historia de los tokens de valores en NPEX suena bastante bien, pero al final todo acaba refugiado en Moonlight. Los de MiCA ni siquiera confían en que las reservas de stablecoins pasen sin auditorías trimestrales; y tú les dices: “tengo zk-proof para elegir una vista enmascarada”. La reacción del regulador siempre es la misma: ¿el código puede exportar un Excel con un clic? La “divulgación selectiva” de Phoenix, para un abogado, es una caja negra técnica: si algo sale mal, ¿quién firma? Las instituciones no son tontos. Con cosas de verdad que valen dinero, prefieren ir sin armadura—pero que exista trazabilidad y responsabilidad.
Ahora la tasa de staking en cadena está al 36%, y se ve bien, pero la gente del sector sabe que todo es nodos festeándose a sí mismos. DuskEVM ya se lanzó; pero si el año que viene el listado de Dapps sigue dejando vacío el espacio de Phoenix, este proyecto se degradará a una cadena EVM con plugins de privacidad y la narrativa se derrumba por la mitad.
No estoy diciendo que la tecnología sea mala—el acoplamiento de UTXO con ZK es realmente exigente. Pero que el producto no dé una respuesta predeterminada es el mayor fracaso. Un usuario normal ni siquiera recuerda la frase mnemónica; y encima quieres que antes de cada transferencia se debata “¿hoy abro la privacidad?”
Quería dejar una orden de observación, pero la retiré. A ver si aparece el primer caso donde alguien se atreva a tirar el pool de liquidez principal a Phoenix y, además, reciba un respaldo por escrito de la regulación de la Unión Europea.
#dusk $DUSK
