Ir para o conteúdo
Financial Context Wiki

Máquina Virtual Ethereum (EVM)

Guia sensível ao fork sobre transações EVM, chamadas, bytecode, pilha, memória, storage, gas, REVERT, DELEGATECALL, precompilados, recibos e conciliação do estado.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

A EVM é a máquina de transição de estado da camada de execução que interpreta bytecode sob as regras de um fork específico. Com o mesmo estado anterior válido, transação ou mensagem, ambiente do bloco e especificação, clientes conformes devem calcular o mesmo estado posterior ou falha. A EVM não ordena transações, fornece finalidade nem torna toda rede compatível tão segura quanto Ethereum.

Uma transação assinada externamente é um objeto superior. Atividade entre contratos são chamadas e quadros aninhados, não transações independentes. Cada quadro tem código, contador, pilha de 256 bits, memória, calldata, returndata, gas e contexto; storage persistente pertence à conta e storage transitório dura a transação.

Como funciona

  1. Fixe rede e chainId, bloco e hash, estado canônico ou finalizado, fork, cliente, revisão, estado anterior, tipo, bytes assinados, hash e recibo.
  2. Decodifique o envelope e separe validade prévia de execução. Verifique assinatura, remetente, nonce, destino ou criação, value, calldata, limite de gas, taxas, access list e campos do tipo. Rejeição anterior não é transação incluída que sofreu revert.
  3. Construa mensagem e árvore de chamadas. Registre CALL, STATICCALL, DELEGATECALL, criação e precompilados; caller, endereços de contexto e código, msg.sender, msg.value, value, dados, gas e resultado. “Transação interna” é visualização de trace.
  4. Rastreie contador, pilha, memória, dados, logs, storage persistente e transitório. CALL usa contexto do callee; DELEGATECALL executa código-alvo no contexto do caller e preserva sender e value; STATICCALL proíbe alteração de estado.
  5. Aplique gas do fork: intrínseco, opcodes, memória, acessos cold/warm, chamadas, stipends, precompilados e refunds. Calcule taxa separada do value. Estimativa não é garantia.
  6. Resolva resultados por escopo. RETURN confirma se os ancestrais confirmarem. REVERT desfaz quadro e descendentes, retorna dados e pode preservar gas; exceptional halt difere. O pai pode capturar a falha, então status superior pode ser 1. Falha incluída consome nonce e gas.
  7. Concilie status, gas, logs, endereço criado e retorno com saldos, nonces, código, storage, tokens, traces e state root. Reexecute se necessário e audite proxies, layouts, precompilados, compilador e forks separadamente da finalidade.

Exemplos resolvidos

  • Revert superior e taxa. Uma transação tipo 2 tem limite 80,000, usa 52,000, base 20 gwei, prioridade máxima 3 gwei e máximo 40 gwei. O preço efetivo é min(40, 20 + 3) = 23 gwei; paga 52,000 * 23 gwei = 0.001196 ETH: queimam-se 52,000 * 20 gwei = 0.001040 ETH e a prioridade é 52,000 * 3 gwei = 0.000156 ETH. Os 28,000 gas não usados não são cobrados. Se houver revert, storage, value e logs são desfeitos, mas nonce e taxa ficam.
  • Falha filha capturada. A começa com A.x = 5. Chama B; B grava B.y = 9, emite log e executa REVERT. Gravação e log são desfeitos. A observa success = false, grava A.x = 7 e termina. O status é 1, permanece A.x = 7 e B conserva o valor anterior.
  • Contexto de DELEGATECALL. Um proxy tem slot0 = 5 e a implementação slot0 = 99. O código soma 7. Por DELEGATECALL, o proxy passa a slot0 = 12 e a implementação fica em slot0 = 99; endereço e storage do proxy se aplicam, preservando sender e value.
  • SELFDESTRUCT conforme fork. Sob EIP-6780, contrato existente com 2 ETH executa SELFDESTRUCT para B. B recebe 2 ETH e o saldo zera, mas conta, código e storage não são excluídos. A exclusão só permanece se criação e autodestruição ocorrerem na mesma transação.

Riscos

  • Reexecutar contra rede, bloco, fork, cliente ou estado incorretos.
  • Tratar estado não canônico ou reorganizado como final.
  • Confundir rejeição prévia e revert incluído.
  • Supor que simulação pendente coincidirá com a inclusão.
  • Ignorar revert, exceptional halt ou out-of-gas superior.
  • Omitir falha filha capturada.
  • Interpretar mal contexto, código, caller, sender ou value.
  • Corromper proxy por layout incompatível em DELEGATECALL.
  • Permitir reentrancy ou transferência externa insegura.
  • Confiar em returndata, flags ou erros não validados.
  • Tratar logs ou traces como estado final.
  • Calcular mal acessos, memória ou gas encaminhado.
  • Aplicar mal refunds, limites, stipends ou regra 63/64.
  • Usar precompilado, entrada, custo ou fork incorretos.
  • Confundir storage, memória e armazenamento transitório.
  • Esperar alteração de estado dentro de STATICCALL.
  • Aplicar suposições antigas de exclusão de SELFDESTRUCT.
  • Omitir mudança de implementação, admin ou compilador.
  • Executar regras de clientes divergentes ou desatualizadas.
  • Inferir segurança de consenso, bridge, token ou governança pela compatibilidade EVM.

Erros comuns

  • O código-fonte Solidity é executado diretamente onchain.
  • Uma transação incluída que sofre revert não custa nem altera o nonce.
  • Status 1 prova que todas as chamadas internas foram bem-sucedidas.
  • Evento ou trace é o estado autoritativo.
  • Compatibilidade EVM garante opcodes, gas, precompilados, consenso e segurança idênticos.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...