Qué te dice y qué no te dice una auditoría de contrato inteligente

«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 especificado de contratos en un commit especificado, durante un periodo especificado, buscando defectos frente a un modelo de amenazas especificado. La firma produce un informe que enumera los hallazgos por severidad, el proyecto responde y un informe final suele dejar constancia de qué se corrigió.

Cada aparición de «especificado» ahí está cumpliendo una función. El alcance se negocia, y un informe sobre tres contratos no dice nada del cuarto, el que guarda los fondos.

Lee primero el apartado de alcance

El alcance te dice qué archivos se revisaron y en qué hash de commit. De ahí salen dos preguntas, y ambas se pueden responder en unos 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 contra 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 esa brecha, y rara vez la hace quien lee el distintivo.

Los hallazgos y su resolución

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

«Reconocido» significa que el proyecto leyó el hallazgo y optó por no cambiar nada. Eso puede ser del todo razonable — el hallazgo puede describir una contrapartida aceptada — pero significa que hay un problema conocido en producción, y no aparecerá en un resumen que solo informa del 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 malas 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, donde los incentivos que crea son explotables. Esto exige modelar la economía del sistema, que es una disciplina distinta y con frecuencia queda fuera del alcance.
• Componibilidad. Un contrato puede ser sólido por sí solo e inseguro al combinarse con otro protocolo que nadie previó.
• Supuestos del oráculo. 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.

Este último 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 sustituirla. Lo que importa entonces es quiénes son esas personas y qué proceso las gobierna — una cuestión de gobernanza vestida de distintivo técnico.

Qué aspecto tiene un buen informe

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

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

Cómo usar una

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 contiene suele decirlo de forma explícita, en el apartado que nadie cita.

Las preguntas prácticas siguen siendo: ¿qué proporción de tus tenencias está expuesta a este contrato, podrías tolerar perderla y es el rendimiento ofrecido plausiblemente una compensación por ese riesgo? La presencia de un informe no las altera, que es exactamente por lo que el distintivo se usa como se usa.

No todas las revisiones tienen la misma profundidad

«Auditoría» cubre un abanico de actividades con costes y rigor muy distintos, y el informe no siempre deja la distinción a la vista.

Una revisión manual a cargo de profesionales de ingeniería con experiencia 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 satisface una especificación, lo cual es potente y tan bueno como la especificación. Las plataformas de auditoría competitiva reparten la revisión entre una multitud, lo que encuentra un abanico amplio de problemas pero produce una cobertura menos consistente.

Cada una tiene su papel. Lo que importa es saber cuál estás mirando, y el apartado de metodología lo dice. Un informe que no describe su método está pidiendo que se le crea por la fuerza del logotipo.

Los programas de recompensas por errores dicen algo que un informe no puede

Una auditoría es una instantánea; un programa de recompensas es continuo. Un proyecto que mantiene un programa sustancial y bien delimitado con un historial público de pagos está expuesto a un escrutinio continuo que una revisión puntual no proporciona.

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

El tiempo en producción también es prueba

Los contratos que han custodiado un valor significativo durante mucho tiempo sin incidentes han pasado por la revisión más rigurosa disponible: la atención sostenida de gente con motivación financiera para romperlos.

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

Combinar ambas cosas es el enfoque práctico: lee el informe por lo que se examinó y sopesa el historial de despliegue por lo que el informe no pudo cubrir.