Cuándo ejecutar una regla en cadena
Un contrato inteligente tiene sentido para una regla que varios participantes independientes deban verificar por sí mismos. Puede controlar una transferencia, un derecho o el estado de un proceso común. Si un solo operador puede cambiar todas las entradas y salidas, el despliegue por sí solo apenas modifica la confianza. Primero identifique participantes, derechos, eventos comerciales y hechos que habrá que demostrar después. Compare la idea con una aplicación ordinaria provista de una buena pista de auditoría.
No toda regla pertenece a un entorno inmutable. Tarifas, textos o excepciones que cambian con frecuencia pueden necesitar gestión fuera del contrato y un proceso explícito de aprobación. Los datos del exterior requieren fuente fiable; un contrato no los verifica de modo independiente al grabarlos. Un diseño sólido mantiene estrecha la frontera entre cadena y aplicación, la hace comprensible y la justifica con un requisito concreto.
Especificación antes que código
El primer resultado es un modelo de estados: qué operación puede seguir a otra, quién puede iniciarla y qué ocurre si se rechaza. Una transferencia de valor puede requerir descripción de saldos, reservas, cancelación, plazos y contraparte que no coopera. Para las funciones indique quién las concede y quién revoca autoridad. Complete el texto con tabla de transiciones y ejemplos de llamadas erróneas. Así se revela si la interfaz propuesta representa el proceso comercial real.
Los invariantes son propiedades que deben mantenerse después de cada operación: por ejemplo una relación definida entre valor registrado y transferencias, o la imposibilidad de que una función no autorizada tome el control. Redactarlos mejora las pruebas y puede ayudar a una verificación más formal. Si el equipo no puede explicar un invariante al responsable de producto, no debería esconder su significado en detalles técnicos.
Accesos, gobierno y poderes de emergencia
Cualquiera con acceso a la red puede intentar llamar una función pública. Cada cambio de estado necesita comprobación explícita de permisos, validación de entrada y tratamiento del orden inesperado. Acciones privilegiadas como cambiar parámetros, actualizar o pausar requieren gobierno separado. Decida si proceden varias firmas, demora temporal o funciones distintas. Multiplicar firmas no basta si una persona las controla todas o falta un procedimiento ante pérdida de una clave.
Una pausa de emergencia puede limitar un defecto, pero concede poder considerable a sus operadores. Los usuarios deberían saber qué puede detenerse, qué queda disponible y cómo se reanuda el servicio. Considere también qué sucede si no es posible contactar a quien tiene autoridad: quién decide la reparación y cómo informa. El gobierno del contrato forma parte del producto y debe ser visible antes del despliegue.
Interacciones y fallos de seguridad habituales
El riesgo aparece en las fronteras: un contrato llama a otro, consume un precio externo o permite secuencias inesperadas. Orden entre actualización de estado y llamadas externas, aritmética, valores de retorno y lógica de negocio importan. Un escáner no conoce toda la intención comercial. El resumen público de riesgos de OWASP ayuda a ordenar el análisis, pero no sustituye revisar el flujo concreto de dinero y permisos.
Para cada flujo describa atacante, capacidades y motivación. ¿Puede alterar orden de transacciones, aportar datos retrasados, dividir una operación en varias llamadas o abusar de una clave de administración? Las pruebas también deben abarcar supuestos sobre integraciones e interfaz. Un contrato correcto no salva una aplicación que pide firmar una acción distinta de la mostrada al usuario.
Probar propiedades y no solo ejemplos
Las pruebas básicas cubren recorrido normal, entradas rechazadas y límites de cantidades. Las pruebas basadas en propiedades aportan más al explorar muchos órdenes, valores extremos y combinaciones de funciones. Cuando cambian reglas, conserve una batería de regresión ligada a invariantes. Una red de pruebas permite ensayar firma y despliegue reales, pero no reproduce todos los incentivos económicos ni las condiciones de producción.
Para contratos de alto riesgo pueden considerarse métodos más formales para propiedades concretas. La documentación de Ethereum presenta verificación formal como prueba de comportamiento frente a una especificación definida. La prueba vale tanto como sus hipótesis. Reserve tiempo para revisión independiente, corrección de hallazgos y nueva comprobación antes del despliegue. EXCOIN no afirma ser auditor independiente de su propio trabajo.
Actualizaciones y migración
Poder cambiar lógica después del despliegue es elección técnica y organizativa. Un contrato inmutable limita al administrador, pero dificulta arreglar errores. Un mecanismo de actualización facilita cambios mientras añade privilegios y riesgo de transición incorrecta. Explique quién propone, aprueba y verifica cada modificación y qué ocurre con compromisos previos. Los usuarios deberían saber si alguien puede modificar en el futuro reglas que aceptan hoy.
El plan de migración cubre compatibilidad de datos, direcciones antiguas, operaciones abiertas, historia accesible y regreso si falla el paso. Simule el cambio con un estado representativo antes de actuar en vivo. Los sistemas externos que consumen eventos deben reconocer nuevas versiones. Documentar la actualización protege a usuarios y aplicaciones conectadas; no es un anexo administrativo.
Despliegue, vigilancia y respuesta
Antes de desplegar, compruebe código exacto, configuración, red, direcciones de administradores y procedimiento de firma. Registre dirección resultante y código verificado para que otra persona determine qué funciona realmente. Vigile eventos críticos también fuera de la cadena: cambios de rol, volumen anómalo, pausas y fallos del indexador. Una alerta solo ayuda si alguien sabe qué acción debe seguirla.
Un plan de incidentes define quién puede pausar funciones, cómo se informa a usuarios, qué se puede restaurar y cuándo interviene un experto externo. Tras publicar, vigile nuevos hallazgos de bibliotecas y dependencias. Si la operación exige atención periódica, inclúyala en presupuesto y responsabilidades. Sería engañoso llamar al contrato libre de mantenimiento porque su bytecode permanece en cadena.
Una solicitud y entrega útiles
Para evaluar el proyecto describa participantes, valor o derecho que manejará el contrato, fuente de datos externos, volumen esperado y peor error aceptable. Señale si las reglas deben poder cambiar y quién gobernaría ese cambio. No es preciso imponer cadena o biblioteca. El proveedor debe examinar primero qué partes pueden permanecer fuera de cadena con más seguridad.
Una entrega clara incluye especificación de estados y funciones, código fuente, pruebas, procedimiento de despliegue, hipótesis, guía operativa y riesgos abiertos. Si se exige auditoría externa, defina autor independiente y alcance; la palabra seguro no la reemplaza. Antes de aceptar, determine quién custodia claves, vigila operación y tiene autoridad ante una emergencia.
¿Cómo saber si el contrato está listo para desplegarse? No basta con superar pruebas automáticas. El dueño de las reglas debe entender lo difícil de revertir, las excepciones que quedan fuera de cadena y quién tiene poderes administrativos. El equipo técnico debería presentar pruebas, hallazgos, correcciones y versión exacta del código. Operaciones debe saber reaccionar a una alerta y ensayar la pérdida de acceso. Si falta una respuesta, conviene retrasar el despliegue antes que trasladar incertidumbre a un sistema donde un error puede dañar a usuarios reales.
Publicar el código por sí solo no garantiza confianza. Permite examinarlo, pero los usuarios necesitan saber que coincide con la versión desplegada, comprender los privilegios y ver la operación real antes de firmarla. Estos controles unen decisiones técnicas, de producto y de operación.