Desarrollo de smart contracts: qué cambia cuando el código guarda el dinero
El desarrollo de smart contracts es la práctica de escribir programas que se ejecutan en una blockchain y custodian valor real. A diferencia de un backend, el código desplegado no se puede parchear, todo su estado es público y cualquiera en el mundo puede invocarlo. Esas tres restricciones cambian todas las decisiones de ingeniería que vienen después.
Por qué no es desarrollo de backend
En un servicio normal despliegas, detectas un fallo y publicas el arreglo esa misma tarde. En cadena no hay esa tarde. El bytecode es inmutable una vez desplegado, así que un error es permanente salvo que diseñaras la vía de actualización antes de lanzar. Tampoco hay datos privados: las variables marcadas como private solo son invisibles para otros contratos, nunca para quien lee la cadena.
Y el modelo de amenaza está invertido. Un backend web asume que casi todo el tráfico es legítimo. Un contrato con fondos asume lo contrario: cada llamante es un adversario con incentivo económico para romperlo, y el exploit vale exactamente lo que custodias.
El stack, y por qué
- Solidity sobre Ethereum, sus L2 y sidechains — el mayor ecosistema de primitivas auditadas y probadas en producción. Construimos sobre OpenZeppelin Contracts en vez de reimplementar estándares como ERC-20. Reescribir un token desde cero no es artesanía, es superficie de ataque nueva.
- Solana cuando el rendimiento y las comisiones mandan en el diseño — otro modelo de cuentas y otro conjunto de compromisos. Ver la documentación de Solana.
- Foundry para las pruebas, porque los tests escritos en el propio Solidity permiten fuzzing y bifurcar mainnet. La referencia es el Foundry Book.
- Referencia del lenguaje: documentación de Solidity.
Elegir cadena es una decisión de negocio
| Si lo que importa es | Elección razonable |
|---|---|
| Componibilidad, liquidez, confianza institucional | Ethereum L1 |
| Mismo ecosistema con comisiones bajas | Una L2 (rollup) |
| Alto rendimiento, transacciones frecuentes y baratas | Solana |
| Control, privacidad, entorno regulado | Cadena privada o permisionada |
También hemos construido sobre la última: una blockchain privada que anonimizó transacciones para una fintech, y una plataforma de compensación de créditos de carbono para un banco suizo.
"Terminado" significa probado contra un adversario
Los tests unitarios solo demuestran que el contrato funciona cuando se usa bien. Esa es la mitad fácil. Lo que importa es el fuzzing (miles de entradas aleatorias buscando el caso que no imaginaste), el testing de invariantes (propiedades que deben cumplirse sea cual sea la secuencia de llamadas: que el suministro total nunca supere el tope, que nadie retire más de lo que depositó) y las pruebas sobre un fork del estado real de mainnet con protocolos reales.
La auditoría no es la última fase
Revisar la seguridad la semana antes de lanzar significa encontrar problemas de arquitectura cuando más caro es arreglarlos. Nosotros auditamos mientras construimos, y para eso hicimos Basalt: un equipo purple de agentes de IA, de código abierto, que demuestra cada hallazgo reproduciendo el exploit en un sandbox aislado, en lugar de entregar una lista de quizás.
Los contratos que no escribimos nosotros los auditamos como servicio externo. El código que gestiona dinero real se revisa antes de desplegarse — el nuestro incluido.