A escalabilidade do Ethereum L1 é um componente chave do futuro roadmap de P&D. Nos próximos cinco anos, o Ethereum pretende melhorar significativamente a execução do L1. Isto acontecerá em paralelo com melhorias na disponibilidade de dados e no consenso (por exemplo, enquanto planeamos aumentar a capacidade de blob e melhorar a UX para L2s, isso não significa que não podemos aumentar o limite de gás e melhorar a UX no L1).

Existem vários EIPs e propostas no pipeline a curto e longo prazo para escalar o L1 como@drakefjustinesboços aqui:

Com base neste roteiro, podemos aumentar em 100 vezes o limite de gás nos próximos cinco anos. Alguns desses aumentos serão feitos de maneira escalonada após a implementação de determinados EIPs e quando soubermos que é seguro aumentar o limite de gás.

Se cinco anos parecem muito tempo, lembre-se que o objetivo do Ethereum é escalar enquanto preserva aa capacidade para qualquer pessoa verificar a redeou participar no consenso sem depender de terceiros. Amamos os nossos apostadores individuais e operadores de nós! Além disso, estamos a administrar um protocolo de vários bilhões de dólares.

Apanhando os frutos fáceis

Os aumentos de 10x no limite de gás estão mais distantes, mas também podemos fazer aumentos menores a qualquer momento, pois os validadores podem ajustar manualmente seus nós para sinalizar que estão dispostos a lidar com blocos maiores. Isso está acontecendo hoje:

Como @dankradnas linhas acima do tweet, podemos ver um aumento no limite de gás L1 de 30 Mgas/bloco -> 36 Mgas/bloco muito em breve. Normalmente tentamos aumentar o gás em L1 periodicamente quando os desenvolvedores principais consideram seguro fazê-lo e à medida que os requisitos de hardware e largura de banda se tornam mais gerenciáveis ao longo do tempo. Algumas propostas comoEIP-7783por @giulio2002mudaria isso para um cronograma predeterminado que aumenta gradualmente o limite de gás ao longo do tempo.

Existem outras atualizações de baixo custo @davidecrapiscoloca-o num tweet recente que deve ajudar a pavimentar o caminho para mais aumentos menores no limite de gás.

Os desenvolvedores principais discutiram recentemente a inclusãoEIP-7623no próximo hardfork da Pectra (sem data definida, mas o final do primeiro trimestre e início do segundo trimestre de 2025 é a minha estimativa). Este EIP ajustaria os preços para CALLDATA, reduzindo o tamanho máximo do bloco e nos dando a capacidade de aumentar o limite de gás de execução. CALLDATA era onde as L2s postariam seus dados antesEIP-4844e blobs.

Post 4844 L2s principalmente postam seus dados em blobs, pois é significativamente mais barato do que usar L1 CALLDATA, portanto, podemos revisar como precificar este recurso e liberar espaço para operações EVM. Como Davide estima, isso poderia resultar em um aumento de 2x no limite de gás.

Atrasar a raiz do estadoé outra proposta com o objetivo de ser incluída na atualização Fusaka hardfork. Isso removeria o cálculo do stateroot (intensivo em termos de computação) do caminho crítico da verificação do bloco e o atrasaria em um slot, melhorando a latência e abrindo caminho para tempos de bloco mais rápidos (uma atualização de escalabilidade e UX para L1). Essa atualização também se encaixa bem com algumas das melhorias de escalabilidade mais complexas que virão com a SNARKificação do EVM.

Para alcançar aumentos na ordem de grandeza do limite de gás, precisaremos ser capazes de provar o EVM em tempo real, ou próximo do tempo real, pois adiar a raiz do estado nos dá o luxo de fazê-lo em 2 slots em vez de 1.

Escolher a fruta não tão baixa pendurada

A mágica ZK será a principal ferramenta que usaremos para alcançar o aumento do limite de gás em 100x, o que pode ser visto como a estrela guia para o roteiro de execução.

Como @jtguibasdiz,

"estamos prestes a provar a totalidade do Ethereum nestes rapazes maus:"

