Lo que una auditoría de contratos inteligentes te dice, y lo que no

“Auditado” aparece en las páginas de aterrizaje como si fuera una certificación con un significado definido. No lo es. Es un servicio profesional de alcance variable, y la diferencia entre una revisión exhaustiva y una superficial es invisible desde el distintivo.

Qué es en realidad una auditoría

Se contrata a una firma para revisar un conjunto determinado de contratos, en un commit determinado, durante un periodo determinado, buscando defectos frente a un modelo de amenazas determinado. Producen un informe que enumera los hallazgos por gravedad, el proyecto responde, y un informe final suele recoger qué se corrigió.

Cada “determinado” de ese párrafo cumple una función. El alcance se negocia, y un informe sobre tres contratos no dice nada del cuarto, que es el que guarda los fondos.

Lee primero el apartado de alcance

El alcance indica qué archivos se revisaron y en qué hash de commit. De ahí surgen dos preguntas, y ambas se responden en pocos minutos.

¿Incluye el alcance los contratos que realmente guardan o mueven valor, o solo los periféricos? ¿Y coincide el commit revisado con lo que está desplegado? El código cambia después de una auditoría, y un informe sobre un commit anterior a varias actualizaciones describe un software que ya no existe. Verificar el bytecode desplegado frente al código fuente auditado es la comprobación que cierra esta brecha, y casi nadie que se fija en el distintivo la hace.

Los hallazgos y su resolución

Los informes clasifican los hallazgos por gravedad. Lo que importa más que el recuento es la resolución: corregido, reconocido o disputado.

“Reconocido” significa que el proyecto leyó el hallazgo y decidió no cambiar nada. Eso puede ser perfectamente razonable —el hallazgo puede describir una concesión aceptada—, pero significa que hay un problema conocido activo, y no aparecerá en un resumen que solo menciona el distintivo.

Un informe sin ningún hallazgo no es un triunfo. Normalmente significa un alcance estrecho o una revisión superficial. Las revisiones competentes de sistemas no triviales encuentran cosas.

En qué son estructuralmente flojas las auditorías

Ciertas categorías son difíciles de detectar revisando código:

• Fallos de diseño económico. Código que se comporta exactamente como está escrito, pero cuyos incentivos son explotables. Esto exige modelar la economía del sistema, una disciplina distinta que a menudo queda fuera del alcance.
• Composabilidad. Un contrato puede ser sólido por sí solo e inseguro al combinarse con otro protocolo que nadie previó.
• Supuestos sobre oráculos. Los contratos que dependen de datos de precio externos heredan la fiabilidad de esos datos, y el oráculo suele quedar fuera del alcance.
• Gobernanza y claves. Un contrato actualizable controlado por una multifirma pequeña tiene un riesgo que ninguna revisión de código aborda, porque el código permite la actualización por diseño.

Ese último punto merece énfasis. Si un contrato se puede actualizar, la auditoría describe la implementación actual, y quienes tienen las claves de actualización pueden reemplazarla. Lo que importa entonces es quiénes son esos titulares y qué proceso los rige —una cuestión de gobernanza disfrazada de distintivo técnico.

Cómo es un buen informe

Publicado íntegro, no resumido. Alcance indicado con hashes de commit. Hallazgos con gravedad, descripción y resolución. Un apartado de metodología que describe qué se examinó y qué no. Y una fecha, para poder compararlo con el historial de despliegues.

Un proyecto que publica todo eso está haciendo algo claramente distinto de uno que solo muestra un logotipo. El logotipo es la parte que menos cuesta.

Cómo usar una auditoría

Trata una auditoría como prueba de que un proyecto gastó dinero en escrutinio y estuvo dispuesto a publicar el resultado, lo cual es una señal real sobre cómo opera. No la trates como una garantía de seguridad, porque el informe no pretende serlo —el descargo de responsabilidad que incluye suele decirlo explícitamente, en el apartado que nadie cita.

Las preguntas prácticas siguen ahí: qué proporción de tus tenencias está expuesta a este contrato, si podrías tolerar perderla, y si el rendimiento ofrecido compensa razonablemente ese riesgo. Nada de eso cambia por la existencia de un informe, y por eso precisamente se usa el distintivo como se usa.

No todas las revisiones tienen la misma profundidad

“Auditoría” abarca un abanico de actividades con costes y rigor muy distintos, y el informe no siempre deja clara la diferencia.

Una revisión manual por ingenieros experimentados que leen el código es el extremo caro. El análisis automatizado detecta patrones conocidos de forma barata y se le escapa cualquier cosa novedosa. La verificación formal demuestra matemáticamente que el código cumple una especificación, lo cual es potente y solo tan bueno como la especificación en sí. Las plataformas de auditoría competitiva externalizan la revisión a la multitud, lo que encuentra una gran variedad de problemas pero produce una cobertura menos uniforme.

Cada una tiene su función. Lo que importa es saber cuál tienes delante, y el apartado de metodología lo indica. Un informe que no describe su método está pidiendo que se le crea por la fuerza del logotipo.

Los programas de recompensas dicen algo que un informe no puede

Una auditoría es una fotografía; un programa de recompensas es continuo. Un proyecto que mantiene una recompensa sustancial y bien delimitada, con un historial de pagos público, está sometido a un escrutinio permanente que una revisión puntual no ofrece.

El importe importa. Un pago máximo muy por debajo de lo que rendiría un exploit no es un incentivo, es un gesto: un investigador que encuentra un fallo crítico en un contrato que guarda una suma grande se enfrenta a un problema aritmético obvio si la recompensa es insignificante en comparación. Las recompensas proporcionales al valor en riesgo son una señal genuina de cuán en serio se toma un proyecto la posibilidad de estar equivocado.

El tiempo en producción también es una prueba

Los contratos que han guardado un valor significativo durante un periodo largo sin incidentes han sido sometidos a la revisión más rigurosa disponible: la atención sostenida de personas con un incentivo económico para romperlos.

Esto no es una prueba definitiva —existen fallos latentes, y varios protocolos longevos han fallado tarde. Pero un contrato desplegado hace poco, con un informe y sin historial operativo, solo ha sido revisado por una firma durante unas semanas. Uno más antiguo con el mismo informe ha sobrevivido además años de interés adversario, y eso es un tipo de prueba distinto.

Combinar ambas cosas es el enfoque práctico: lee el informe para saber qué se examinó, y valora el historial de despliegue para lo que el informe no pudo cubrir.