Tanque de gases com vazamento da Ethereum: Desaviando 13 Inconsistências de Modelo de Gás Caro – Pesquisa de Camada de Execução

Este post resume 13 inconsistências no modelo de gás do Ethereum.
Todos os símbolos vêm do artigo amarelo Ethereum (especialmente da programação de taxas do Apêndice G.).

1. A transação externa não incorre em cobranças de nova conta (G_ {newAccount}) ao criar uma conta, mas transações internas fazem

Exemplo
Suponha que você queira um contrato C transferir ETH para um conta nova A Isso ainda não existe.

• Se C Transferências diretamente, as cobranças internas do caminho da conta nova 25.000 gás (G_ {newAccount}).
• Alternativa: primeiro envie um TX externo de um EOA para A com 1 wei. Este TX custa a base padrão 21.000 gás. Depois disso, A existe. Agora Cé transferida para A não incorre mais no novo custo da conta (Economize ~ 4.000 gás).

Conclusão
Se você confiar em um contrato para criar uma nova conta, pagará 25.000 gases.
Mas se você enviar uma transação externa pela primeira vez (21.000 gás) e depois deixe o contrato enviar fundos, você efetivamente Economize ~ 4.000 gás.

Causa
Os caminhos de criação externa e interna usam ganchos de carregamento diferentes; Somente o contrato que invocava aciona a taxa explícita de nova conta.

2. As chamadas pré-compilantes às vezes ignoram as taxas de entrada de transação

Exemplo
Chamando um contrato pré -compilado (por exemplo, ECRECOVER) pode pular o carregamento para bytes de entrada da transação. Normalmente, os bytes de entrada custam 4 gás (zero) ou 16 gás (diferente de zero) cada. Pegue dois exemplos de transações reais:
* 1. Uma transação 0x6b01 chamando ECRECOVER com 24.276 gás, onde 276 gás é para os bytes de entrada.
* 2. Uma transação 0x1fb0 chamando ECRECOVER com 24.000 gás, onde 0 gás é para os bytes de entrada.
Se você ler o Código Fonte de Execução Cliente, poderá descobrir que a segunda transação também pode executar ECRECOVER sem cobrar por bytes de entrada. O cliente preencherá a entrada com dados zero para corresponder ao tamanho esperado.

Nota extra
Eu acho que você é inteligente o suficiente para perceber que as duas transações que mencionei são transações externas.
Então, por que eles invocam contratos pré -compilados?

Eu acho que parte do motivo é que alguns endereços pré -complicantes dos exploradores da etiqueta (0x01–0x0a) como “endereços de queimadura”, confundindo ainda mais usuários (veja aqui com o instantâneo abaixo).

Além disso, a implantação dos endereços pré -compilados nesses endereços especiais (0x01–0x0a) é um design com falha.
Às vezes, as pessoas só querem chamar esses endereços especiais diretamente.

Causa
O mau endereço do design de contratos pré -compilados e o enganoso dos exploradores de blocos levam a confusão e erro de roteiro.

3. As entradas da lista de acesso são cobradas mesmo que nunca acessadas (ou seja, G_ {AccessListAddress}Assim, G_ {AccessListStorage})

Exemplo
O EIP-2930 apresenta listas de acesso, permitindo que as transações especifiquem quais endereços e slots de armazenamento eles pretendem acessar. No entanto, uma transação pode incluir endereços e slots em sua lista de acesso, mas nunca os toca.
Por exemplo, uma transação 0x0dd0c define uma lista de acesso, mas nunca acessa os slots especificados devido ao endereço.

Causa
O protocolo cobra inclusão Para simplificar a execução, independentemente de as entradas serem usadas. Se você confia que seus usuários podem fornecer informações corretas, também pode confiar que Taylor Swift é sua esposa.

4. A auto-transferência ainda cobra transferência de gás

Exemplo
A conta A envia a ETH para si mesma.
Nenhuma mudança de equilíbrio ocorre, mas as cobranças ainda incluem 9.000 gás (G_ {CallValue}) para a transferência de valor. De acordo com este post de @vbuterin.

Duas contas gravações (uma chamada de edição de saldo normalmente custa 9000 gases)

Por que uma conta de conta ainda custa 9.000 gás? Na verdade, se você ler a fonte do cliente de execução, descobrirá que, quando o endereço do endereço for o mesmo que o abordagem, o cliente não fará nada.

Os casos acima podem acontecer quando a transação é uma auto-transferência ou usa Callcode para transferir valor.

Causa
As cobranças de execução são acionadas, independentemente de a transferência ser um não-OP.

5. Calldata vs. Contrato ByteCode Disk Precication Intispatch

Exemplo

• TX Calldata: 16 gás/byte (diferente de zero) ou 4 gás/byte (zero).
• Contrato bytecode: 200 gás/byte.
  Ambos ocupam o disco, mas os preços são inconsistentes. É muito confuso para mim, pois o TX Calldata é mais barato que o ByteCode de contrato, pois deve considerar o uso real do disco e a sobrecarga de rede.

Causa
O cronograma de gás separa “Calldata” e “depósito de código” sem alinhá -los ao uso real do disco.

6. As transações revertidas são carregadas como se tenham escrito ao disco

Exemplo
Uma transação revertida modifica o estado na memória, mas nenhuma alteração persiste, mas as cobranças de gravações ainda são aplicadas, as seguintes taxas de gás são afetadas:

• 25.000 gás (nova conta, G_ {newAccount})
• 9.000 gás (transferência de valor, G_ {CallValue})
• 2.100 gás (fato frio, G_ {Coldslot})
• 200 gás (depósito de código, G_ {codedEposit})

