Empiece por lo que promete el contrato
Un contrato inteligente puede controlar activos y sus errores suelen ser difíciles de corregir después de desplegarlo. La revisión debe empezar con un modelo conciso del comportamiento previsto, no con una búsqueda de patrones conocidos en el código. Describa actores, permisos, flujos de activos, reglas de cálculo y estados posibles. Para cada operación pública, indique entradas, efectos y condiciones en las que debe fallar. Sin especificación, se puede confirmar que el código es coherente consigo mismo sin descubrir que implementa una regla de producto equivocada.
Delimite exactamente el alcance: revisión del código, versión del compilador, dependencias, red y direcciones de contratos externos. Incluya scripts de despliegue, configuración inicial y componentes web o de servidor que preparan las llamadas. Una dirección equivocada, una suposición sobre decimales o un rol de administrador incorrecto puede tener el mismo efecto que un fallo en una transferencia. Congele un commit y enumere excepciones antes de la revisión. Un hallazgo sobre otra versión no prueba la seguridad del bytecode realmente publicado.
Escriba invariantes y límites de confianza
Un invariante es una propiedad que debe mantenerse a lo largo de secuencias de transacciones. Ejemplos: las obligaciones no superan los fondos que las respaldan, un usuario normal no cambia el destinatario de comisiones, una reclamación pagada no se paga dos veces y una pausa de emergencia no permite mover activos ajenos. Convierta estas frases en pruebas que exploren órdenes de acciones diversos, no solo rutas felices aisladas. Las recomendaciones de seguridad de Ethereum proponen combinar pruebas unitarias y basadas en propiedades. Una gran cobertura de líneas no demuestra que se eligieron las propiedades correctas.
Trace los límites de confianza con oráculos, puentes, otros contratos y operadores. Pregunte qué ocurre con datos antiguos o erróneos, llamadas externas fallidas o reglas modificadas por una contraparte. Un atacante puede influir en el orden de transacciones y crear estados ausentes de las pruebas manuales. Haga explícita cada suposición sobre fiabilidad de terceros. Si el producto no puede funcionar con seguridad sin un servicio, esa dependencia constituye una decisión empresarial y no debe ocultarse en el código.
Revise roles y custodia de claves
Cree una tabla de funciones privilegiadas: quién cambia parámetros, pausa operaciones, actualiza la implementación, retira comisiones o restablece el servicio. Verifique asignación inicial, transferencia y retirada de roles. Considere la pérdida o el compromiso de una clave autorizada. Un código técnicamente correcto controlado por una única clave de administrador desprotegida mantiene un riesgo operativo grave. Para cambios críticos, evalúe firmas múltiples, demoras y separación entre propuesta y aprobación.
Examine también el proceso fuera de cadena: custodios, copias de claves, acceso al entorno de despliegue y verificación de direcciones antes de firmar. Ensaye el reemplazo urgente del administrador en una red de prueba. Busque permisos temporales concedidos al desplegar y nunca revocados. Los eventos deben ayudar a distinguir cambios ordinarios de incidentes, pero el registro no sustituye a la autorización. Documente quién puede activar y revertir una pausa; un interruptor de emergencia sin operador disponible puede resultar inútil.
Llamadas externas y reentrada
La documentación de Solidity recomienda la secuencia comprobaciones, efectos e interacciones. Si el contrato envía valor o llama a otro antes de completar su propio cambio de estado, la contraparte puede entrar de nuevo en la función. Inspeccione todas las rutas de llamadas externas, incluidas bibliotecas, hooks de tokens y direcciones aparentemente conocidas. Una protección contra reentrada puede ayudar, pero no sustituye la contabilidad correcta de saldos y transiciones. Pruebe una contraparte que responda, revierta y trate de reentrar.
Examine también límites de gas, valores devueltos, fallos de transferencia y tokens no convencionales. No es seguro asumir que todos devuelven el booleano esperado o comparten precisión decimal. Las operaciones por lotes pueden sobrepasar el gas disponible y bloquear a todo el grupo. Combine importes normales, extremos y de frontera en las pruebas, prestando atención al redondeo. El tiempo y el orden de transacciones merecen revisión especial cuando alguien puede ganar económicamente por actuar antes. Registre el deslizamiento y plazo admisibles para acciones firmadas por usuarios.
Una actualización es más que un archivo nuevo
En contratos con proxy, incluya inicialización de la implementación, autoridad de actualización y compatibilidad del almacenamiento. OpenZeppelin explica que los proxies usan reglas de inicialización distintas de los constructores normales y que un cambio de disposición puede alterar los valores existentes. Compruebe cada versión propuesta con validación automática del almacenamiento y una prueba de migración sobre un estado representativo. Aunque no se permitan actualizaciones, el producto necesita un plan ante un defecto en lógica inmutable.
Antes de publicar una actualización, describa las diferencias de comportamiento y su efecto en activos de usuarios. Prepare aprobación, ventana temporal, vigilancia y posible retorno. Revertir no siempre es seguro: la implementación nueva puede haber escrito estados que la antigua no entiende. Simule toda la secuencia en un entorno aislado. Mantenga la interfaz sincronizada con la versión activa para que las personas no firmen una acción con significado diferente del que muestra la pantalla.
Combine clases de pruebas complementarias
Las pruebas unitarias verifican reglas concretas, las basadas en propiedades exploran combinaciones de entradas y estados, y las de integración unen contratos, oráculos y llamadas de usuarios. El análisis estático señala patrones sospechosos, pero cada hallazgo necesita contexto. Una salida limpia de la herramienta no prueba seguridad. Las pruebas de despliegue deben confirmar roles iniciales, configuración y bytecode publicado. Importan los casos negativos: llamadas no autorizadas, liquidación repetida, transacciones interrumpidas y datos inválidos de oráculos. Incluya fronteras de tiempo, redondeo y valores cero.
Cuando el valor expuesto o la complejidad sean elevados, encargue una revisión experta independiente con tiempo para corregir y verificar cambios. Ethereum recuerda que las auditorías no encuentran todos los errores; añaden otra capa de inspección. El informe debe identificar alcance, commit, gravedad, estado de remediación y riesgo residual. Decir solo «auditado» es publicidad, no prueba técnica. Tras la corrección, el revisor debe confirmar el código modificado. Una función añadida fuera del alcance original requiere nueva evaluación.
Prepare la operación posterior
La seguridad no termina con la publicación. Vigile cambios de roles, actualizaciones, volúmenes de transferencia anómalos, desviaciones del oráculo y fallos repetidos. Defina quién examina una alarma, quién puede pausar un componente y cómo se informa a los usuarios. Ensaye el mecanismo de emergencia, incluido el acceso a claves y el tiempo real necesario. El plan debe cubrir también el compromiso de un servicio externo o una interfaz engañosa. Ajuste las ventanas de observación a la red y al producto, sin depender de un panel genérico.
Durante un incidente conserve transacciones, versiones y decisiones relevantes. Evite una actualización improvisada sin comprobar efectos sobre el estado y las personas. Después añada una prueba que represente la causa y actualice el modelo de amenazas. EXCOIN puede ayudar con especificación, pruebas, integración y operación; una auditoría concreta y cualquier afirmación de seguridad deben corresponder siempre al código real, alcance y verificación independiente. El objetivo práctico es tener pruebas y riesgos reconocidos antes de firmar la transacción de despliegue. Registre el alcance exacto de cada revisión y compruebe de nuevo cualquier cambio posterior.