Esta noche volqué los registros de los nodos para revisarlos y, de repente, me acordé de una pelea que tuve la semana pasada con un amigo que hace auditorías.
El mercado cayó un poco, pero ¡la tendencia alcista del BTC sigue!
Me preguntó: «Vosotros que corréis Dusk, ¿de verdad os quedáis tranquilos dejando la lógica de verificación fuera de WASM?» En ese momento no supe qué contestar: solté que «el whitepaper dice que se auditó», pero por dentro me daba bastante inseguridad. Hasta que esta noche di con los casos de prueba de Piecrust en su GitHub para la función host, y ahí sí sentí que tocaba algo del meollo.
Vamos al grano: la idea tradicional de «bloquear todo en una sandbox» es como ir a una tienda de conveniencia a comprar un paquete de cigarrillos: primero tienes que pasar el control de seguridad, enseñar el documento de identidad, revisar el bolso… y al final te dejan pagar. Sí, es seguro, pero la gente de atrás va a acabar maldiciendo en la fila. Dusk apuesta por otro camino: las acciones de alta frecuencia pasan por un canal dedicado y las de baja frecuencia pasan por el control.
Los datos de terceros que citan me fui a buscarlos en el original: ese paper mide la degradación de rendimiento de WASM frente a nativo bajo distintos conjuntos de instrucciones. En el escenario criptográfico más extremo, la sobrecarga llega a 255%. Haz cuentas: si Dusk necesita validar firmas BLS en, digamos, X transacciones al día, y en otras Y transacciones hay que pasar pruebas ZK, ¿qué pasa si en cada una le das el trabajo de interpretar todo a WASM? Es como pagar «dos kilómetros y medio» extra de gasolina por cada kilómetro recorrido. ¿Quién lo aguanta?
Por eso convierten esas piezas en llamadas a sistema: invocan implementaciones nativas directamente. ¿Cuál es el coste? Que el radio de confianza pasa de «ese cajón de hierro de la sandbox de WASM» a «si esas pocas líneas de C de la función del host están bien escritas». Estos dos riesgos no son de la misma magnitud: el primero es aislamiento físico; el segundo, calidad del código.
Revisé su informe de auditoría de 2024 Q3 (escondido en algún rincón de la web). Al menos para esas épocas, los casos límite que se evaluaron no destaparon ningún problema. Pero, siendo honestos, este tipo de superficie de ataque no se «mide» para encontrarla: se usa para explotarla. Algún día alguien alimenta con un conjunto de datos de prueba cuidadosamente construido, activa un desbordamiento de enteros dentro de alguna función host que nadie notó… la escena sería demasiado horrible como para imaginarla.
Dicho esto: si de verdad buscas «seguridad absoluta», no montes una blockchain pública; vuelve y escribe un programa de escritorio. La gente de Dusk apuesta a esto: primero te asfixian el cuello de botella del rendimiento y, mientras tanto, los problemas de seguridad todavía se pueden parchear. @Dusk $DUSK #dusk
El mercado cayó un poco, pero ¡la tendencia alcista del BTC sigue!
Me preguntó: «Vosotros que corréis Dusk, ¿de verdad os quedáis tranquilos dejando la lógica de verificación fuera de WASM?» En ese momento no supe qué contestar: solté que «el whitepaper dice que se auditó», pero por dentro me daba bastante inseguridad. Hasta que esta noche di con los casos de prueba de Piecrust en su GitHub para la función host, y ahí sí sentí que tocaba algo del meollo.
Vamos al grano: la idea tradicional de «bloquear todo en una sandbox» es como ir a una tienda de conveniencia a comprar un paquete de cigarrillos: primero tienes que pasar el control de seguridad, enseñar el documento de identidad, revisar el bolso… y al final te dejan pagar. Sí, es seguro, pero la gente de atrás va a acabar maldiciendo en la fila. Dusk apuesta por otro camino: las acciones de alta frecuencia pasan por un canal dedicado y las de baja frecuencia pasan por el control.
Los datos de terceros que citan me fui a buscarlos en el original: ese paper mide la degradación de rendimiento de WASM frente a nativo bajo distintos conjuntos de instrucciones. En el escenario criptográfico más extremo, la sobrecarga llega a 255%. Haz cuentas: si Dusk necesita validar firmas BLS en, digamos, X transacciones al día, y en otras Y transacciones hay que pasar pruebas ZK, ¿qué pasa si en cada una le das el trabajo de interpretar todo a WASM? Es como pagar «dos kilómetros y medio» extra de gasolina por cada kilómetro recorrido. ¿Quién lo aguanta?
Por eso convierten esas piezas en llamadas a sistema: invocan implementaciones nativas directamente. ¿Cuál es el coste? Que el radio de confianza pasa de «ese cajón de hierro de la sandbox de WASM» a «si esas pocas líneas de C de la función del host están bien escritas». Estos dos riesgos no son de la misma magnitud: el primero es aislamiento físico; el segundo, calidad del código.
Revisé su informe de auditoría de 2024 Q3 (escondido en algún rincón de la web). Al menos para esas épocas, los casos límite que se evaluaron no destaparon ningún problema. Pero, siendo honestos, este tipo de superficie de ataque no se «mide» para encontrarla: se usa para explotarla. Algún día alguien alimenta con un conjunto de datos de prueba cuidadosamente construido, activa un desbordamiento de enteros dentro de alguna función host que nadie notó… la escena sería demasiado horrible como para imaginarla.
Dicho esto: si de verdad buscas «seguridad absoluta», no montes una blockchain pública; vuelve y escribe un programa de escritorio. La gente de Dusk apuesta a esto: primero te asfixian el cuello de botella del rendimiento y, mientras tanto, los problemas de seguridad todavía se pueden parchear. @Dusk $DUSK #dusk