Os bad boys a que ele se refere são provadores ZK e Justin Drake espera que os vendedores sejam capazes de provar a totalidade do EVM nessas máquinas no próximo ano. Em vez de executar um cliente de camada de execução e ingenuamente reexecutar cada transação por conta própria, tudo o que você precisa fazer é verificar uma prova. Executar a versão ZK do cliente de execução eliminará efetivamente os requisitos de hardware necessários para executar um cliente baunilha, tornando a verificação de um bloco de 30 Mgas ou 3 Ggas o mesmo.

ZK também pode ajudar a acelerar o roadmap da ausência de estado, dando-nos a opção de mudar de direçãoverkle árvores (um pré-requisito para a ausência de estado) em binárioárvores de Merkle, uma estrutura de árvore mais otimizada, amigável ao SNARK e segura contra ataques quânticos. A falta de estado empurra as responsabilidades de armazenamento de estado para os construtores de blocos, o que significa que outros nós na rede não precisam mais armazenar os dados de estado completos, permitindo que eles acompanhem tamanhos de bloco maiores. Isso será complementado ainda mais com a expiração do histórico ouEIP-4444.

Os desenvolvedores principais têm como alvo o lançamento em maio de 2025 paraEIP-7639esta é a primeira atualização relacionada com a expiração histórica que tem como objetivo limitar os dados históricos nos clientes de execução. O EIP-7639 propõe podar o estado histórico antes da fusão e espera-se que liberte algumas centenas de gigabytes de espaço em disco para os operadores de nós e não exija um hardfork. Embora isso não se traduza diretamente em melhorias de escalabilidade, ajuda a tornar os nós mais leves e facilita a digestão das decisões relacionadas com o aumento do limite de gás.

Antes de podermos aumentar com segurança o gás em 100x, como descrito no roadmap de Justin Drake, precisaremos de um último ingrediente:multi-dimensional EIP-1559. Discutimos anteriormente a repricing CALLDATA, o EIP-1559 multidimensional expande isso e nos dá a capacidade de repricing recursos que impactam o crescimento do estado e o crescimento do tamanho de armazenamento. Ajustando esses parâmetros, podemos tornar recursos como a execução do EVM mais abundantes, enquanto mantemos os outros em níveis mais gerenciáveis em comparação com um aumento uniforme.

Estamos hoje a 30 Mgas/bloco; estas atualizações levar-nos-ão a 3 Ggas/bloco, um aumento de 100 vezes, nos próximos cinco anos.

Bónus: outros itens de roadmap que ajudam a escalar o Ethereum

O roteiro de P&D do Ethereum não é sequencial; muitos aspectos estão sendo desenvolvidos em paralelo e, às vezes, as propostas têm um efeito colateral positivo de melhorar a escalabilidade, mesmo que esse não fosse seu objetivo inicial.

Uma tal proposta é EIP-7732. Como o nome sugere, a ePBS consagra o que o MEV Boost faz extra-protocolo (desvincula a tarefa de propor blocos da construção de blocos) e elimina a necessidade de retransmissão, melhorando as propriedades de resistência à censura do Ethereum. Como subproduto, otimiza o fluxo de produção de blocos, dando aos validadores mais tempo para produzir um bloco, resultando em otimizações de largura de banda e CPU que podem se traduzir em aumentos no limite de gás, conforme mencionado por Giulio aqui.

Também houve discussões para diminuir os tempos de slot do Ethereum; isso melhoraria a UX para os usuários de L1 e rollups baseados, mas também aumentaria a capacidade de execução e de blob do L1 como um benefício adicional.

Há muito para se animar quando se trata de dimensionar o L1 (direta ou indiretamente) e, o mais importante, o caminho para 100 vezes o limite de gás está claro e alcançável. Vejo você em 36 Mgas e além em breve!

Aviso legal:

1. Este artigo é reproduzido de [2077 Research]. Todos os direitos autorais pertencem ao autor original [@acseth2032]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão tratar disso prontamente.
2. Aviso de Responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe de tradução da gate Learn faz traduções do artigo para outros idiomas. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.