Certificación de smart contracts: qué demuestra una auditoría

Los contratos inteligentes ejecutan las reglas de una aplicación blockchain, desde una transferencia hasta la gestión de permisos sobre un activo. Cuando esas reglas van a utilizarse en un producto, el equipo necesita comprobar que el código responde al funcionamiento previsto. Las auditorías y otras revisiones técnicas aportan evidencia para ese trabajo.

El término certificación puede referirse a servicios y documentos con alcances distintos. Para entender qué acredita una revisión, hay que conocer la versión analizada, las pruebas realizadas y las correcciones verificadas. Esos datos permiten interpretar el informe sin atribuirle una garantía general de seguridad.

¿Certificación y auditoría significan lo mismo?

En proyectos blockchain se utiliza a veces «certificación» para referirse a un informe de auditoría. Conviene pedir el alcance concreto: una revisión de código no equivale por sí sola a una homologación regulatoria ni garantiza que un sistema esté libre de vulnerabilidades. Si existe un esquema de certificación aplicable, deben identificarse la entidad, el estándar, la versión evaluada y sus condiciones.

Una auditoría analiza una versión determinada del software y documenta hallazgos y limitaciones. Su valor está en la evidencia que aporta y en cómo se resuelven los problemas detectados. Un sello sin informe, fecha o referencia al código permite comprobar muy poco.

Qué debe revisar una auditoría de smart contracts

La revisión empieza por las reglas del producto: quién puede emitir, transferir, retirar o bloquear activos; qué debe permanecer cierto después de cada operación; y qué ocurre si una dependencia deja de responder. Después se contrasta esa especificación con el código.

• Control de acceso: roles, administradores y permisos de actualización.
• Interacciones externas: reentrada, oráculos, tokens ajenos y llamadas que pueden fallar.
• Contabilidad: redondeos, límites, saldos y condiciones de liquidación.
• Operación: configuración del despliegue, custodia de claves y respuesta ante incidentes.

Las consideraciones de seguridad de Solidity explican riesgos como la reentrada y los límites de gas. Ayudan a construir pruebas, pero una lista de fallos conocidos no sustituye el análisis de la lógica particular del negocio.

Inmutabilidad y contratos actualizables

El código desplegado en una dirección no se modifica como un archivo de servidor. Sin embargo, una aplicación puede usar proxies que delegan en otra implementación o incluir funciones de pausa y administración. La guía de actualización de Ethereum describe estos patrones y sus compromisos.

Por eso hay dos preguntas distintas: si el código examinado tiene defectos y si alguien puede cambiar después el comportamiento del sistema. Revisar solo la implementación y omitir el proxy, los permisos o el proceso de gobierno deja fuera una parte importante del riesgo.

Qué pedir al equipo auditor

Pide un informe vinculado a un commit del repositorio y a una configuración de compilación reproducible. Debe identificar el alcance, las exclusiones, la metodología, la severidad de los hallazgos y su estado tras la corrección. Comprueba después que el despliegue corresponde a la versión revisada.

Las pruebas unitarias, el fuzzing y las comprobaciones de invariantes aportan evidencias complementarias. La revisión independiente puede descubrir supuestos que el equipo implementador no cuestionó. Ninguna técnica cubre por sí sola todos los errores económicos, operativos o de integración.

Cómo leer un hallazgo y su corrección

Como ejemplo hipotético, un informe puede detectar que una cuenta operativa también tiene permiso para cambiar al administrador. El hallazgo debe explicar la condición que lo permite, el impacto y el código afectado. Su severidad depende del contexto: no se interpreta igual una función de una red de ensayo que un permiso activo en un contrato que custodia fondos.

Después de corregirlo, hay que revisar el cambio y comprobar que la configuración de despliegue deja los roles previstos. Si el equipo elimina el permiso de una función pero otra cuenta puede concedérselo de nuevo, el riesgo puede seguir existiendo por un camino distinto. La evidencia de cierre debe cubrir el escenario identificado.

Un estado de «aceptado» tampoco significa «resuelto». Puede indicar que el equipo reconoce un riesgo y decide mantenerlo. El lector del informe necesita entender esa decisión, sus mitigaciones y quién la asume. Comparar proveedores por número de hallazgos o por ausencia de incidencias críticas, sin considerar alcance y versión, puede llevar a conclusiones equivocadas.

La entrega más útil conecta cada hallazgo con su respuesta, revisión posterior y código desplegado. Esa relación permite decidir qué cambios requieren otra evaluación y evita que un informe antiguo se utilice como aval de una versión distinta.

Qué queda fuera del código

Un contrato puede registrar un pago o un derecho declarado por un emisor; no transfiere por sí solo la titularidad jurídica de un coche o inmueble. La documentación, el registro aplicable y las obligaciones de las partes siguen formando parte del producto. Tampoco un oráculo demuestra automáticamente que el dato recibido sea verdadero.

Antes del lanzamiento, conviene cerrar hallazgos, probar recuperación e incidentes y asignar responsables de monitorización. Los cambios materiales posteriores requieren revisar de nuevo el alcance afectado. En Metlabs abordamos el desarrollo de contratos inteligentes junto con sus permisos, integraciones y operación, para que la revisión evalúe el sistema que realmente se pondrá en producción.