Desarrollo para Ethereum (EVM)

La máquina virtual de Ethereum (EVM) es el entorno de ejecución que comparten Ethereum y decenas de redes: Arbitrum, Base, Polygon, Optimism o BNB Chain. Elegirla es entrar en el ecosistema con las herramientas más maduras, más auditores disponibles y las carteras que tus usuarios ya tienen instaladas.

Se traduce en tres ventajas concretas: los estándares ya están escritos, el talento existe y la infraestructura de terceros está integrada.

Cuándo no tiene sentido. Si necesitas datos personales en cadena, confidencialidad entre participantes o miles de operaciones por segundo, una red pública EVM no es la respuesta: ahí planteamos una red permisionada o descartamos blockchain. Decirlo antes de firmar ahorra presupuesto.

La red condiciona el coste por operación, el tiempo hasta que una transacción es irreversible y la complejidad de mover fondos. Tres criterios:

• Coste de gas. La mainnet de Ethereum es la opción cara y la que menos supuestos exige. Un rollup como Arbitrum o Base reduce el coste por transacción en órdenes de magnitud, a cambio de confiar en su secuenciador.
• Finalidad. Una confirmación rápida en un L2 no equivale a finalidad en Ethereum: en los rollups optimistas la ventana de retirada al L1 se mide en días. Si liquidas contra un banco o un registro, ese detalle entra en el diseño desde el primer día.
• Puentes. Cada puente añade superficie de ataque. Preferimos el puente canónico de la red antes que puentes de terceros y reducimos al mínimo los saltos entre cadenas.

Escribimos en Solidity y partimos de OpenZeppelin para lo que ya está resuelto y revisado: control de acceso por roles, pausado de emergencia, implementaciones de ERC-20, ERC-721 y ERC-1155. El código propio queda para la lógica de negocio, que es donde merece la pena revisar línea a línea.

El entorno es Foundry (tests en Solidity, fuzzing, invariantes y medición de gas), con Hardhat cuando hacen falta scripts en TypeScript. Todo contrato pasa por tests unitarios, pruebas contra un fork de la red real y análisis estático antes de acercarse a un despliegue.

Un aviso que damos siempre: el estándar del token no determina su naturaleza jurídica. Un ERC-20 puede ser un criptoactivo bajo MiCA o un instrumento financiero sujeto a la LMVSI y a MiFID II, con obligaciones distintas. Conviene cerrar esa clasificación antes de fijar suministro y permisos; el clasificador MiCA/MiFID da una primera orientación.

Un contrato desplegado ya no se parchea a la ligera. El gobierno del sistema se decide antes de escribirlo:

• Actualizabilidad. Proxy UUPS o transparente si el producto va a evolucionar; contrato inmutable si el compromiso es que nadie pueda cambiar las reglas.
• Claves y permisos. Las funciones privilegiadas se firman desde un multisig, nunca desde una clave individual, y los cambios sensibles pasan por un timelock que da margen de reacción.
• Frenos. Pausa de emergencia, límites por operación y separación entre el contrato que custodia fondos y el que ejecuta la lógica.

Antes de mainnet, revisión externa: para cualquier sistema que custodie valor recomendamos una auditoría de smart contracts hecha por alguien distinto de quien escribió el código.

El despliegue se ejecuta con scripts versionados y reproducibles, no a mano desde una consola. El código se verifica en el explorador de cada red para que cualquiera pueda cotejar el bytecode publicado con el fuente.

Al cerrar el proyecto recibes:

• Repositorio con contratos, tests y scripts de despliegue.
• Direcciones y código verificado en cada red, con los hashes de las transacciones de despliegue.
• Documento de arquitectura: roles, funciones privilegiadas y procedimiento de actualización y de pausa.
• Monitorización de eventos y alertas sobre las funciones críticas, con el runbook de respuesta.

La monitorización no es opcional: un contrato sin vigilancia solo avisa cuando el daño ya está hecho.