El Lamentable Estado de las Auditorías en Web3, y Qué se Puede Hacer

Balancer, un protocolo antiguo y bien auditado, fue recientemente "hackeado". Yearn Finance, igualmente bien auditado, también lo fue. Hace años, Euler Finance fue "hackeado" a través de una función introducida en respuesta a una auditoría anterior. USPD fue auditado antes del despliegue y luego el proceso de despliegue no auditado fue hackeado, lo que llevó a una pérdida total en aproximadamente 3 meses desde su lanzamiento. Nadie que haya estado prestando atención cree que las auditorías son una garantía de que algo es seguro. Muchos cuestionan si valen algo en absoluto.

Esto no es nuevo. Esto no es un problema de web3. Y, en realidad, esta no es una observación particularmente profunda. Pero las auditorías siguen siendo muy relevantes. Los proyectos pagan por auditorías. Los proyectos promocionan auditorías. La gente finge leer auditorías. A menudo, cuando un producto auditado es explotado, la gente pregunta por qué y cómo sucedió eso.

En lugar de responder a nada de eso directamente, vamos a trabajar a través de algunas auditorías recientes de productos lanzados recientemente. El objetivo aquí no es burlarse ni criticar a nadie. Estos son seleccionados al azar, principalmente debido al enfoque en cosas recientes. Eso no significa que sean particularmente malos. ¡Ni siquiera son tan malos!

Nuestro punto aquí no es que los auditores estén haciendo algo mal. Los auditores están haciendo lo que los proyectos que los contratan solicitan. El alcance de la auditoría lo establece el proyecto. Como un ejemplo extremo: si Do Kwon hubiera contratado auditores para su esquema de stablecoin, habrían señalado que era potencialmente inestable. El problema habría sido marcado como "reconocido" y nada se habría hecho o sería diferente.

Este problema no tiene absolutamente nada que ver con estudios como aquellos que afirmaban que el ecosistema Terra-LUNA de Do era altamente robusto. Es difícil predecir el futuro y ese tipo de estudios se ven correctamente como marketing interesado que, en el límite, reconoce los problemas centrales. Se espera que la investigación patrocinada por proyectos pinte las cosas de manera positiva. El punto completo de las auditorías es proporcionar una perspectiva objetiva de terceros. No se debe confiar en la exageración y las auditorías no son garantías ni seguros. Así es la vida.

El punto de esta encuesta es enfatizar que el problema real aquí no son los errores básicos de programación del tipo que los auditores están bien situados para identificar y el proceso de auditoría está bien diseñado para resolver. Los auditores son bastante buenos atrapando esos. También lo son, de hecho, los programadores que construyen estas cosas en primer lugar. Empíricamente, este tipo de retroalimentación llega a las personas adecuadas y los problemas específicos se solucionan.

No, el problema real son los productos que funcionan exactamente según lo previsto y donde un "riesgo" conocido se materializa para derribar todo. Lo que vas a ver ahora son auditores tratando de protegerse contra todos y cada uno de los problemas conocidos-desconocidos futuros. Como ejercicio de protección contra responsabilidad y burla, tal vez esto sea algo valioso. Pero, en un sentido general, no ayuda a nadie.

Y luego, al final, vamos a discutir qué pueden hacer varias partes que ayudaría y serviría a sus propios intereses estrechos. Si tu receta para mejorar las auditorías implica altruismo, bueno, no es muy útil.

Jovay

Jovay es una L2 asociada con Ant Financial o Alibaba o algo en esa área general. Pero no importa realmente lo que hace Jovay. Es algo construido con software de una organización grande y bien financiada. Esta auditoría enumera ocho problemas:

1. Un error de programación legítimo que se corrigió posteriormente.
2. Que el protocolo no es trustless. Esto es un problema en cierto modo, pero también es una parte central del diseño.
3. El ataque de "recarga falsa" que se aplica a una amplia franja del ecosistema y no es específico del proyecto.
4. Los servidores RPC usan HTTP en lugar de HTTPS. Estas interfaces no procesan información secreta. Esto se aplica a miles de millones de sitios web de solo lectura perfectamente seguros.
5. La computación cuántica representa un riesgo para Ethereum. OK. Muy relevante ese.
6. Los smart contracts EVM pueden ser vulnerables. No en serio. Dice "Los smart contracts Evm son susceptibles a varios vectores de ataque debido al despliegue de código inmutable e interacciones complejas, lo que podría llevar al robo de fondos,.." Ok. Nuevamente, realmente respetando el enfoque estrecho de esta auditoría.
7. El diseño del secuenciador está sujeto a MEV. Como el resto del ecosistema Ethereum. También está demasiado oscuro por la noche.
8. La calidad del código podría mejorarse. A diferencia de la mayoría del otro código escrito desde los albores de la informática.

Solo uno de estos es un problema real. Sí, vale la pena señalar que el producto en sí no es trustless si la documentación establece lo contrario. Pero este producto está bastante bien en ese frente. Señalar que la computación cuántica potencialmente representa un riesgo futuro y que los smart contacts pueden ser riesgosos... esos son intentos de hacer el informe más largo encontrando problemas inventados o son un intento de proporcionar algún tipo de "no es nuestra culpa" si algo es eventualmente hackeado. Probablemente una mezcla de ambos.

