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 irá enfatizar ainda mais a 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 chamada; 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!
1 Curtir
Fontesethresear
