TECNOLOGÍAS

Smart Contract

Código que corre en una blockchain, se ejecuta de forma determinista y, una vez desplegado, no se puede cambiar (a menos que se diseñe para poder hacerlo).

Última revisión: porKevin Riedl wiki ↗

Un smart contract es un programa desplegado en una blockchain. Una vez desplegado, su bytecode es inmutable, su estado público y su ejecución se rige por reglas de consenso que nadie puede saltarse. Esa permanencia es feature y riesgo a la vez: un bug en producción es un bug para siempre, salvo que metas mecanismos de upgrade (que en sí son superficie de vulnerabilidad).

La mayoría de sistemas de smart contracts en producción no son un solo contract sino un conjunto: un proxy para upgradeability, un contract de implementación para la lógica y, a menudo, un contract de access-control para gobernanza. El patrón es familiar para quien haya versionado APIs; el coste del error es mayor.

Ejemplo de por qué la disciplina de despliegue difiere del software normal: envía un bug en un backend SaaS y lo parcheas y redespliegas en una hora. Envía un bug de reentrancy en un contract que custodia fondos de usuarios y un atacante puede vaciarlo antes de que reacciones, porque no hay rollback y el valor está vivo desde el bloque uno. Por eso la pregunta no es «¿deberíamos auditar?» sino «¿cómo estructuramos los upgrades de forma segura?». La respuesta habitual es un patrón proxy tras un timelock y un multisig: la autoridad de upgrade inmediata es un punto único de fallo, no tener camino de upgrade te deja atrapado con el primer bug, y los upgrades con timelock transparentes para los usuarios son el punto medio al que converge la mayoría de los sistemas en producción.

El trade-off honesto y el error de founder común: los founders tratan el contract como una feature y la auditoría como una línea opcional. Para cualquier contract que custodia valor no trivial, la auditoría es el seguro más barato que comprarás, normalmente 1 a 2 semanas del presupuesto del build contra todo el valor en juego. Wavect escribe smart contracts en Solidity para chains EVM y Rust para Solana, Near e ICP, y el lenguaje es consecuencia de qué chain exige tu caso de uso web3, no una preferencia. Recomendamos auditoría externa antes de mainnet en cualquier cosa que importe, y hemos entregado contracts auditados a producción. Saltarse la auditoría es como los equipos aprenden esto por las malas.

// FAQ

Preguntas frecuentes

Para cualquier contract que custodia valor no trivial, sí. Para un NFT mint sencillo o un experimento testnet, no. La regla práctica: si el TVL esperado supera el coste de auditoría (1 a 2 semanas de presupuesto del build, normalmente 15.000 a 50.000 EUR), audita. Si no, mantén el alcance pequeño y úsalo como aprendizaje, no como producción.
Inmutable cuando puedes y la lógica está bien acotada. Los proxies upgradeables añaden superficie de ataque (claves de admin, riesgo de governance), y la promesa «lo arreglamos si hay un bug» se convierte en «somos un punto único de fallo». Si necesitas evolución, considera contratos modulares y deploy-then-deprecate en vez de upgrade.
Porque es público, irreversible y muchas veces explotable de forma atómica. Un atacante puede vaciar el contract antes de que reacciones. Las herramientas de pause y los bug bounties ayudan, pero no sustituyen un código que ya esté correcto al momento de desplegar. La prevención sale infinitamente más barata que el incidente.