Ethereum revela roteiro de escalabilidade, o que é diferente desta vez?

Autor original: @VitalikButerin
Tradução: Peggy, BlockBeats

Nota do editor: À medida que o ecossistema Ethereum continua a crescer, alcançar a escalabilidade da rede sem sacrificar a segurança e a descentralização tornou-se uma questão central. Neste artigo, Vitalik Buterin delineia ainda mais o caminho de escalabilidade do Ethereum: no curto prazo, melhorando a eficiência de execução por meio da otimização do mecanismo de Gas, paralelização da validação de blocos e outras atualizações técnicas; no longo prazo, contando com a estrutura de dados ZK-EVM e blobs para impulsionar a escalabilidade da rede.

No geral, este roteiro fornece um plano de escalabilidade faseado projetado para estabelecer a base para o Ethereum expandir continuamente sua capacidade de rede nos próximos anos.

O seguinte é o texto original:

Agora vamos falar sobre escalabilidade. Ela pode ser dividida principalmente em duas partes: escalabilidade de curto prazo e escalabilidade de longo prazo.

Escalabilidade de Curto Prazo

Em relação à escalabilidade de curto prazo, escrevi sobre isso em outro lugar. A ideia central é mais ou menos a seguinte:

· Listas de acesso de nível de bloco (que serão introduzidas na atualização Glamsterdam) podem permitir a paralelização da validação de blocos.

· O ePBS (também a ser introduzido em Glamsterdam) tem vários recursos, um dos quais é: permite que usemos com segurança uma proporção maior de tempo em cada intervalo para validar blocos, em vez de apenas usar alguns poucos milissegundos como agora.

· A redefinição do preço do gás garantirá que o custo do gás das várias operações permaneça consistente com seu tempo de execução real (e outros custos que incorrem). Também estamos no início da exploração de um mecanismo de gás multidimensional, permitindo que diferentes recursos tenham limites separados. A combinação desses dois pode permitir que usemos uma proporção maior do tempo do intervalo na validação de blocos sem nos preocuparmos com cenários extremos.

Em relação ao gás multidimensional, estabelecemos um roteiro em fases. A primeira fase está na atualização Glamsterdam, onde o "custo de configuração do estado" é separado dos "custos de execução e de calldata".

Por exemplo, atualmente: uma operação SSTORE custa 5000 gas se o slot de armazenamento mudar de não-zero → não-zero; custa 20000 gas se mudar de zero → não-zero.

Em um evento de reajuste de gás em Glamsterdam, esse custo adicional será significativamente aumentado (por exemplo, aumentado para 60000). O objetivo é aumentar o custo, ao mesmo tempo em que a taxa de expansão da capacidade de execução é significativamente maior do que a taxa de expansão do tamanho do estado.

Em relação aos motivos, já escrevi antes: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Portanto, em Glamsterdam: Esta operação SSTORE consumirá 5000 "gás base", por exemplo, 55000 "gás de criação de estado".

É importante notar: O gás de criação de estado não conta para o limite de gás de transação de aproximadamente 16 milhões.

Isso significa: Criar contratos maiores do que agora se tornará possível.

Como o Gás Multidimensional é alcançado no EVM?

Aqui está um problema: O design do EVM assume que o gás tem apenas uma dimensão; por exemplo, GAS, CALL e outros opcodes são todos baseados nessa suposição.

Nossa solução é manter dois invariantes:

Se você iniciar uma chamada com X gás, essa chamada terá X gás disponível para "operações básicas", "criação de estado" ou quaisquer outras dimensões adicionais futuras.

Se o opcode GAS lhe disser que você atualmente tem Y gás, e então você iniciar uma chamada que consome X gás, após a chamada retornar, você ainda terá pelo menos Y − X gás disponível para operações subsequentes.

A implementação específica é: Introduzimos N+1 dimensões de gás. Por padrão, N = 1 (criação de estado), e a dimensão adicional é chamada de reservatório.

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

Se possível, priorize o consumo de gás a partir de dimensões especializadas.

Se não for suficiente, consuma do reservatório.

Por exemplo, se você tiver: (100000 gás criado pelo estado, 100000 reservatório)

Se você usar SSTORE para criar três novos estados, o processo de transformação de gás é: (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000)

Neste projeto:

O opcode GAS retorna o reservatório

CALL passará uma quantidade específica de gás do reservatório e todo o gás que não está no reservatório

Preços de Gás Multidimensionais

Mais tarde, introduziremos preços multidimensionais, permitindo que diferentes dimensões de recursos tenham diferentes preços de gás flutuantes.

Isso trará:

Melhor sustentabilidade econômica a longo prazo

Eficiência otimizada na alocação de recursos

Veja mais em: https://vitalik.eth.limo/general/2024/05/09/multidim.html

O mecanismo do reservatório resolve de forma elegante o problema das subchamadas mencionado no final desse artigo.

Escalabilidade a Longo Prazo

A escalabilidade a longo prazo envolve principalmente duas direções: ZK-EVM e Blobs.

Blobs

Para os blobs, planejamos continuar a iterar no PeerDAS, com o objetivo de alcançar, eventualmente, uma taxa de transferência de dados de aproximadamente 8 MB/segundo.

Esta escala:

É suficiente para atender às próprias necessidades do Ethereum

E não se destina a se tornar uma "camada de dados global".

Atualmente, os blobs são usados principalmente para L2. O plano futuro é ter os dados do bloco do Ethereum escritos diretamente nos blobs.

O objetivo de fazer isso é permitir que as pessoas validem uma rede Ethereum altamente escalável sem baixar e reexecutar toda a cadeia:

ZK-SNARKs eliminam a necessidade de reexecução

PeerDAS + blobs permitem a verificação da disponibilidade de dados sem baixar todos os dados

ZK-EVM

Para o ZK-EVM, nosso objetivo é aumentar gradualmente a dependência da rede dele.

2026: Surgiram clientes que dão suporte ao ZK-EVM, permitindo que os nós participem da atestação com o ZK-EVM. No entanto, eles ainda não são seguros o suficiente para permitir que toda a rede dependa deles para funcionar. No entanto, é aceitável se cerca de 5% da rede os usar. (Se houver problemas com o ZK-EVM, você não será penalizado no slashing, mas poderá construir blocos inválidos, resultando em perda de receita.)

2027: Começaremos a recomendar que uma proporção maior de nós execute o ZK-EVM, enquanto nos concentramos na verificação formal e nos aprimoramentos de segurança. Mesmo que apenas 20% da rede use o ZK-EVM, podemos aumentar significativamente o limite de gás, pois isso oferece um caminho de validação de baixo custo para os participantes solo, e a proporção de participantes solo é inferior a 20%.

Maturidade pós-técnica: Introduziremos um mecanismo de prova obrigatória de 3 de 5. Ou seja, um bloco deve conter pelo menos 3 provas de 5 sistemas de prova diferentes para ser considerado válido. Até então, esperamos que a maioria dos nós dependa das provas ZK-EVM, exceto para os nós que precisam fazer indexação.

A longo prazo: Continuar a melhorar o ZK-EVM para torná-lo mais robusto e submeter a uma verificação formal mais rigorosa. Esta fase também pode envolver mudanças no nível da máquina virtual, como a direção do RISC-V.

Veja: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

[Link do artigo original]