He revisado materiales de auditoría de contratos XSC de Dusk y encontré un punto ciego que todo el mundo pasa por alto: la auditoría de contratos inteligentes confidenciales, que no es en absoluto lo mismo que lo que la gente normal llama “auditoría de contratos inteligentes”. Las auditorías tradicionales se centran en fallos lógicos, reentradas (reentrancy), desbordamientos (overflow) y, además, el código es transparente: el auditor puede leerlo línea por línea. En XSC, los campos están cifrados; el auditor se enfrenta a texto cifrado y a pruebas de conocimiento cero (zero-knowledge). No puedes “leer” el estado del contrato: solo puedes verificar si la prueba se sostiene.
En XSC, el supuesto de las auditorías tradicionales de “ver el código” simplemente se rompe. El resumen de auditorías oficiales de Dusk lista 10 auditorías; lo que cubren es precisamente esta superficie de contratos confidenciales. Yo revisé informes emitidos por instituciones entre ellas: el enfoque no es leer el estado, sino verificar que “las operaciones que deben ejecutarse bajo el estado cifrado realmente se ejecutaron” y que “los campos que deben mantenerse confidenciales no se filtraron”. Por detrás también hay rutas dobles: Phoenix para ocultar y Moonlight para cuentas públicas; la auditoría cubre simultáneamente el modo cifrado y el modo en claro. Ese paso convierte la auditoría de “leer código a mano” a “verificar con criptografía”; el reto no es encontrar bugs, sino demostrar que la lógica del estado cifrado es coherente.
Casi todos los que escriben sobre seguridad en Dusk se limitan a soltar una frase: “AEGIS revisó 39 ítems y corrigió 7 graves”, y ya está; nadie explica la particularidad de las auditorías de contratos confidenciales. Yo verifiqué resúmenes de auditorías de cadenas de privacidad similares, y suelen depender de la “compromiso de auditar tras descifrar”: es como desconectar temporalmente la privacidad para revisarla. Justo esa es la vía que Dusk quiere evitar. XSC integra la auditoría dentro del estado cifrado; ahí está el requisito para que se atrevan a confiar activos reales a instituciones en la cadena.
Así que, al valorar la seguridad de una cadena de privacidad, no cuentes cuántas auditorías “superó” ni cuántos ítems revisó. Lo que importa es si la auditoría se hace en claro o en el estado cifrado. La primera es la línea de aprobación para contratos ordinarios; la segunda es el pase de entrada para las finanzas confidenciales. He visto el proceso de verificación de Dusk y confirmé que sigue la ruta del estado cifrado, no la de descifrar para auditar.
Dusk convirtió “ser auditable” en una característica del contrato al fabricarlo; por lo tanto, la auditoría de seguridad también debe acompañarse de una verificación en modo cifrado. Esta línea casi nadie la explica en detalle, pero precisamente es el umbral real que permite que las instituciones se suban a la cadena. Si te quedas mirando el número de 39 correcciones, es fácil perderte todo el paradigma de auditoría criptográfica que hay debajo. $BTC $ETH
#dusk $DUSK @Dusk
En XSC, el supuesto de las auditorías tradicionales de “ver el código” simplemente se rompe. El resumen de auditorías oficiales de Dusk lista 10 auditorías; lo que cubren es precisamente esta superficie de contratos confidenciales. Yo revisé informes emitidos por instituciones entre ellas: el enfoque no es leer el estado, sino verificar que “las operaciones que deben ejecutarse bajo el estado cifrado realmente se ejecutaron” y que “los campos que deben mantenerse confidenciales no se filtraron”. Por detrás también hay rutas dobles: Phoenix para ocultar y Moonlight para cuentas públicas; la auditoría cubre simultáneamente el modo cifrado y el modo en claro. Ese paso convierte la auditoría de “leer código a mano” a “verificar con criptografía”; el reto no es encontrar bugs, sino demostrar que la lógica del estado cifrado es coherente.
Casi todos los que escriben sobre seguridad en Dusk se limitan a soltar una frase: “AEGIS revisó 39 ítems y corrigió 7 graves”, y ya está; nadie explica la particularidad de las auditorías de contratos confidenciales. Yo verifiqué resúmenes de auditorías de cadenas de privacidad similares, y suelen depender de la “compromiso de auditar tras descifrar”: es como desconectar temporalmente la privacidad para revisarla. Justo esa es la vía que Dusk quiere evitar. XSC integra la auditoría dentro del estado cifrado; ahí está el requisito para que se atrevan a confiar activos reales a instituciones en la cadena.
Así que, al valorar la seguridad de una cadena de privacidad, no cuentes cuántas auditorías “superó” ni cuántos ítems revisó. Lo que importa es si la auditoría se hace en claro o en el estado cifrado. La primera es la línea de aprobación para contratos ordinarios; la segunda es el pase de entrada para las finanzas confidenciales. He visto el proceso de verificación de Dusk y confirmé que sigue la ruta del estado cifrado, no la de descifrar para auditar.
Dusk convirtió “ser auditable” en una característica del contrato al fabricarlo; por lo tanto, la auditoría de seguridad también debe acompañarse de una verificación en modo cifrado. Esta línea casi nadie la explica en detalle, pero precisamente es el umbral real que permite que las instituciones se suban a la cadena. Si te quedas mirando el número de 39 correcciones, es fácil perderte todo el paradigma de auditoría criptográfica que hay debajo. $BTC $ETH
#dusk $DUSK @Dusk
明文
迷态
15 hora(s) restante(s)