Escalabilidade: o ponto de situação.
Distinguem-se aqui duas vertentes: curto prazo e longo prazo.
Já abordei anteriormente as soluções de escalabilidade a curto prazo. Em síntese:
As listas de acesso ao nível do bloco, previstas para Glamsterdam, vão permitir a verificação paralela dos blocos.
O ePBS, também previsto para Glamsterdam, traz várias funcionalidades, nomeadamente a possibilidade de utilizar uma parte substancial de cada slot (em vez de apenas algumas centenas de milissegundos) para a verificação segura de blocos.
Os reajustes dos preços do gas asseguram que o custo do gas para cada operação reflete o tempo real de execução (e outros custos inerentes). Estão já a ser feitos os primeiros ensaios de gas multidimensional, que garante que os limites de recursos são definidos de forma diferenciada. Ambas as abordagens permitem utilizar uma maior fração do slot para verificar blocos, sem receio de situações excecionais.
O roadmap para o gas multidimensional contempla várias fases.
Na primeira fase, em Glamsterdam, os custos de “criação de estado” passam a estar separados dos custos de “execução e calldata”. Atualmente, um SSTORE que altera um slot de não nulo para não nulo custa 5000 gas, enquanto um SSTORE que altera de zero para não nulo custa 20000. Um dos reajustes de Glamsterdam aumenta substancialmente este diferencial (por exemplo, para 60000); o objetivo, ao combinar esta medida com o aumento do limite de gas, é escalar muito mais a capacidade de execução do que a capacidade de crescimento do estado, conforme já expliquei anteriormente (
https://
ethresear.ch/t/hyper-scalin
g-state-by-creating-new-forms-of-state/24052
). Assim, em Glamsterdam, esse SSTORE passará a cobrar 5000 de gas “regular” e, por exemplo, 55000 de “gas de criação de estado”.
O gas de criação de estado NÃO será contabilizado para o limite de cerca de 16 milhões de gas por transação, o que permitirá criar contratos de maior dimensão do que atualmente.
Um desafio prende-se com o funcionamento disto na EVM. Os opcodes da EVM (GAS, CALL, etc.) assumem todos apenas uma dimensão. A estratégia passa por manter dois princípios:
Ao efetuar uma chamada com X gas, esse valor estará disponível para “gas regular”, “criação de estado” ou outras dimensões futuras;
Se invocar o opcode GAS, que indica Y gas, e depois fizer uma chamada com X gas, continuará a ter pelo menos Y-X gas utilizável para qualquer função, após a chamada, para operações subsequentes;
O sistema cria N+1 “dimensões” de gas, sendo N=1 (criação de estado) por defeito, e a dimensão extra designada “reservatório”. Por defeito, a execução da EVM consome as dimensões especializadas sempre que possível; caso contrário, consome do reservatório. Assim, por exemplo, com (100000 de gas de criação de estado, 100000 de reservatório), ao usar SSTORE para criar novo estado três vezes, o saldo de gas evolui: (100000, 100000) -> (45000, 95000) -> (0, 80000) -> (0, 20000). O opcode GAS devolve o valor do reservatório. O CALL transmite o valor de gas especificado a partir do reservatório, mais todo o gas não reservatório.
Mais tarde, será implementada a precificação multidimensional, permitindo que diferentes dimensões tenham preços de gas flutuantes distintos. Isto garante sustentabilidade e eficiência económica a longo prazo (ver
https://
vitalik.eth.limo/general/2024/0
5/09/multidim.html
). O mecanismo do reservatório resolve o problema das subchamadas descrito no final desse artigo.
Para a escalabilidade a longo prazo, há dois eixos: ZK-EVM e blobs.
No caso dos blobs, a estratégia é continuar a evoluir o PeerDAS até atingir um estado final capaz de processar, idealmente, cerca de 8 MB/segundo de dados. Um valor suficiente para as necessidades do Ethereum, sem pretender funcionar como camada global de dados. Atualmente, os blobs são utilizados para L2s. No futuro, o objetivo é que os dados dos blocos Ethereum sejam integrados diretamente em blobs. Isto é fundamental para permitir validar uma cadeia Ethereum em hiperescala sem a necessidade de descarregar e reexecutar pessoalmente: os ZK-SNARKs eliminam a necessidade de reexecução e o PeerDAS nos blobs permite verificar a disponibilidade sem descarregar localmente.
Quanto ao ZK-EVM, o objetivo é aumentar progressivamente a confiança na sua utilização:
Em 2026, existirão clientes que permitem participar como atestador com ZK-EVMs. Não serão suficientemente seguros para que a rede dependa deles, mas, por exemplo, 5% da rede poderá utilizá-los sem problema. (Se o ZK-EVM falhar, não será penalizado; apenas corre o risco de construir sobre um bloco inválido e perder receitas)
Em 2027, será recomendado que uma minoria mais alargada da rede utilize ZK-EVMs, sendo o foco colocado na verificação formal e no reforço da segurança, entre outros. Mesmo 20% da rede a operar com ZK-EVMs permitirá aumentar significativamente o gaslimit, pois possibilita limites de gas muito superiores, mantendo um caminho económico para validadores individuais, que já são menos de 20%.
Quando estiverem reunidas as condições, avança-se para o modelo de prova obrigatória 3-em-5. Para um bloco ser válido, terá de conter 3 de 5 tipos de provas provenientes de diferentes sistemas. Nessa altura, espera-se que todos os nós (exceto os que necessitam de indexação) dependam das provas ZK-EVM.
O ZK-EVM continuará a ser melhorado, tornando-se o mais robusto e formalmente verificado possível, incluindo eventuais alterações à VM (como, por exemplo, RISC-V).
Declaração de exoneração de responsabilidade:
- Este artigo é uma republicação de [vitalikbuterin]. Todos os direitos de autor pertencem ao autor original [vitalikbuterin]. Caso exista alguma objeção a esta republicação, contacte a equipa Gate Learn, que dará seguimento ao pedido com celeridade.
- Declaração de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer aconselhamento de investimento.
- As traduções do artigo para outros idiomas são realizadas pela equipa Gate Learn. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.