En el espíritu de esos puntos, proponemos como noveno problema que la red se caerá cuando el sol muera a menos que nos convirtamos en una especie interestelar y de alguna manera descubramos la comunicación más rápida que la luz. De lo contrario, la relatividad limita la vida útil de este sistema a unos 5 mil millones de años. Honestamente, eso es más útil que afirmar que la calidad del código podría mejorarse porque incluso después de que el Sol muera todavía habrá código malo ejecutándose en algún lugar. Pero bromeamos.

Hyperliquid

Hyperliquid ha publicado algunos informes de auditoría. El primer informe de auditoría encontró seis problemas y el segundo informe confirmó que se resolvieron. Pero el alcance de la auditoría excluyó:

1. Otros smart contracts parte del sistema Hyperliquid
2. Componentes off-chain, como validadores
3. Componentes front-end
4. Infraestructura relacionada con el proyecto
5. Custodia de claves

¡Esas parecen áreas problemáticas potenciales! Todo lo que se auditó fue un solo contrato puente. Pero el sistema es, bueno, mucho más complicado que eso.

Auditar un pequeño rincón del sistema que solo hace algunas cosas estrictamente definidas es bastante inútil. La forma en que está diseñado Hyperliquid, el contrato auditado es el punto de entrada y salida externo para todos. Por lo tanto, sería un problema serio si ese contrato estuviera plagado de errores. Pero confirmar que el contrato funciona proporciona poco o ningún consuelo.

Ondo

Esta auditoría destaca "RIESGO DE CENTRALIZACIÓN PARA ENTIDADES Y ROLES DE CONFIANZA" que el equipo reconoció. Está en mayúsculas así en el informe. Correcto.

Esta auditoría señala que el sistema podría colapsar si un stablecoin involucrado se despega demasiado. Lo expresan como que el sistema "permitirá la acuñación excesiva de tokens OUSG durante el evento de despeg de USDC". Al final, la "solución" que implementaron fue una referencia a un oráculo Chainlink y un interruptor de apagado en caso de que el precio se reporte como demasiado bajo. Así que en lugar de implosionar con el valor cayendo, el protocolo se detendrá con el valor cayendo. Correcto. Este no es un problema solucionable en el sentido de que no hay mecanismo para evitar un resultado de pérdida de valor si USDC explota. Y, en línea con ese hecho, la solución realmente no arregla nada.

Esas auditorías son relativamente recientes. Pero para dar algo de contexto, esta auditoría de octubre de 2022 identifica muchos problemas reales. Casi 200 de ellos. La mayoría se corrigieron, algunos fueron similares a los anteriores y simplemente se reconocieron. El punto es que la auditoría solía hacer algo concreto y sustancial: buscar errores de programación que no pudieron haber sido la intención del programador. Los programadores solían corregir estos errores porque eran, ya sabes, errores genuinos, no solo decisiones de diseño cuestionables integradas en el producto.

Y luego, para 2024, vemos auditorías que encuentran relativamente pocos problemas técnicos y declaran fuera de alcance los ataques relacionados con las finanzas. La única forma sensata de interpretar este cambio con el tiempo es que los programadores, y los programadores como auditores, reconocieron que el código funcional no era el único riesgo. Claro, los errores de programación se explotaron de vez en cuando. Pero para mediados de 2024, todos podían ver que los mecanismos económicos defectuosos también eran un riesgo masivo. Eran el mayor riesgo.

Los proyectos que funcionaron exactamente según lo previsto, no como se soñó, como se pretendía en realidad, explotan de vez en cuando porque los sueños de estabilidad de los diseñadores se rompen cuando se enfrentan al mundo real.

Puedes ver esta evolución en las auditorías de este proyecto.

Mutuum Finance

Ahora tenemos la reductio ad absurdum de las auditorías. Esta identifica un solo problema:

El problema es la falta de transparencia en torno a la distribución inicial de tokens y cómo eso podría estar relacionado con problemas de centralización. Ha sido "mitigado" porque:

Luego hay muchos detalles de multisig. Y finalmente la respuesta del auditor:

Así que el riesgo con el proyecto es que un pequeño equipo controla todo y la forma en que ese control será, o tal vez no será, dispersado es completamente no transparente. Y la solución propuesta del equipo de escribir una publicación de blog para aclarar su intención no, en ningún sentido estricto, arregla esto.

Para que conste, el equipo ha publicado una lista detallada de qué tokens irán a dónde y cuándo. Y reconocen que esto está incompleto con comentarios como "Estamos considerando un modelo de distribución bloque por bloque o semanal". También reconocen que todo se gestionará con multisigs manuales. Así que están siendo honestos. Es solo que la honestidad equivale a "sí, todavía podemos hacer lo que queramos y tienes que confiar en nosotros".

