Qué hacer en las dos semanas previas a una auditoría de contratos

Una auditoría tiene un presupuesto fijo de atención del auditor. Cada hora dedicada a averiguar qué se supone que hace una función es una hora que no se dedica a buscar el fallo que tiene dentro. Prepararse no va de quedar bien: va de redirigir esa atención hacia el código que puede perder dinero.

Esto es lo que merece la pena hacer en las dos semanas previas al arranque.

Congela el código

Lo más caro que puedes hacer es seguir commiteando durante la auditoría. Cada cambio invalida trabajo ya hecho y obliga a revisar de nuevo todo lo que dependa de él.

Etiqueta el commit que entregas. Si aparece un fallo crítico a mitad de auditoría, corrígelo en una rama y acuerda con el auditor cuándo se incorpora. No hagas push a la rama auditada porque se ha quejado el linter.

Escribe qué se supone que hace el sistema

Los auditores encuentran fallos comparando la intención con la implementación. Sin una intención declarada, solo pueden encontrar lo que está mal de forma evidente: reentrada, desbordamiento, control de acceso ausente. Los fallos sutiles, esos en los que el código hace exactamente lo que está escrito y la lógica es incorrecta, son invisibles sin una especificación.

Lo que merece la pena entregar:

• Los roles y qué puede hacer cada uno. Cada función privilegiada, quién puede llamarla y qué ocurre si esa clave se ve comprometida.
• Los invariantes. Afirmaciones que deben cumplirse siempre: el total de participaciones es igual a la suma de saldos, el pool nunca puede pagar más de lo que tiene, un mercado no puede liquidarse dos veces.
• Los caminos del dinero. Todas las formas en que el valor entra y sale del sistema, dibujadas como diagrama si es posible.
• De qué decidiste deliberadamente no protegerte. Si aceptas el riesgo de un oráculo malicioso porque el oráculo eres tú, dilo. Si no, el auditor lo redacta como hallazgo y los dos perdéis tiempo con ello.

Haz que las pruebas digan la verdad

El porcentaje de cobertura no significa casi nada: una prueba que llama a una función y no comprueba nada cuenta como cubierta. Lo que importa es si las pruebas codifican los invariantes de arriba.

Antes de la auditoría: deja toda la suite en verde, borra o arregla las pruebas saltadas y añade una prueba de fuzzing o de invariante para cada invariante de los caminos del dinero. Si una propiedad merece enunciarse, merece que el fuzzer la ataque un rato.

Limpia tú los hallazgos obvios

Todo informe de auditoría tiene una sección de hallazgos de severidad baja que un analizador estático habría detectado. Pasa Slither, compila con todos los avisos activados y corrige o justifica explícitamente cada resultado. Estás pagando tarifas de ingeniero senior; no las gastes en imports sin usar y eventos sin emitir.

Prepara la historia del despliegue

Una proporción sorprendente de los incidentes reales viene de los caminos de despliegue y actualización, no de la lógica del contrato. Ten listos: la secuencia exacta de despliegue, los parámetros de inicialización, quién guarda cada clave, si los contratos son actualizables y cuál es el procedimiento de actualización. Si hay un proxy, el auditor necesita el diseño del almacenamiento.

La resolución es la parte difícil de un mercado de predicción

Cuando llega el informe

Corrige los hallazgos en una rama y escribe una respuesta a cada uno, incluidos los que no vas a corregir. «Reconocido, riesgo aceptado, y este es el motivo» es una respuesta legítima y luce mucho mejor que un hallazgo ignorado en silencio.

Después, haz que revisen las correcciones. Una corrección sin revisar de un hallazgo crítico es un futuro hallazgo crítico: los parches escritos con la fecha encima son justo el código que necesita un segundo par de ojos.