El whitepaper de Ethereum y la EVM

Curiosidad

1. ¿Por qué una computadora replicada en miles de máquinas necesita cobrar por cada instrucción?
2. ¿Qué se rompe si el código que se ejecuta en esas máquinas puede iterar eternamente sin consecuencias?
3. ¿Cómo pueden dos modelos de cuentas distintos —UTXO y saldos en su lugar— representar la misma riqueza de manera diferente?

Explorar

1. Vitalik Buterin, que en ese entonces tenía diecinueve años, redactó el documento técnico de Ethereum a finales de 2013, proponiendo una plataforma de cómputo de uso general en lugar de una moneda específica. El proyecto, anunciado públicamente en enero de 2014, reunió a cofundadores como Gavin Wood, Joseph Lubin, Charles Hoskinson, Anthony Di Iorio y Mihai Alisie. Se llevó a cabo una venta colectiva de julio a agosto de 2014, que permitió recaudar aproximadamente 31,500 BTC para el proyecto. La red se lanzó oficialmente el 30 de julio de 2015, marcando un cambio con respecto al sistema limitado de scripting de Bitcoin hacia un entorno completamente programable donde los desarrolladores podían crear aplicaciones complejas directamente en la cadena.
2. El núcleo de esta arquitectura es la Máquina Virtual Ethereum (EVM), una máquina de estados Turing-completa que se replica en cada nodo completo. A diferencia del modelo UTXO de Bitcoin, que registra las salidas no gastadas individuales, Ethereum emplea un modelo de cuentas en el que los saldos se actualizan directamente. Cada cuenta, ya sea controlada por una clave privada o por código, mantiene un nonce y un saldo. Cuando se ejecuta una transacción, la EVM la procesa de manera determinística; cada nodo calcula el mismo resultado por sí mismo, lo que garantiza el consenso sin necesidad de confianza entre los participantes.
3. Los contratos inteligentes son programas escritos en lenguajes de alto nivel como Solidity que se compilan en códigos opcodes de bajo nivel ejecutados por la EVM. Estos contratos albergan tanto valor como lógica al mismo tiempo. Un contrato puede retener ether, ejecutar transacciones condicionales o gestionar votos de gobernanza basándose en entradas de otras cuentas. Dado que su ejecución es determinista y muchos contratos publican su código fuente, cualquiera puede verificar su lógica antes de interactuar con ellos. Esta transparencia elimina la necesidad de intermediarios de confianza en muchas aplicaciones financieras, ya que las reglas son aplicadas por software y no por la discreción humana.
4. Para evitar bucles infinitos y ataques de denegación de servicio, cada operación EVM consume “gas”, una unidad de cálculo que se paga en ether. El remitente especifica un límite de gas por adelantado; si la ejecución agota este recurso, los cambios de estado se anulan, pero el gas consumido sigue descontándose. Esta restricción económica obliga a los desarrolladores a escribir código eficiente y protege la red de contratos maliciosos o con errores que podrían congelar la cadena. Los precios del gas suben y bajan según la demanda; inicialmente los usuarios simplemente hacían ofertas, pero desde 2021 una tarifa base establecida por el protocolo se ajusta automáticamente, a la cual se añaden propinas (lección posterior).
5. Las decisiones de diseño de la EVM reflejan un equilibrio entre expresividad y seguridad. La completitud de Turing permite cálculos arbitrarios, pero introduce una complejidad que puede albergar vulnerabilidades. El modelo de cuentas hace que algunos programas sean más simples que con UTXO, pero los contratos que se invocan mutuamente deben escribirse con cuidado para evitar errores como la reentrada (reentrancy), el defecto detrás del hackeo de The DAO (una lección posterior). La estandarización de la EVM permite un vasto ecosistema de herramientas y auditores familiarizados con su conjunto específico de instrucciones.
6. Abra un explorador de bloques como Etherscan e inspeccione cualquier transacción reciente que haya desplegado un contrato inteligente. Observe el estado de “Creación del contrato” y la cantidad de gas utilizada en comparación con el límite de gas. Note cómo los datos de entrada de la transacción contienen el bytecode compilado que se almacena en la nueva dirección. Este paso concreto revela la realidad mecánica del despliegue: el código se carga, es verificado por cada nodo y se fija en la máquina de estados de la cadena, listo para su ejecución en futuras interacciones.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• V. Buterin, 'Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform' (2013/2014)
• G. Wood, 'Ethereum: A Secure Decentralised Generalised Transaction Ledger' (Yellow Paper, 2014)
• ethereum.org, 'History of Ethereum'