A Ethereum lançou o roteiro de expansão, o que há de diferente desta vez?

Título original: Ethereum lança roteiro de expansão, o que há de diferente desta vez?

Autor original: @VitalikButerin Tradução: Peggy

Fonte original:

Reprodução: Mars Finance

Nota do editor: À medida que o ecossistema Ethereum continua a crescer, a questão de como expandir a rede sem sacrificar segurança e descentralização torna-se um tema central. Neste artigo, Vitalik Buterin detalha o caminho de expansão do Ethereum: a curto prazo, melhorias técnicas como otimização do mecanismo Gas e paralelismo na validação de blocos aumentam a eficiência de execução; a longo prazo, a rede será impulsionada por ZK-EVM e arquitetura de dados blobs para ampliar sua escala.

De modo geral, essa rota oferece um plano de expansão faseado, visando fornecer uma base para o contínuo aumento da capacidade da rede Ethereum nos próximos anos.

A seguir, o texto original:

Vamos falar sobre expansão (scaling). Aqui, dividimos em duas partes principais: expansão de curto prazo e de longo prazo.

Expansão de curto prazo

Sobre expansão de curto prazo, já escrevi sobre isso em outros lugares. A ideia central é a seguinte:

· Listas de acesso a nível de bloco (block-level access lists) (serão lançadas na atualização Glamsterdam) permitirão a paralelização na validação de blocos.

· ePBS (também será lançado na Glamsterdam) possui várias funcionalidades, uma delas é: possibilitar o uso seguro de uma maior proporção do tempo de cada slot para validar blocos, ao invés de apenas alguns centenas de milissegundos atuais.

· Reajuste de preços do Gas (gas repricing) garantirá que os custos de gas de várias operações estejam alinhados com seu tempo de execução real (e outros custos associados). Também estamos explorando mecanismos de gas multidimensional, que permitem definir limites separados para diferentes recursos. A combinação dessas abordagens nos permite usar uma maior proporção do tempo de slot na validação de blocos, sem preocupações com casos extremos.

Sobre gas multidimensional, traçamos uma rota faseada. Na primeira fase, na atualização Glamsterdam, vamos separar o “custo de criação de estado” do “custo de execução e calldata”.

Por exemplo, atualmente: uma operação SSTORE, se alterar o armazenamento de não zero para não zero, custa 5000 gas; se de zero para não zero, custa 20000 gas.

Na reprecificação de gas na Glamsterdam, esse custo adicional será significativamente aumentado (por exemplo, para 60000). O objetivo é, ao aumentar o limite de gas, permitir que a expansão da capacidade de execução seja muito mais rápida que a expansão do tamanho do estado.

Sobre o motivo, já escrevi anteriormente:

Portanto, na Glamsterdam: essa operação SSTORE consumirá 5000 de “gas comum”, além de aproximadamente 55000 de “gas de criação de estado”.

É importante notar que: o gas de criação de estado não será incluído no limite de aproximadamente 16 milhões de gas por transação.

Isso significa que será possível criar contratos mais complexos do que atualmente.

Como funciona a implementação do gas multidimensional no EVM?

Aqui surge uma questão: o design do EVM assume que o gas possui uma única dimensão, por exemplo, as operações GAS, CALL, etc., baseadas nesse pressuposto.

Nossa solução é manter dois invariantes:

Se você inicia uma chamada com X gas, essa chamada terá X gas disponíveis, que podem ser usados para “operações comuns”, “criação de estado” ou outras dimensões que possam ser adicionadas futuramente.

Se o opcode GAS informa que você tem Y gas, e você inicia uma chamada que consome X gas, após a chamada, você ainda terá pelo menos Y − X gas, disponível para operações subsequentes.

A implementação específica é: introduzimos N+1 dimensões de gas. Por padrão, N=1 (criação de estado), e uma dimensão adicional chamada reservoir (reservatório).

A lógica de execução do EVM é:

Priorizar o consumo de gas na dimensão dedicada, se possível;

Se não for suficiente, consumir do reservoir.

Por exemplo, se você possui: (100000 de gas para criação de estado, 100000 de reservoir)

Se você criar três estados com SSTORE, a evolução do gas será: (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000).

Com esse design:

O opcode GAS retorna o valor do reservoir;

A chamada (CALL) passará uma quantidade específica de gas do reservoir, além de todos os outros gas não reservados.

Precificação do gas multidimensional

Depois, introduziremos uma precificação multi-dimensional, permitindo que diferentes recursos tenham preços de gas flutuantes distintos.

Isso trará:

Maior sustentabilidade econômica a longo prazo;

Melhor alocação de recursos.

Veja mais detalhes em:

E o mecanismo de reservoir resolve exatamente o problema de chamadas secundárias (sub-call) mencionado no artigo final.

Expansão de longo prazo

A expansão de longo prazo foca em duas frentes principais: ZK-EVM e Blobs.

Blobs

Para os blobs, planejamos continuar iterando o PeerDAS, visando alcançar uma capacidade de throughput de aproximadamente 8 MB/s.

Esse nível:

Suficiente para atender às necessidades do próprio Ethereum;

Não pretende se tornar uma “camada de dados global”.

Atualmente, os blobs são usados principalmente em L2. No futuro, planejamos que os dados de blocos do Ethereum sejam escritos diretamente em blobs.

O objetivo é permitir que as pessoas possam verificar uma rede Ethereum altamente escalável sem precisar baixar e reexecutar toda a cadeia:

ZK-SNARKs eliminam a necessidade de reexecução;

PeerDAS + blobs possibilitam verificar a disponibilidade de dados sem baixar toda a informação.

ZK-EVM

Para ZK-EVM, nosso objetivo é aumentar gradualmente a dependência da rede em relação a ela.

2026: surgirão clientes compatíveis com ZK-EVM, permitindo que os nós participem de attestations usando ZK-EVM. Ainda não serão suficientemente seguros para que toda a rede dependa dela, mas cerca de 5% da rede poderá usá-la sem problemas. (Se ocorrerem problemas com ZK-EVM, você não perderá sua staking, mas poderá construir em blocos inválidos, perdendo recompensas.)

2027: começaremos a recomendar que uma maior proporção de nós execute ZK-EVM, focando em validação formal e melhorias de segurança. Mesmo que apenas 20% da rede utilize ZK-EVM, poderemos aumentar significativamente o limite de gas, pois isso oferece uma via de validação de baixo custo para validadores solo, que representam menos de 20% da rede.

Quando a tecnologia estiver madura: introduziremos um mecanismo de prova 3-de-5, ou seja, um bloco deve conter pelo menos 3 provas de 5 diferentes sistemas de prova para ser considerado válido. Naquela época, esperamos que, além dos nós de indexação, a maioria dos nós dependa de provas ZK-EVM.

A longo prazo: continuaremos aprimorando o ZK-EVM, tornando-o mais robusto e realizando validações formais mais rigorosas. Essa fase pode envolver mudanças na camada da máquina virtual, como a direção RISC-V.

Veja mais detalhes em: