A Máquina Virtual Ethereum, ou EVM, é o ambiente de execução dos contratos inteligentes do Ethereum. Para entender sua função, acompanhe três ideias conectadas: o contrato contém bytecode compilado, a EVM executa esse código como instruções e o estado do Ethereum muda conforme regras definidas. O gas mede o trabalho computacional e limita quanto uma transação pode consumir.
Essa descrição explica a execução sem prometer que uma aplicação atingirá o resultado pretendido. As perguntas úteis são: qual código é executado, quais informações armazenadas estão envolvidas e o que acontece se o orçamento de execução acabar?
O que a Máquina Virtual Ethereum executa
Um bom ponto de partida é distinguir o programa de seu ambiente de execução. O contrato inteligente fornece o código; a EVM fornece as regras para executá-lo. A documentação da EVM descreve contas de contrato que contêm bytecode compilado. Quando outra conta faz uma chamada ao contrato, esse bytecode é executado.
Bytecode é a forma compilada do programa do contrato. Sua execução ocorre por meio de instruções da EVM chamadas opcodes. Pense no bytecode como o programa codificado e nos opcodes como as instruções individuais que realizam seu trabalho. Para quem está começando, compreender essa relação é mais útil do que decorar uma lista de instruções.
Ao ler uma explicação sobre um contrato, separe a finalidade descrita em linguagem comum do código compilado que será executado. Dizer que um contrato serve para registrar um valor descreve seu propósito. Explicar quais instruções são executadas e qual valor fica armazenado trata de seu comportamento.
A EVM não é uma carteira nem o algoritmo de consenso do Ethereum. Sua função aqui é executar contratos. Essa delimitação evita que a expressão “a EVM processou” seja interpretada como uma garantia sobre todos os aspectos da interação com uma aplicação.
Transições de estado seguem regras definidas
O estado do Ethereum inclui contas, saldos e armazenamento dos contratos. A EVM define as regras para alterá-lo. A documentação representa essa relação como Y(S, T) = S': um estado anterior válido, combinado com transações válidas, produz um estado resultante válido segundo as regras de transição.
Leia a fórmula como uma relação entre entradas, regras e saídas. O estado anterior fornece as informações iniciais. As transações fornecem instruções a processar. As regras de transição determinam o estado resultante. Considerar apenas a finalidade declarada do contrato deixa de fora esse contexto inicial.
A documentação descreve a função de transição como determinística: a saída decorre das entradas segundo as regras definidas. Determinismo não significa garantia de sucesso da aplicação. Reproduzir um resultado e satisfazer o objetivo de uma pessoa são questões diferentes.
Uma dedução limitada parte de duas premissas documentadas: as transições seguem regras do protocolo, e uma execução pode esgotar seu gas e ter suas alterações desfeitas. Portanto, uma transição de estado válida não garante que uma chamada ao contrato alcance o resultado pretendido. Essa conclusão é uma interpretação dessas premissas, não uma promessa adicional contida na fórmula.
O armazenamento do contrato integra o estado
O armazenamento persistente de um contrato está associado à sua conta e faz parte do estado global do Ethereum. Conceitualmente, é onde o contrato pode conservar informações, em vez de apenas calcular um resultado intermediário.
A distinção central é entre executar instruções e comprovar uma atualização persistente. Uma explicação que menciona uma operação de gravação ainda precisa demonstrar se a atualização pretendida ocorreu. A tentativa de atualizar, por si só, não comprova o valor armazenado ao final.
Também é necessário distinguir o armazenamento persistente dos dados temporários usados na execução. Por exemplo, a memória de execução da EVM não persiste entre transações. Não é preciso conhecer a estrutura interna das árvores de armazenamento para formular a pergunta prática: quais informações pertencem ao estado persistente do contrato e que evidência demonstra seu valor resultante?
Gas mede o trabalho e delimita o orçamento
Gas mede o esforço computacional necessário para executar operações no Ethereum. O limite de gas da transação estabelece o orçamento máximo fornecido para ela. São conceitos relacionados: gas é a medida de trabalho, enquanto o limite delimita o orçamento disponível.
A documentação descreve a taxa como o gas utilizado multiplicado pelo custo por unidade de gas. Como o limite representa uma quantidade máxima de gas e o preço representa um custo por unidade, deduz-se que são grandezas diferentes. Aqui, o foco é o orçamento computacional, sem cálculos de taxas ou preços de opcodes. Fornecer um orçamento também não comprova que o resultado solicitado ocorrerá.
Gas intrínseco insuficiente: rejeição na validação
A documentação de gas do Ethereum diferencia a transação sem gas intrínseco suficiente para passar pela validação daquela que esgota o gas durante a execução. No primeiro caso, a transação é rejeitada antes da inclusão em um bloco, sem consumo de gas.
A fonte ilustra essa situação com uma transferência simples de ETH cujo limite está abaixo do requisito de validação. O exemplo numérico não deve ser generalizado como requisito para toda operação com contratos. O ponto relevante é que a rejeição acontece antes de a execução prosseguir.
Esgotamento de gas durante a execução
No caso descrito pela fonte em que a transação esgota seu gas durante a execução, o processamento começa, mas consome todo o orçamento fornecido. A EVM desfaz as alterações da execução, enquanto todo o gas disponibilizado é consumido pelo trabalho realizado.
Essa afirmação tem um alcance específico: o esgotamento de gas no nível da transação. Ela não descreve todos os tipos de falha. Tampouco estabelece recuperação de ativos, reversão do consumo de gas ou o tratamento de falhas em chamadas internas individuais.
Exemplo hipotético de um contador armazenado
Exemplo hipotético: imagine um contrato didático cujo armazenamento persistente contém um contador com valor 7. A operação pretendida é aumentá-lo para 8. O contrato e os valores são inventados para explicar o conceito; não é necessário realizar uma transação.
- Identifique o programa: o contrato contém bytecode compilado, executado como opcodes da EVM quando recebe uma chamada.
- Identifique o estado inicial: o contador começa em 7 no armazenamento persistente do contrato.
- Identifique o resultado pretendido: a atividade didática espera que o contador termine em 8.
- Considere o limite do orçamento: se a transação esgotar seu gas durante a execução, suas alterações de execução serão desfeitas e todo o gas fornecido será consumido.
O exemplo mostra por que descrever a atualização desejada é insuficiente. É preciso distinguir o valor inicial, a operação executada e o valor armazenado ao final. Na alternativa com esgotamento de gas, o início da execução não comprova a atualização pretendida.
Separe execução de consenso e confira a explicação
O cliente de execução do Ethereum executa transações na EVM. O cliente de consenso implementa o acordo por prova de participação, ou proof of stake, com base nos dados validados pelo cliente de execução. A documentação de nós e clientes estabelece essa divisão de responsabilidades.
Essa é a fronteira conceitual necessária aqui: execução trata do processamento de instruções e do estado; consenso trata do acordo da rede com base nos dados de execução validados. Para aprofundar as funções dos programas, consulte o guia de nós e clientes Ethereum. Para estudar separadamente as etapas de verificação, veja como uma transação é verificada no Ethereum.
Use este checklist ao avaliar uma explicação sobre a EVM:
- Identifique o código compilado do contrato e a operação pretendida.
- Especifique o estado inicial relevante e o armazenamento persistente.
- Separe uma transição conforme as regras da evidência do resultado desejado.
- Diferencie o orçamento de gas da transação do preço por unidade de gas.
- Distinga rejeição por gas intrínseco insuficiente de esgotamento durante a execução.
- Mantenha execução e acordo da rede como responsabilidades distintas.
Essas perguntas ajudam a interpretar descrições técnicas. A indicação de fontes, isoladamente, não comprova que um contrato específico seja seguro.
Material educativo preparado com auxílio de IA. O exemplo é hipotético e não solicita o envio de transações nem a assinatura de pedidos em uma carteira.