Análise baseada em dados em EIP-7907 – Execution Layer Research

O relatório a seguir pretende ser uma coleção de dados que, esperançosamente, será um recurso que ajudará a ACD a tomar uma decisão sobre o EIP-7907.
Além disso, esperamos que isso estabeleça uma nova metodologia de respaldo de EIPs ou propostas com o máximo de dados possível, o que pode definitivamente ajudar a tomar decisões melhores e mais informadas ao definir o escopo das bifurcações.

Quero agradecer a @ rjl493456442 por seu PR adicionando métricas no Geth e por seu conselho e suporte durante a coleta de benchmark, que foi extremamente útil. E que eu gostaria de padronizar eventualmente em todos os clientes, para que possamos comparar e coletar dados facilmente para informar nossas decisões sobre reprecificação e dimensionamento.

Problema Relacionado:** EIP-7907
Data: 13/01/2026
Ambiente de referência: Geth (modo dev) com banco de dados do tamanho da rede principal (~ 24 milhões de blocos), caches internos desativados
Configuração de teste: ~18.106 operações EXTCODESIZE por bloco (todos os diferentes contratos de bytecode), ~50 milhões de gás
Hardware: WD Black SN850X NVMe (8 TB)

Sumário executivo

Este relatório analisa o desempenho do EXTCODESIZE opcode ao ler contratos de tamanhos variados de bytecode (0,5 KB a 64 KB) com o cache de código interno do Geth desativado. Isso representa o pior cenário de ataque, onde um invasor implanta milhares de contratos exclusivos para forçar leituras frias de disco.

A iteração também tem a menor sobrecarga possível. CREATE2 geração de endereços determinísticos.
Mais informações sobre isso podem ser encontradas em:

Principais conclusões

Veredicto EIP-7907

Recomendação: Continue com 64 KB como o novo tamanho máximo do contrato. Além de 64 KB, seria necessária uma nova coleta de dados assim que as otimizações de BALs e ePBS fossem implementadas em todos os clientes.
Se fosse necessária uma reavaliação após a recolha de dados acima mencionada, tal precificação também exigiria a capacidade de avaliar o resto dos clientes, bem como olhar para o resto dos EXTCODE* códigos de operação.

1. Metodologia e configuração de benchmark

1.1 Ambiente de Teste

1.2 Desenho do Cenário de Ataque

Este parâmetro representa o ataque de pior caso contra EXTCODESIZE:

• Mais de 18.100 contratos exclusivos implantados por tamanho (força perdas de cache de código)
• Cada bloco lê bytecode de todos os contratos exclusivos exatamente uma vez
• Taxa de acerto do cache de código: <2% (efetivamente desabilitado)
• Cache de página do sistema operacional limpo entre execuções de benchmark

1.3 Linha de base do disco bruto (fio)

Para estabelecer o desempenho máximo teórico, medimos os recursos brutos do NVMe:

2. Resultados de referência

2.1 Tempo de leitura do código versus tamanho do bytecode

Descoberta principal: O tempo de leitura do código aumenta com o tamanho do bytecode quando o cache é ineficaz.

Visão principal: O tempo de leitura do código aumenta 8,5x à medida que o tamanho do bytecode aumenta 128x. Isso é sublinear escala (não 1:1), mas o impacto absoluto no tempo é significativo.

2.2 Bytes lidos versus tempo de leitura de código (correlação)

A forte correlação positiva (R² ≈ 0,96) confirma que o tempo de leitura do código aumenta com o total de bytes lidos quando os caches são ineficazes.

2.3 Latência por chamada

A latência por chamada aumenta com o tamanho do bytecode:

3. Detalhamento do tempo de execução

3.1 Análise de Componentes

A leitura do código torna-se o fator dominante em tamanhos de bytecode maiores:

Observação: Com 64 KB, a leitura do código consome 90% do tempo de execução do bloco. Isso é dramaticamente diferente dos cenários de cache quente, onde a leitura do código é de apenas 8 a 10%.

4. Análise de orçamento de tempo de bloco (foco EIP-7907)

