O whitepaper do Ethereum e o EVM

Curiosidade

1. Por que um computador replicado em milhares de máquinas precisa cobrar por cada instrução?
2. O que se quebra se o código rodando nessas máquinas puder entrar em um ciclo infinito sem consequências?
3. Como dois modelos de conta diferentes — UTXOs e saldos no local — podem representar a mesma riqueza de maneiras distintas?

Explorar

1. Vitalik Buterin, então com dezenove anos, redigiu o white paper do Ethereum no final de 2013, propondo uma plataforma de computação de uso geral em vez de uma moeda específica. O projeto, anunciado publicamente em janeiro de 2014, reuniu cofundadores como Gavin Wood, Joseph Lubin, Charles Hoskinson, Anthony Di Iorio e Mihai Alisie. Uma venda coletiva foi realizada de julho a agosto de 2014, arrecadando aproximadamente 31.500 BTC para o empreendimento. A rede foi lançada oficialmente em 30 de julho de 2015, marcando uma mudança em relação ao sistema limitado de scripts do bitcoin, rumo a um ambiente totalmente programável no qual os desenvolvedores podiam criar aplicativos complexos diretamente na cadeia.
2. O núcleo dessa arquitetura é a Máquina Virtual Ethereum (EVM), uma máquina de estados completa de Turing replicada em todos os nós completos. Diferentemente do modelo UTXO do Bitcoin, que rastreia saídas individuais não gastas, o Ethereum utiliza um modelo de conta no qual os saldos são atualizados diretamente. Cada conta – seja controlada por uma chave privada ou por código – mantém um nonce e um saldo. Quando uma transação é executada, a EVM a processa de forma determinística; cada nó calcula o mesmo resultado por conta própria, garantindo consenso sem a necessidade de confiança entre os participantes.
3. Contratos inteligentes são programas escritos em linguagens de alto nível como Solidity, que são compilados em códigos operacionais de baixo nível executados pela EVM. Esses contratos armazenam valor e lógica simultaneamente. Um contrato pode reter ether, executar transações condicionais ou gerenciar votos de governança com base em entradas de outras contas. Como a execução é determinística e muitos contratos publicam seu código-fonte, qualquer pessoa pode verificar sua lógica antes de interagir com ele. Essa transparência elimina a necessidade de intermediários confiáveis em muitas aplicações financeiras, já que as regras são aplicadas por software, e não pela discricionariedade humana.
4. Para evitar loops infinitos e ataques de negação de serviço, toda operação EVM consome “gás”, uma unidade de computação paga em ether. O remetente especifica um limite de gás antecipadamente; se a execução esgotar esse recurso, as alterações no estado são revertidas, mas o gás consumido ainda é deduzido. Essa restrição econômica obriga os desenvolvedores a escreverem código eficiente e protege a rede de contratos maliciosos ou com erros que poderiam congelar a cadeia. Os preços do gás sobem e descem conforme a demanda; inicialmente, os usuários simplesmente faziam lances, mas, desde 2021, uma taxa básica definida por protocolo é ajustada automaticamente, com gorjetas adicionais (um tópico abordado posteriormente).
5. As escolhas de design no EVM refletem um trade-off entre expressividade e segurança. A completude de Turing permite cálculos arbitrários, mas introduz complexidade que pode abrigar vulnerabilidades. O modelo de conta torna alguns programas mais simples do que os UTXOs, mas contratos que se chamam mutuamente precisam ser escritos com cuidado para evitar erros como reentrância, a falha por trás do hack da The DAO (uma lição posterior). Essa padronização permite um vasto ecossistema de ferramentas e auditores familiarizados com o conjunto específico de instruções.
6. Abra um explorador de blocos como o Etherscan e inspecione qualquer transação recente que tenha implementado um contrato inteligente. Observe o status de “Criação do Contrato” e o gás utilizado em comparação com o limite de gás. Note como os dados de entrada da transação contêm o bytecode compilado, armazenado no novo endereço. Este passo concreto revela a realidade mecânica da implementação: o código é carregado, verificado por todos os nós e fixado na máquina de estados da cadeia, pronto para execução em futuras interações.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• 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'