Escalonar o Ethereum L1 é um componente chave do futuro roadmap de pesquisa e desenvolvimento. Nos próximos cinco anos, o Ethereum tem como objetivo melhorar significativamente a execução do L1. Isso acontecerá em paralelo com melhorias na disponibilidade de dados e consenso (por exemplo, mesmo que planejemos aumentar a capacidade de blobs e melhorar a experiência do usuário para L2s, não significa que não possamos aumentar o limite de gás e melhorar a experiência do usuário no L1).

Existem vários EIPs e propostas em andamento, tanto de curto quanto de 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 forma escalonada após a implementação de certos EIPs e saberemos que é seguro aumentar o limite de gás.

Se cinco anos parecem muito tempo, lembre-se de que o objetivo do Ethereum é escalar enquanto preserva ocapacidade para qualquer pessoa verificar a redeou participar de um consenso sem depender de terceiros. Amamos nossos stakers solos e executores de nós! Além disso, estamos administrando um protocolo de várias centenas de bilhões de dólares.

Colhendo os frutos mais fáceis

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

Como @dankradcomo mencionado no tweet acima, podemos ver em breve um aumento no limite de gás L1 de 30 Mgas/block para 36 Mgas/block. Normalmente, tentamos aumentar o gás no 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 @giulio2002alteraria isso para um cronograma predefinido que aumenta gradualmente o limite de gás ao longo do tempo.

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

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

Post 4844 L2s principalmente postam seus dados em blobs, pois é significativamente mais barato do que usar CALLDATA L1, portanto, podemos revisitar como precificamos esse 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.

Atrasando a raiz do estadoé outra proposta com o objetivo de ser incluída no hardfork Fusaka. Isso removeria o cálculo da stateroot (intensivo computacionalmente) do caminho crítico da verificação do bloco e o atrasaria por 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.

A fim de 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 atrasar a raiz do estado nos dá o luxo de fazê-lo em 2 slots em vez de 1.

Colhendo as frutas não tão baixas penduradas

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

Como @jtguibasdiz,

"estamos prestes a provar toda a ethereum nesses caras maus:"

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

ZK também pode ajudar a acelerar o roadmap de estado sem nos dar a opção de pivotar para longe.árvores de verkle (um pré-requisito para a falta de estado) em binárioárvores de Merkle, uma estrutura de árvore mais otimizada que é amigável à SNARK e segura para a quântica. A ausência de estado transfere 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 estão mirando um lançamento em maio de 2025 paraEIP-7639esta é a primeira atualização relacionada ao vencimento histórico que tem como objetivo limitar os dados históricos nos clientes de execução. A EIP-7639 propõe podar o estado histórico antes da mesclagem e espera-se que libere alguns 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 sobre aumentos no limite de gás.

Antes de podermos aumentar com segurança o gás em 100x, conforme descrito no roteiro de Justin Drake, precisaremos de um ingrediente final: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, mantendo os outros em níveis mais gerenciáveis ​​em comparação com um aumento uniforme.

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

Bônus: outros itens do roteiro ajudando a escalar o Ethereum

O roteiro de pesquisa e desenvolvimento do Ethereum não é sequencial; muitos aspectos estão sendo desenvolvidos em paralelo e, às vezes, as propostas têm um efeito colateral interessante de melhorar a escalabilidade, mesmo que esse não fosse seu propósito inicial.

Uma dessas propostas éEIP-7732. Como o nome sugere, o ePBS consagra o que o MEV Boost faz extra-protocolo (desacopla a tarefa de propor blocos da construção de blocos) e elimina a necessidade de retransmissão, melhorando as propriedades resistentes à censura do Ethereum. Como subproduto, ele otimiza o pipeline 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 experiência do usuário para usuários de L1 e rollups baseados, mas também aumentaria a capacidade de execução e de blob do L1 como benefício adicional.

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

Isenção de responsabilidade:

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