#dusk $DUSK
Sobre DUSK, siempre he tenido una duda que no consigo aclarar.
El puente de Dusk no es de la misma especie que los puentes normales entre cadenas.
La lógica de los dos libros contables sincronizados es completamente distinta: del lado de DuskDS hay un libro contable de liquidación con privacidad; todos los saldos y transacciones van envueltos en texto cifrado, así que desde fuera solo se ve jerga sin sentido. Del lado de DuskEVM, en cambio, se ejecutan contratos de valores XSC, que exigen transparencia y auditabilidad.
El trabajo del puente es este: tú pones en garantía una cantidad de XSC en la capa de privacidad y, cuando quieres hacer una transacción en la capa EVM, el puente primero debe confirmar que esos activos realmente existen, y que no han sido falsificados ni reutilizados.
Pero aquí hay un punto muerto. Como el libro de contabilidad de privacidad está cifrado, ¿cómo puede el puente “ver” que el activo realmente existe? No puede. Así que solo se puede pedir al usuario que envíe un comprobante ZK: que demuestre que yo realmente poseo esos XSC en la capa de privacidad y que la conversión de estado es válida.
Generar la prueba requiere una ejecución de cómputo ZK, y al verificar el puente vuelve a ejecutarla: una segunda ejecución de ZK. La seguridad del puente depende completamente de este sistema de pruebas.
Luego, OtterSec encontró una vulnerabilidad en dusk-plonk. El verificador omitió una comprobación clave y la falsa prueba pasó directamente. En una sola capa, equivale a acuñar dinero de la nada. Con 60 millones de dólares bloqueados, ya fue corregido.
Pero revisé todo el material público y nadie respondió a esto: ¿la lógica de verificación del puente nativo y dusk-plonk utilizan el mismo circuito?
Si no, entonces bien. Si sí, o si reutilizan en parte parámetros y plantillas de circuitos, el problema pasa de acuñar en una sola capa a acuñar entre capas: tú falsificas una posición de XSC inexistente en la capa de privacidad, engañas al puente con una prueba falsa y logras que la capa EVM libere los activos correspondientes, para luego venderlos en masa.
Incluso el atacante no necesita tocar la lógica del contrato del puente: basta con que el sistema de pruebas tenga una grieta, y el puente se convierte en una máquina de extracción.
Dicho con justicia: la verificación del puente quizá se implementó de forma independiente, con auditorías adicionales, solo que no se publicó. No puedo demostrar que sea inseguro, pero tampoco encontré pruebas de que sea seguro.
Hasta hoy, la oficina oficial no ha divulgado el informe de auditoría independiente del puente nativo, ni ha explicado si la verificación entre capas está aislada por código respecto a dusk-plonk.
Antes de que NPEX migre valores por varios cientos de millones de euros, esta cuestión debe responderse de frente.
No se puede pasar con “la vulnerabilidad ya fue corregida” a secas. El puente no conecta solo dos cadenas: conecta una única puerta entre el mundo de la privacidad y el mundo público. Que esa puerta tenga o no cerradura, no lo sabrás hasta que alguien entre.
@Dusk
Sobre DUSK, siempre he tenido una duda que no consigo aclarar.
El puente de Dusk no es de la misma especie que los puentes normales entre cadenas.
La lógica de los dos libros contables sincronizados es completamente distinta: del lado de DuskDS hay un libro contable de liquidación con privacidad; todos los saldos y transacciones van envueltos en texto cifrado, así que desde fuera solo se ve jerga sin sentido. Del lado de DuskEVM, en cambio, se ejecutan contratos de valores XSC, que exigen transparencia y auditabilidad.
El trabajo del puente es este: tú pones en garantía una cantidad de XSC en la capa de privacidad y, cuando quieres hacer una transacción en la capa EVM, el puente primero debe confirmar que esos activos realmente existen, y que no han sido falsificados ni reutilizados.
Pero aquí hay un punto muerto. Como el libro de contabilidad de privacidad está cifrado, ¿cómo puede el puente “ver” que el activo realmente existe? No puede. Así que solo se puede pedir al usuario que envíe un comprobante ZK: que demuestre que yo realmente poseo esos XSC en la capa de privacidad y que la conversión de estado es válida.
Generar la prueba requiere una ejecución de cómputo ZK, y al verificar el puente vuelve a ejecutarla: una segunda ejecución de ZK. La seguridad del puente depende completamente de este sistema de pruebas.
Luego, OtterSec encontró una vulnerabilidad en dusk-plonk. El verificador omitió una comprobación clave y la falsa prueba pasó directamente. En una sola capa, equivale a acuñar dinero de la nada. Con 60 millones de dólares bloqueados, ya fue corregido.
Pero revisé todo el material público y nadie respondió a esto: ¿la lógica de verificación del puente nativo y dusk-plonk utilizan el mismo circuito?
Si no, entonces bien. Si sí, o si reutilizan en parte parámetros y plantillas de circuitos, el problema pasa de acuñar en una sola capa a acuñar entre capas: tú falsificas una posición de XSC inexistente en la capa de privacidad, engañas al puente con una prueba falsa y logras que la capa EVM libere los activos correspondientes, para luego venderlos en masa.
Incluso el atacante no necesita tocar la lógica del contrato del puente: basta con que el sistema de pruebas tenga una grieta, y el puente se convierte en una máquina de extracción.
Dicho con justicia: la verificación del puente quizá se implementó de forma independiente, con auditorías adicionales, solo que no se publicó. No puedo demostrar que sea inseguro, pero tampoco encontré pruebas de que sea seguro.
Hasta hoy, la oficina oficial no ha divulgado el informe de auditoría independiente del puente nativo, ni ha explicado si la verificación entre capas está aislada por código respecto a dusk-plonk.
Antes de que NPEX migre valores por varios cientos de millones de euros, esta cuestión debe responderse de frente.
No se puede pasar con “la vulnerabilidad ya fue corregida” a secas. El puente no conecta solo dos cadenas: conecta una única puerta entre el mundo de la privacidad y el mundo público. Que esa puerta tenga o no cerradura, no lo sabrás hasta que alguien entre.
@Dusk