Agora, escalabilidade.
Existem dois grupos: curto prazo e longo prazo.
Já abordei a escalabilidade de curto prazo em outros locais. Basicamente:
Listas de acesso em nível de bloco (previstas para Glamsterdam) permitem que os blocos sejam verificados em paralelo.
ePBS (também prevista para Glamsterdam) oferece várias funcionalidades, incluindo tornar seguro utilizar uma grande fração de cada slot (em vez de apenas alguns centenas de milissegundos) para verificar um bloco.
A reprecificação do gas garante que os custos de gas das operações estejam alinhados com o tempo real de execução (além de outros custos envolvidos). Estamos também iniciando explorações em gas multidimensional, que assegura limites distintos para diferentes recursos. Ambas as soluções permitem utilizar frações maiores do slot para verificar blocos, sem riscos de casos excepcionais.
Existe um roadmap em múltiplas etapas para gas multidimensional.
Primeiro, em Glamsterdam, os custos de “criação de estado” são separados dos custos de “execução e calldata”. Atualmente, um SSTORE que altera um slot de não zero para não zero custa 5.000 gas, enquanto um SSTORE que altera de zero para não zero custa 20.000. Uma das reprecificações de Glamsterdam aumenta significativamente esse valor extra (por exemplo, para 60.000); nosso objetivo com isso, junto ao aumento do limite de gas, é escalar a capacidade de execução muito mais do que a capacidade de tamanho de estado, por razões já detalhadas anteriormente (
https://
ethresear.ch/t/hyper-scalin
g-state-by-creating-new-forms-of-state/24052
). Assim, em Glamsterdam, esse SSTORE cobrará 5.000 de gas “regular” e, por exemplo, 55.000 de gas de “criação de estado”.
O gas de criação de estado NÃO será contabilizado no limite de gas de ~16 milhões de transações, o que permitirá criar contratos maiores do que atualmente.
Um desafio: como isso funciona no EVM? Os opcodes do EVM (GAS, CALL…) assumem apenas uma dimensão. Nossa abordagem mantém dois invariantes:
Ao fazer uma chamada com X gas, essa chamada terá X gas utilizável para “regular”, “criação de estado” ou outras dimensões futuras
Ao chamar o opcode GAS, ele indica que você tem Y gas; ao fazer uma chamada com X gas, ainda terá pelo menos Y-X gas, utilizável para qualquer função, após a chamada, para operações posteriores
Criamos N+1 “dimensões” de gas, onde por padrão N=1 (criação de estado), e a dimensão extra é chamada de “reservatório”. A execução no EVM consome, por padrão, as dimensões especializadas se possível; caso contrário, consome do reservatório. Por exemplo, se você tem (100.000 de gas de criação de estado, 100.000 de reservatório), ao usar SSTORE para criar novo estado três vezes, o saldo de gas evolui assim: (100.000, 100.000) -> (45.000, 95.000) -> (0, 80.000) -> (0, 20.000). GAS retorna o reservatório. CALL repassa a quantidade especificada de gas do reservatório, além de todo gas não reservado.
Depois, migramos para precificação multidimensional, onde diferentes dimensões podem ter preços flutuantes de gas. Isso proporciona sustentabilidade econômica de longo prazo e otimização (veja
https://
vitalik.eth.limo/general/2024/0
5/09/multidim.html
). O mecanismo de reservatório resolve o problema de subcalls citado ao final desse artigo.
Agora, para escalabilidade de longo prazo, há dois pontos: ZK-EVM e blobs.
Para blobs, o plano é continuar evoluindo o PeerDAS até atingir um estado final capaz de processar, idealmente, ~8 MB/seg de dados. Suficiente para as necessidades do Ethereum, sem buscar ser uma camada global de dados. Atualmente, blobs são usados por L2s. No futuro, a ideia é que os dados dos blocos do Ethereum sejam inseridos diretamente em blobs. Isso é necessário para permitir que alguém valide uma cadeia Ethereum hiper-escalada sem precisar baixar e reexecutar pessoalmente: ZK-SNARKs eliminam a necessidade de reexecução, e PeerDAS nos blobs permite verificar disponibilidade sem baixar os dados.
Para ZK-EVM, o objetivo é aumentar gradualmente a confiança em depender dele:
Clientes que permitem participar como atestador com ZK-EVMs existirão em 2026. Não serão seguros o suficiente para rodar toda a rede, mas, por exemplo, 5% da rede depender deles será aceitável. (Se o ZK-EVM falhar, você não será penalizado, apenas terá risco de construir sobre um bloco inválido e perder receita)
Em 2027, a recomendação será para uma minoria maior da rede operar com ZK-EVMs, com foco total em verificação formal e máxima segurança. Mesmo 20% da rede rodando ZK-EVMs permitirá aumentar significativamente o gaslimit, pois viabiliza limites maiores de gas e um caminho acessível para stakers solo, que representam menos de 20%.
Quando estiver pronto, avançaremos para prova obrigatória 3-de-5. Para um bloco ser válido, precisará conter 3 de 5 tipos de provas de diferentes sistemas. Nesse estágio, espera-se que todos os nós (exceto os de indexação) dependam das provas ZK-EVM.
Continuar aprimorando o ZK-EVM para torná-lo o mais robusto e formalmente verificado possível. Isso também envolverá esforços de mudança de VM (por exemplo, RISC-V).
Isenção de responsabilidade:
- Este artigo foi republicado de [vitalikbuterin]. Todos os direitos autorais pertencem ao autor original [vitalikbuterin]. Caso haja objeções a esta republicação, entre em contato com a equipe Gate Learn, que irá tratar prontamente.
- Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem aconselhamento de investimento.
- As traduções do artigo para outros idiomas são realizadas pela equipe Gate Learn. Salvo indicação, copiar, distribuir ou plagiar os artigos traduzidos é proibido.