¿Cuál es el propósito de esta auditoría? Si el código no tuviera errores identificables, el auditor podría simplemente escribir eso. A veces, una visita al médico o al mecánico produce un certificado de salud limpio. Así que nos quedamos preguntándonos si solo se auditó una cantidad trivial de código. ¿O tal vez el proyecto en sí es solo una cantidad trivial de código? ¿El auditor sintió la necesidad de poner algo en el informe porque de lo contrario era todo demasiado vacuo? ¿Por qué alguien se molestó con algo de esto?

Nuevamente, no estamos realmente culpando a los auditores aquí. En la medida en que alguien esté haciendo algo mal aquí, es casi con certeza un problema de incentivos con quien encargó la auditoría. Y el hecho de que estén gastando dinero de inversores para producir un documento mayormente inútil con fines de marketing. ¡Eso no es responsabilidad del auditor!

Mejoras

Es algo inequívocamente bueno que se atrapen más errores, se libere menos código defectuoso a producción y se implementen más correcciones propuestas. Y no somos lo suficientemente inmaduros como para sugerir que el problema es que los usuarios e inversores se preocupan por las cosas equivocadas, como, por ejemplo, depositar valor y confianza en auditorías que no significan mucho. La gente se preocupa por lo que se preocupa e intentar cambiar eso es una tarea inútil.

Pero hay algunas mejoras reales que podemos sugerir. Ethena lideró el camino al explicar algunos de los muchos modos de falla de su producto por adelantado. El equipo fue consistente con el mensaje de que USDe no estaba libre de riesgo. Y delinearon formas en que podría tener problemas. El producto ha sobrevivido, con algunos baches, y es bastante grande hoy. Esto nos da un punto de acción para los inversores: insistir en que los proyectos sean honestos sobre cualquier "ataque relacionado con las finanzas" que pueda existir.

¡Ethena muestra que ser honesto no condena al proyecto! Puedes argumentar que al ser más honesto, el proyecto atrajo más interés. La honestidad también tiene el beneficio adicional de proporcionar más cobertura legal si algo sale mal. Los proyectos ya deberían querer hacer esto.

Los auditores también pueden reorganizar la forma en que hacen el análisis para hacer su trabajo más útil. O al menos menos inútil y potencialmente engañoso. No pongan problemas de incentivos económicos o preocupaciones generales como la seguridad cuántica en la misma sección que los errores. A partir de ahora, estos normalmente están etiquetados de una manera que los diferencia ligeramente de los errores de codificación. O se enumeran como "informativos" en lugar de "críticos".

Pero esto pierde el punto. La seguridad cuántica bien puede ser un riesgo "crítico" para un sistema, ¡pero es de un carácter completamente diferente que una mala verificación de firma o un signo menos errante! Pongan estas cosas en secciones separadas. De manera similar, "este esquema de stablecoin es inestable bajo condiciones razonablemente probables" no es nada como un error de lógica en el código. Aclarar esta confusión debería mejorar la apariencia de los documentos de auditoría y pulir la reputación del auditor.

Finalmente, los exchanges pueden ayudar con esto. Los grandes exchanges reciben muchas críticas por listar proyectos terribles, o memecoins de riesgo que fluctúan violentamente y cuestan dinero a la gente, o todo tipo de decisiones comerciales extrañas que infligen pérdidas. ¿Qué pasaría si los exchanges insistieran en auditorías razonables que cubran la estabilidad económica honestamente y no mezclen riesgos como "los smart contracts pueden ser vulnerables" con verificaciones de lógica reales?

Una forma de interpretar que un auditor rellene sus resultados con este tipo de relleno es que nadie tomará en serio un resultado de auditoría vacío. Es justo que tal documento plantee preguntas. Pero si un exchange importante listara un token con, digamos, dos resultados de auditoría "vacíos" coincidentes que no incluyeran problemas específicos del proyecto y tomara la posición de que esto era algo bueno... eso podría ayudar a mover un poco la pelota hacia adelante. También estamos en un punto del ciclo en el que ser un exchange más "honesto" y "razonable" debería conseguirte más clientes de lo que te cuesta la falta de marketing ridículo hasta la luna.

De manera similar, no debería haber estigma asociado con auditar un proyecto y decir que se ve bien. Este es responsabilidad de los auditores. Tal vez un grupo de auditores podría emitir algunas declaraciones conjuntas en esta área. Sí, podemos entender que los auditores querrán poner advertencias para problemas potenciales que quedaron fuera del alcance cuando comenzó el compromiso. También es justo. Pero rellenar resultados con problemas potenciales generales sin sentido no es la respuesta. Tampoco lo es decir que el equipo mitigó el riesgo de centralización haciendo una publicación de blog sobre la distribución de tokens que tienen la intención de resolver manualmente, pronto, en algún calendario que aún está por determinarse.

Las auditorías pueden ser útiles. Las auditorías pueden ayudar. Y la verdad es que las auditorías web3 han detectado problemas reales y, durante un período significativo de tiempo, estuvieron llenas de contenido útil e interesante. Pero los ingenieros han mejorado con el tiempo porque son, ya sabes, ingenieros y eso es lo que hacen. Los auditores necesitan mantener el ritmo y, para tomar prestada una palabra, innovar un poco. Y muchas partes más grandes del ecosistema, como los exchanges, también pueden ayudar a impulsar esto.