O custo real apenas de memória teria sido ~100 gás.

Causa
O gás é cobrado durante a execução; Uma reversão posterior cancela as mudanças do estado, mas não as taxas. As implementações cobram conservadoramente para impedir o DOS.

7. As transferências de ETH múltiplas em uma única transação são inalteradas como frio

Exemplo
Suponha que um contrato envie ETH para diferentes contas várias vezes em uma única transação.

• A primeira transferência incorre corretamente o G_ {CallValue} (9.000 gás) para escrever para o saldo da conta.
• Transferências subsequentes para a outra conta na mesma transação devem ser cobradas a taxa de acesso quente (100 gás + 4.500 gás), mas às vezes ainda são cobrados como frio (9.000 gás).

Causa
A contabilidade de acesso quente/frio não é atualizado de forma consistente para transferências de valor múltipla em uma única transação.

8. A recompensa ou retirada de mineiro/validador não é carregado

Exemplo
Atualizações de saldo no nível do protocolo (por exemplo, recompensas, retiradas) modificam o estado no disco, mas custa 0 gás.

Causa
A contabilidade no nível do sistema ignora os ganchos de contabilidade de gás.

9. A primeira leitura de disco de Sstore não é carregada (por EIP-2200)

Exemplo
Quando o SSTORE O OpCode é executado, primeiro lê o valor atual do disco (armazenamento de contrato) antes de decidir se deve escrever um novo valor. De acordo com o EIP-2200, se o valor armazenado corresponder ao valor existente, nenhuma gravação de disco ocorre e apenas uma taxa mínima de gás será cobrada. No entanto, o disco inicial leia em si é não cobrou nenhum gás– O protocolo cobra apenas a gravação subsequente se o valor for alterado.

Causa
A lógica do EIP-2200 se concentra no carregamento das alterações do estado, mas omite o carregamento da leitura do disco que sempre acontece primeiro. Isso significa que o primeiro acesso ao slot de armazenamento é gratuito, mesmo que seja uma leitura fria.

10. Otimizações de leitura de armazenamento reduzem a E/S, mas o gás permaneceu inalterado

Exemplo
Os clientes do Ethereum adotaram otimizações planas de armazenamento/instantâneo (por exemplo, estrutura de aceleração de instantâneos para GETH), que organizam o estado como uma loja de valor-chave simples e permitem leituras de disco direto, ignorando os nós intermediários exigidos pelo Trie Merkle-Patricia Legacy (MPT). Essa otimização reduz significativamente a E/S do disco para leituras de armazenamento a frio. Por exemplo, Geth e outros clientes agora usam SAS ou estruturas semelhantes, mas as taxas de gás para acessos frios –2.600 / 2.100 / 2.400 / 1.900 gás—Mon -se inalterado.

Causa
As constantes de gás para acesso a frio foram originalmente calibradas para MPT, onde as leituras de disco eram mais caras devido a atravessar vários nós de trie. Com o SAS, o consumo real de recursos de disco é muito menor, mas o protocolo não atualizou as taxas de gás correspondentes.

Mitigação
Recalibre as constantes de gás para refletir a E/S reduzida de disco quando os clientes alternam para o SAS ou backndes de armazenamento otimizado similares.

11. Sload vs. Mismatch de preços de Mload

Exemplo

• SLOAD (quente) → 100 gás
• MLOAD → 3 gás
  Ambos são leituras de memória, mas os preços diferem muito.

Causa
Distinção herdada entre operações de estado e memória; Otimizações embaçaram a diferença de custo real.

12. Transações internas às vezes atualizam contas sem gás

Exemplo
Quando as atualizações da conta no disco ocorrem sem cobrar uma taxa de gás por essas atualizações. Especificamente, esse problema surge em cenários em que um usuário envia uma transação externa para o contrato A, que por sua vez faz uma chamada interna para o contrato B. Se o contrato b modificar um slot em seu armazenamento, a raiz de armazenamento correspondente na conta do contrato B deverá ser atualizada no disco. No entanto, nenhuma taxa de gás é cobrada por esta atualização da conta B, levando a uma inconsistência.

Causa
O bug ocorre porque a modificação do Trie de armazenamento do contrato b não incorre na taxa de gás adicional para atualizar o estado da conta. Isso resulta do protocolo que não cobra para as atualizações do estado da conta acionadas por transações internas, embora as gravações de disco sejam executadas.

13. Ext* Opcodes com preços muito grosseiros

Exemplo
EXTCODESIZE pode ler mais dados do que BALANCEmas ambos são cobrados a mesma taxa de conta a frio (2.600 gás).

Causa
Os baldes de preços do código OPCOD são grossos e ignoram o trabalho variável.

Nota de fechamento

Esta questão vem do meu artigo da seguinte maneira, eu o compartilho com este link.

Ele, Z., Li, Z., Luo, J., Luo, F., Duan, J., Li, J.,… & Zhang, X. (2025, fevereiro). AUSPEX: revelando bugs de inconsistência do mecanismo de taxa de transação no blockchain. Em Anais da 23ª conferência do USENIX, sobre tecnologias de arquivo e armazenamento.

Eu ficaria feliz se você pudesse citar meu artigo.

Tudo isso destaca a necessidade de uma revisão abrangente e ajuste de mecanismos de precificação de gás no protocolo Ethereum. Ao abordar essas inconsistências, podemos garantir um mercado de gás mais eficiente e justo que reflita com precisão os custos de recursos subjacentes de várias operações.