#dusk $DUSK @Dusk Boreas se activó en la red de pruebas en mayo; mi primera reacción fue: ¿se sube (en valor) aunque la red principal todavía no esté en marcha? Revisé y resulta que el 7 de enero de 2025 la red principal ya había empezado a producir bloques; fui yo quien iba ocho meses atrasado.
Cuando leía la documentación, el fragmento de Phoenix me dejó sentado. Pensaba que las cadenas de privacidad solo tenían dos modelos: Monero totalmente opaco o Ethereum totalmente transparente. Pero Phoenix queda en medio, en un punto especialmente enrevesado. Las fondos se guardan en notas cifradas; lanzas las transacciones; los validadores no miran el importe, ni el remitente ni el destinatario: solo verifican una prueba de conocimiento cero. Esa prueba demuestra que no hay doble gasto y que el saldo alcanza. En ese momento pensé: “¿No es eso la lógica de una criptomoneda de privacidad de toda la vida?”.
Hasta que, al revisar un informe de auditoría, vi esta frase: “El validador solo verifica la validez de la prueba, no verifica la relación de vinculación entre la prueba y las entradas/salidas de la transacción”. La leí tres veces antes de entenderlo: el validador verifica “que la prueba está bien resuelta”, no “que la prueba resuelva precisamente la pregunta que tú me estás dando”. Son cosas distintas.
Esa diferencia me asustó. Si la relación de vinculación no queda inmovilizada, un atacante podría usar una prueba de una transacción legítima para validarla en otra transacción ilegal. El validador aun así daría su visto bueno, porque “la matemática está bien”.
Luego fui a revisar la lógica de verificación de Plonk. La verificación de las ecuaciones se hace a nivel de polinomios para comprobar la integridad del cálculo, pero si el contenido de la prueba realmente corresponde a los inputs y outputs de esa transacción depende por completo de las restricciones de codificación. Si se omite una comprobación en el circuito, la prueba pasa. Antes creía que el verdadero reto de una cadena de privacidad era si la criptografía era lo bastante fuerte; pero al ver esto, descubrí que la dificultad real es: “que lo que el validador está verificando sea realmente lo que tú dices que se debe verificar”.
Sin Phoenix, en Dusk para RWA solo hay dos caminos: o instituciones en una cadena transparente no se atreven, o con una cadena totalmente opaca la supervisión/regularización cierra. La view key por capas resuelve ese problema, pero con una condición: que el validador efectivamente esté verificando la transacción en sí. La dirección está bien; y el NPEX de 300 millones de euros también sigue en marcha. Pero al final, la seguridad depende de que cada restricción quede firmemente fijada; por muy bonita que sea la matemática, si el código no aguanta, no sirve de nada.
Cuando leía la documentación, el fragmento de Phoenix me dejó sentado. Pensaba que las cadenas de privacidad solo tenían dos modelos: Monero totalmente opaco o Ethereum totalmente transparente. Pero Phoenix queda en medio, en un punto especialmente enrevesado. Las fondos se guardan en notas cifradas; lanzas las transacciones; los validadores no miran el importe, ni el remitente ni el destinatario: solo verifican una prueba de conocimiento cero. Esa prueba demuestra que no hay doble gasto y que el saldo alcanza. En ese momento pensé: “¿No es eso la lógica de una criptomoneda de privacidad de toda la vida?”.
Hasta que, al revisar un informe de auditoría, vi esta frase: “El validador solo verifica la validez de la prueba, no verifica la relación de vinculación entre la prueba y las entradas/salidas de la transacción”. La leí tres veces antes de entenderlo: el validador verifica “que la prueba está bien resuelta”, no “que la prueba resuelva precisamente la pregunta que tú me estás dando”. Son cosas distintas.
Esa diferencia me asustó. Si la relación de vinculación no queda inmovilizada, un atacante podría usar una prueba de una transacción legítima para validarla en otra transacción ilegal. El validador aun así daría su visto bueno, porque “la matemática está bien”.
Luego fui a revisar la lógica de verificación de Plonk. La verificación de las ecuaciones se hace a nivel de polinomios para comprobar la integridad del cálculo, pero si el contenido de la prueba realmente corresponde a los inputs y outputs de esa transacción depende por completo de las restricciones de codificación. Si se omite una comprobación en el circuito, la prueba pasa. Antes creía que el verdadero reto de una cadena de privacidad era si la criptografía era lo bastante fuerte; pero al ver esto, descubrí que la dificultad real es: “que lo que el validador está verificando sea realmente lo que tú dices que se debe verificar”.
Sin Phoenix, en Dusk para RWA solo hay dos caminos: o instituciones en una cadena transparente no se atreven, o con una cadena totalmente opaca la supervisión/regularización cierra. La view key por capas resuelve ese problema, pero con una condición: que el validador efectivamente esté verificando la transacción en sí. La dirección está bien; y el NPEX de 300 millones de euros también sigue en marcha. Pero al final, la seguridad depende de que cada restricción quede firmemente fijada; por muy bonita que sea la matemática, si el código no aguanta, no sirve de nada.
