Ethereum ByteCode e Code Chunk Analysis – Pesquisa de camada de execução

O Code Chunking é uma estratégia para dividir o ByteCode em pedaços menores, o que ajuda a reduzir o tamanho da testemunha. No entanto, essa abordagem é eficaz apenas se uma parte relativamente pequena do bytecode for acessada durante a execução. Esta análise explora os padrões de acesso de byte e chunk para avaliar a utilidade do Code Chunking.

Metodologia

O repositório completo que inclui o código de coleta e análise de dados pode ser encontrado aqui.

Análise

Principais estatísticas do conjunto de dados

• Faixa de blocos: 15537394 (a mesclagem) –22000000
• Contagem de blocos: 100898 (espalhado uniformemente pela faixa de blocos)
• Interações com contrato total: 19.934.701
• Min. Contratos exclusivos interagiram com o bloco: 1
• Contratos exclusivos medianos interagiram com o bloco: 187
• Máx. Contratos exclusivos interagiram com o bloco: 659
• Contratos únicos totais interagiram com: 1.220.017

Padrões de acesso a bytes

Esta seção examina a proporção de bytecode acessada durante a execução do contrato:

Bytes Accessed Ratio = bytes accessed / total bytecode size

Encontrar o núcleo: Em média, apenas 22,8% do contrato bytecode foi acessado em um bloco.

Insights detalhados:

• Proporção mediana acessada: 17,1%
• Pelo tamanho do contrato:
  • Minúsculo (<1 kib): AVG 62,9%, mediana 61,2%
  • Pequeno (1–5 kib): AVG 21,6%, mediana 15,8%
  • Médio (5-10 kib): AVG 15,0%, mediana 13,0%
  • Grande (10–20 kib): AVG 16,5%, mediana 17,3%
  • Muito grande (20–24 kib): AVG 16,1%, mediana 15,1%

Interpretação: Para contratos maiores que 1 kib, apenas uma pequena fração do bytecode é acessada. Os contratos abaixo de 1 KIB tendem a ter mais bytecode acessados. Isso é esperado, pois pequenos contratos geralmente contêm menos funções que são invocadas repetidamente.

Padrões de acesso a pedaços

Referenciando o EIP-2926 como uma solução de chunking de código, dividimos o bytecode do contrato em pedaços de 31 bytes e avaliamos a proporção de pedaços de 31 bytes acessados:

Total number of chunks = bytecode size / 31
Chunks Accessed Ratio = chunks accessed / total number of chunks

Encontrar o núcleo: Em média, apenas 29,6% de pedaços de 32 bytes foram acessados em um bloco.

Insights detalhados:

• Proporção mediana acessada: 24,7%
• Pelo tamanho do contrato:
  • Minúsculo (<1 kib): AVG 69,1%, mediana 66,7%
  • Pequeno (1–5 kib): AVG 30,8%, mediana 23,5%
  • Médio (5-10 kib): AVG 22,0%, mediana 19,6%
  • Grande (10–20 kib): AVG 22,2%, mediana 24,5%
  • Muito grande (20–24 kib): AVG 21,7%, mediana 21,1%

Interpretação: Os resultados são semelhantes à proporção de bytes acessados. O acesso a pedaços também é baixo para contratos acima de 1 kib. No entanto, as relações gerais de acesso à acesso são um pouco mais altas do que as relações acessadas por bytes, sugerindo que nem todos os bytes nos pedaços acessados foram usados.

Eficiência de pedaços

Nesta seção, exploramos o quão eficientes são os pedaços, ou seja, quantos bytes nos pedaços são realmente usados:

Chunks Efficiency = bytes accessed / (chunks accessed * 31)

Encontrar o núcleo: Em média, 68,9% dos bytes nos pedaços de 31 bytes foram acessados. São cerca de 21 bytes em cada pedaços de 31 bytes, em média.

Isso indica que mais da metade dos bytes em pedaços de 31 bytes foram acessados. Para maximizar a eficiência do pedaço, podemos considerar tamanhos de pedaços menores (por exemplo, pedaços de 16 bytes). No entanto, isso tem o custo do aumento da sobrecarga de hash.

Instruções de acesso ao código

Esta seção avalia o impacto dos códigos de operações que acessam todo o código, a saber:

• EXTCODESIZE
• EXTCODECOPY
• CODECOPY
• CODESIZE

Quando um desses códigos de operações é executado, requer acesso a todos os bytes no bytecode. Nas seções anteriores para avaliar as taxas de acesso, as excluímos dos resultados. Aqui, avaliamos como incluí -los altera os índices de acesso. Nós os dividimos em duas categorias:

1. Tamanho do código (EXTCODESIZEAssim, CODESIZE)
2. Cópia de código (EXTCODECOPYAssim, CODECOPY)

O motivo das duas categorias é porque o EIP2926 adiciona o tamanho do código no campo da conta. Portanto, uma vez implementado, o código de código OPCODES não exigirá mais acesso a todo o bytecode.

No total, 46,6% de contratos por bloco contêm o tamanho do código ou o código OPCODES. Entre estes, 40,7% contém o tamanho do código OPCODES, enquanto apenas 10,6% conter os códigos de cópia de código.

Taxa de acesso de bytes avg

• Original: 22,8%
• Com o tamanho do código: 54,0% (+31,2%)
• Com cópia de código: 31,5% (+8,7%)

Taxa de acesso AVG em pedaços

• Original: 29,6%
• Com o tamanho do código: 57,8% (+28,2%)
• Com cópia de código: 37,6% (+8,0%)

Depois de incluir as instruções de acesso ao código, vemos um aumento moderado nas taxas de acesso. No entanto, é principalmente devido a códigos de tamanho de código. Como mencionado anteriormente, a adição do tamanho do código no campo da conta tornaria o código de cópia o código OPCODS as únicas instruções para acessar o bytecode inteiro. Como a quantidade de instruções de cópia de código é significativamente menor, as taxas de acesso geral são mais baixas.

O código está chunking uma solução viável?

Referenciando o EIP-2926, o ponto principal de chunking de código é reduzir o tamanho da testemunha, pois o status quo atual exige que todo o bytecode seja usado na prova do código.

Nossa análise mostrou que nem todos os bytes do bytecode de um contrato são usados. De fato, apenas uma proporção relativamente pequena dos bytes e pedaços é usada. Com base nos padrões de acesso atuais, se implementarmos o Chunking de código, reduziríamos significativamente a quantidade de bytes reais usados incluídos na testemunha do código.

A adição do tamanho do código no campo da conta no EIP2926 faria efetivamente fazer com que cópias de código OPCODES as únicas instruções que exigem acessar todo o bytecode. Além disso, como mostrado em nossas descobertas, a quantidade de código de cópia de código é significativamente menor que o tamanho do código. Portanto, reduziríamos ainda mais o tamanho médio da testemunha do código com base no padrão de acesso atual.

Uma exploração adicional que podemos realizar é determinar o tamanho ideal do pedaço. No EIP-2926, ele usa pedaços de 31 bytes. Podemos querer explorar tamanhos de pedaços menores, como 16 bytes, para maximizar o número de bytes utilizados por pedaço. No entanto, isso tem um custo de sobrecarga adicional de hash. Portanto, precisamos experimentar diferentes tamanhos de bloco para encontrar o equilíbrio ideal.