O pior tamanho de bloco do Ethereum continua surgindo como um problema, normalmente por meio de construções adversárias, em vez de uso honesto. Os blocos médios são pequenos; os piores casos não são.
Fundo
Antes do Pectra, o tamanho do bloco de pior caso era impulsionado por ineficiências de compactação do Snappy e dados de chamada baratos (gás 4/16 para bytes zero/diferentes de zero).
EIP-7623 (Pectra) resolveu esta questão aumentando os custos de calldata para 10/40 gás para transações com muitos dados de chamada. Isso introduziu uma nova construção de pior caso:
- ~3/5 do gás de bloco gasto nas listas de acesso EIP-2930
- ~2/5 gastos em calldata
- Estruturado para evitar o acionamento do piso EIP-7623 → “gás de execução suficiente para continuar pagando o preço mais baixo”
O problema: os dados da lista de acesso são essencialmente gratuitos. Isso contorna o EIP-7623 e aumenta novamente o tamanho do bloco do pior caso.
Por que isso é importante agora
O aumento dos limites de gás de bloco e da contagem de blob causará ainda mais estresse na propagação. Enquanto ePBS (envio com Glamsterdam) estende o tempo de propagação, BALs aumentam os dados brutos do bloco: contraproducente nesta frente.
Reprecificação proposta (ambos os EIPs são CFI para Glamsterdam)
EIP-7981: Aumente o custo da lista de acesso
Aplica custos de calldata a listas de acesso de transação. Isto fecha o caminho de evasão: o pagamento do gás agora rastreia os dados reais como se fossem calldata.
EIP-7976: Aumentar o custo mínimo de dados de chamada
Duas opções em discussão:
- Conforme especificado: aumentar os preços a partir de 40/10 → 15/60 gás para transações com muitos dados de chamadas; simples aumento de preço de 50%
- Alternativa: plano 64/64 gás por byteeliminando a distinção zero/diferente de zero
Interação com ePBS
ePBS pode vir com um prazo de carga dinâmica: o PTC impõe prazos mais apertados para cargas úteis menores.
O CL não deseja consagrar uma codificação Snappy específica. O preço fixo por byte (opção 2) é melhor aqui: o tamanho do pior caso torna-se mais previsível ao usar o tamanho da carga útil não compactada.
Um possível caminho a seguir
Com o EIP-7976, no estado em que se encontra (15/60 para bytes zero e diferentes de zero), podemos chegar a um limite de gás de bloco de 150 milhões sem exceder o tamanho de bloco do pior caso de 4 MiB. A alternativa, sem dúvida, a reavaliação mais agressiva (64/64; sem distinção entre bytes zero e diferentes de zero), nos levaria a um tamanho de bloco de pior caso de 2,25 MiB, deixando espaço para novos aumentos no limite de gás para 300 milhões no futuro.
Feedback bem-vindo!
3 curtidas
Ei, bela postagem!! Definitivamente interessante ver os números e um belo resumo fácil de digerir!
Quer saber aqui se isso também considera o BAL do pior caso? ou seja. Isso é BAL + Block ou apenas Block data?
Outra dúvida que tenho é em relação à rede em geral. Como estão os números de propagação para blocos de 2,3 MiB? IIRC, acima de 1 MB já estamos vendo tempos de propagação degradados. Não tem certeza se temos em vista alguma melhoria na camada p2p que possa tornar isso gerenciável? CC: @cskiraly?
Além disso, neste tópico, qual é a sua opinião sobre se livrar completamente das listas de acesso? Não parece mais fácil? Eles são realmente necessários para manter a compatibilidade neste momento? Considerando todas as coisas, provavelmente romperemos com a reprecificação?
Obrigado pela postagem!
1 Curtir
Em relação ao pior caso: os maiores blocos compactados pelo Snappy ocorrem quando todos o gás disponível é gasto em calldata. Nesse cenário, o BAL está vazio. Grandes BALs e grandes dados de chamadas são, portanto, mutuamente exclusivos. Além disso, calldata produz blocos estritamente piores (ou seja, maiores) que os BALs, uma vez que tudo declarado em um BAL deve realmente ser acessado ou modificado – caso contrário, o bloco será inválido.
Quanto à compatibilidade: basicamente, sim. No mínimo, eles devem ser reavaliados para contabilizar adequadamente o custo dos dados e não contribuir mais para o pior tamanho de bloco. Reavaliá-los razoavelmente é mais simples e seguro do que tentar a depreciação total, pelo menos no curto/médio prazo.
Fontesethresear