4.1 Tempo versus meta de orçamento

Usando uma meta de 1 segundo para execução de bloco:

Conclusão: Contratos de 64 KB são viáveis ​​nas piores condições de ataque em blocos de gás de 60 milhões. O tempo de execução de aproximadamente 1 segundo está dentro do limite do orçamento, mas é aceitável. Observe que este é um limite bastante conservador, considerando que os ePBS e BALs provavelmente remodelarão o que consideramos um orçamento seguro num futuro próximo.

4.2 Taxa de processamento de gás (análise de preços incorretos)

Preço incorreto observado: Mesmo custo de gás, mas tempo de execução 5x diferente (236 Mgas/s → 49 Mgas/s). Isto indica que, nas piores condições, contratos maiores impõem custos desproporcionalmente mais elevados aos validadores.

Implicação para 128 KB+: Além de 64 KB, seria necessário um ajuste no modelo de gás – provavelmente um custo base mais um componente dependente do tamanho.

Observe que isso é bastante conservador. Como para “parar” a rede ou “prejudicar significativamente os validadores lentos”, a configuração necessária seria centenas de vezes maior que os 18 mil contratos únicos. O que acarreta custos enormes (não podemos reutilizá-los, pois seriam armazenados em cache após a execução do primeiro bloco).

5. Linha de base do disco bruto (eficiência Geth vs NVMe)

5.1 Comparação de eficiência

Observação: Geth atinge 20-51% de desempenho bruto do disco. A lacuna provavelmente se deve a:

• Sobrecarga Pebble/LevelDB (travessia de índice, filtros Bloom)
• Hashing e pesquisa de chave
• Desserialização de valor

6. Comparação com cenário de cache quente

6.1 Desempenho em cache versus desempenho sem cache

A descoberta de “custo fixo” dos benchmarks de cache quente permanece válida para operação normal. As condições de cache frio exigem cenários de ataque extremos (mais de 18 mil contratos exclusivos).

7. Implicações para EIP-7907 e recomendações

7.1 Resumo das Constatações

1. Escalas de tempo de leitura de código com tamanho sob condições de ataque (8,5x de 0,5 KB a 64 KB)
2. 64 KB é viável em 60 milhões de blocos de gás – na pior das hipóteses, execução de ~1s, dentro do orçamento
3. Isto representa o pior caso absoluto—18K+ contratos exclusivos são impraticáveis ​​para implantar e manter (você precisa de um novo conjunto para cada bloco que deseja executar o ataque).
4. A operação normal não é afetada—cenários de cache quente mostram custo fixo de aproximadamente 5ms
5. Existe preços incorretos de gás sob ataque (variação de tempo de execução de 5x para o mesmo gás)

7.2 Recomendação EIP-7907

Parece que podemos simplesmente “manter as coisas simples” e fornecer aos desenvolvedores de contratos inteligentes uma boa atualização no limite de tamanho do código sem quaisquer alterações no protocolo além do limite de 64kB e do aumento do tamanho do código de inicialização.

Assim que tivermos BALs e ePBS em um estado mais pronto, estaremos em uma posição em que os dados nos guiarão melhor para uma boa decisão sobre reprecificação/apenas prosseguir para 256kB.
Mas parece desnecessário fazer uma reavaliação agora para algo que realmente não precisa, mesmo no pior dos casos.

7.3 Por que 64 KB é aceitável

1. Impraticabilidade do ataque: A implantação de mais de 18 mil contratos exclusivos de 64 KB requer:

   • ~13 milhões de gás por implantação de contrato (base 32K + 64K × 200 gás/byte)
   • Centenas de blocos apenas para configuração
   • Custo contínuo significativo para manter a superfície de ataque

2. Bloqueie o tempo dentro do orçamento: Mesmo o pior caso ~1s é aceitável para blocos de gás de 60M

3. Eficácia do cache na prática: Mainnet real bloqueia contratos de reutilização; a taxa de acerto do cache de código é normalmente alta

4. Escala sublinear: O tempo de 8,5x para um crescimento de tamanho de 128x indica que a amortização ainda ajuda