O futuro possível do Ethereum: The Surge

O roadmap do Ethereum incluía inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer2. O sharding permite que cada nó verifique e armazene apenas uma pequena parte das transações, enquanto os protocolos Layer2 constroem redes sobre o Ethereum, aproveitando sua segurança ao mesmo tempo que mantém a maior parte dos dados e cálculos fora da cadeia principal. À medida que a pesquisa avançava, esses dois caminhos acabaram se fundindo, formando um roadmap centrado em Rollup, que ainda é a estratégia de escalabilidade do Ethereum.

O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o L1 do Ethereum se concentra em ser uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo está presente em toda a sociedade: a existência do sistema judicial (L1) não é para buscar super velocidade e eficiência, mas para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) devem construir sobre essa camada base sólida, impulsionando o progresso humano.

Este ano, o roteiro centrado em Rollup alcançou resultados importantes: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou significativamente, e vários Rollups do Ethereum Virtual Machine (EVM) entraram na primeira fase. Cada L2 existe como uma "partição" com suas próprias regras internas e lógica, e a diversidade e pluralidade das formas de implementação das partições tornaram-se uma realidade. No entanto, este caminho também enfrenta alguns desafios únicos. Assim, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, ao mesmo tempo em que mantemos a robustez e a descentralização que são características do Ethereum L1.

The Surge: Objetivos-chave

1. No futuro, o Ethereum poderá alcançar mais de 100.000 TPS através do L2;

2. Manter a descentralização e robustez do L1;

3. Pelo menos algumas L2 herdaram completamente as propriedades centrais do Ethereum ( de confiar, serem abertas e resistentes à censura );

4. Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.

O conteúdo deste capítulo

1. Paradoxo do triângulo da escalabilidade
2. Avanços adicionais na amostragem de disponibilidade de dados
3. Compressão de dados
4. Plasma Generalizado
5. Sistema de prova L2 maduro
6. Melhoria da interoperabilidade entre L2
7. Expandir a execução na L1

paradoxo do triângulo da escalabilidade

O paradoxo da escalabilidade é uma ideia proposta em 2017, que afirma que existe uma contradição entre três características da blockchain: descentralização (, mais especificamente: baixo custo de operação dos nós ), escalabilidade (, que permite processar um grande número de transações ), e segurança (, onde um atacante precisa comprometer uma grande parte dos nós na rede para falhar uma única transação ).

É importante notar que o paradoxo do triângulo não é um teorema, e os posts que introduzem o paradoxo do triângulo não incluem uma prova matemática. Ele realmente fornece um argumento matemático heurístico: se um nó amigável e descentralizado (, por exemplo, um laptop de consumo ) pode validar N transações por segundo, e você tem uma cadeia que processa k*N transações por segundo, então (i) cada transação só pode ser vista por 1/k nós, o que significa que um atacante só precisa comprometer alguns poucos nós para realizar uma transação maliciosa, ou (ii) seu nó se tornará poderoso, enquanto sua cadeia não se descentralizará. O objetivo deste artigo nunca foi provar que quebrar o paradoxo do triângulo é impossível; ao contrário, ele visa mostrar que quebrar o paradoxo ternário é difícil e requer, de certa forma, sair da estrutura de pensamento implícita no argumento.

Durante muitos anos, algumas cadeias de alto desempenho afirmam resolver o trilema sem mudar fundamentalmente a arquitetura, geralmente através da aplicação de técnicas de engenharia de software para otimizar os nós. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós no Ethereum. Este artigo irá explorar por que isso acontece e por que apenas a engenharia de software do cliente L1 não pode escalar o Ethereum.

No entanto, a combinação de amostragem de disponibilidade de dados com SNARKs realmente resolve o paradoxo triangular: permite que os clientes verifiquem que uma certa quantidade de dados está disponível, realizando apenas o download de uma pequena quantidade de dados e executando uma quantidade muito limitada de cálculos, e que uma certa quantidade de etapas de cálculo foi executada corretamente. Os SNARKs são sem necessidade de confiança. A amostragem de disponibilidade de dados possui um sutil modelo de confiança few-of-N, mas mantém as características fundamentais que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.

Outra maneira de resolver o dilema das três dificuldades é a arquitetura Plasma, que usa técnicas engenhosas para transferir a responsabilidade pela disponibilidade dos dados de monitoramento para os usuários de uma maneira compatível com incentivos. Entre 2017 e 2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, o Plasma era muito limitado em termos de execução segura, mas com a popularização dos SNARKs(, as provas de conhecimento zero concisas e não interativas), a arquitetura Plasma tornou-se mais viável para uma gama de cenários de uso mais ampla do que nunca.

Avanços adicionais na amostragem de disponibilidade de dados

Que problema estamos a resolver?

Em 13 de março de 2024, quando a atualização Dencun for lançada, a blockchain Ethereum terá 3 blobs de aproximadamente 125 kB a cada slot de 12 segundos, ou seja, a largura de banda de dados disponível por slot será de aproximadamente 375 kB. Supondo que os dados de transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o TPS máximo de Rollup na Ethereum será: 375000 / 12 / 180 = 173,6 TPS.

Se adicionarmos o valor máximo teórico do calldata do Ethereum (: cada slot 30 milhões de Gas / por byte 16 gas = cada slot 1.875.000 bytes ), isso se torna 607 TPS. Usando o PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para o calldata.

Esta é uma melhoria significativa para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é de 16 MB por slot, e se combinado com melhorias na compressão de dados Rollup, isso trará cerca de ~58000 TPS.

O que é isso? Como funciona?

PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus no campo primo de 253 bits (. Nós transmitimos as partes do polinômio, onde cada parte contém 16 valores de avaliação de 16 coordenadas adjacentes entre um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 ) pode ser recuperado de acordo com os parâmetros propostos: qualquer 64 de 128 amostras possíveis ( pode recuperar o blob.

![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(

O funcionamento do PeerDAS é permitir que cada cliente ouça um pequeno número de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo sample de qualquer blob, e solicita ao par global na rede p2p quem irá ouvir diferentes sub-redes ) para requisitar os blobs que necessita nas outras sub-redes. Uma versão mais conservadora, o SubnetDAS, usa apenas o mecanismo de sub-rede, sem consultas adicionais ao nível de pares. A proposta atual é que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto outros nós (, ou seja, clientes ) utilizem o PeerDAS.

Em teoria, podemos escalar um "1D sampling" bastante grande: se aumentarmos o número máximo de blobs para 256( com o objetivo de 128), então podemos atingir a meta de 16MB, onde a amostragem de disponibilidade de dados tem cada nó 16 amostras * 128 blobs * 512 bytes por blob por amostra = 1 MB de largura de banda de dados por slot. Isso está apenas ligeiramente dentro da nossa margem de tolerância: é viável, mas isso significa que clientes com largura de banda limitada não podem amostrar. Podemos otimizar isso até certo ponto reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentará o custo de reconstrução.

Portanto, queremos avançar ainda mais, realizando a amostragem 2D (2D sampling), este método não apenas realiza amostragem aleatória dentro do blob, mas também entre os blobs. Aproveitando a propriedade linear do compromisso KZG, expandimos um conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais, que codificam redundantemente as mesmas informações.

Assim, no final, queremos ir mais longe e realizar amostragem 2D, que não só amostra aleatoriamente dentro do blob, mas também entre os blobs. A propriedade linear do compromisso KZG é utilizada para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais com codificação redundante da mesma informação.

É crucial que a expansão do compromisso de cálculo não exija blobs, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem blocos precisam apenas ter o compromisso KZG de blobs, e podem confiar na amostragem de disponibilidade de dados (DAS) para validar a disponibilidade dos blocos de dados. A amostragem de disponibilidade de dados unidimensional (1D DAS) é essencialmente também amigável à construção de blocos distribuídos.

(# O que mais precisa ser feito? Quais são as concessões?

A próxima etapa é a implementação e lançamento do PeerDAS. Depois disso, aumentaremos continuamente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, este é um processo gradual. Ao mesmo tempo, esperamos que haja mais trabalho acadêmico para normatizar o PeerDAS e outras versões do DAS e suas interações com questões de segurança, como as regras de seleção de fork.

Em estágios mais distantes no futuro, precisaremos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos finalmente poder transitar do KZG para uma alternativa que seja segura contra quânticos e não exija configurações confiáveis. Atualmente, ainda não está claro quais opções candidatas são amigáveis à construção de blocos distribuídos. Mesmo utilizando técnicas de "força bruta" caras, ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, não é suficiente para atender à demanda, pois, embora tecnicamente, o tamanho de um STARK seja O)log(n) * log###log(n() hash ( usando STIR(, na prática, o STARK é quase tão grande quanto o blob inteiro.

O caminho da realidade de longo prazo que eu considero é:

1. Implementar o DAS 2D ideal;
2. Manter o uso de 1D DAS, sacrificando a eficiência da largura de banda de amostragem, aceitando um limite inferior de dados em prol da simplicidade e robustez.
3. Desistir do DA e aceitar completamente o Plasma como a nossa principal arquitetura Layer2 em foco.

Por favor, note que mesmo que decidamos expandir a execução diretamente na camada L1, essa opção ainda existe. Isso porque, se a camada L1 tiver que lidar com uma grande quantidade de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão uma maneira eficiente de verificar sua correção, portanto, teremos que usar na camada L1 as mesmas tecnologias que o Rollup), como ZK-EVM e DAS).

(# Como interagir com outras partes do roteiro?

Se a compressão de dados for implementada, a demanda por DAS 2D diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para os protocolos e mecanismos de construção de blocos distribuídos: embora o DAS seja teoricamente amigável à reconstrução distribuída, na prática isso precisa ser combinado com a proposta da lista de inclusão de pacotes e seu mecanismo de escolha de fork ao redor.

) compressão de dados

(# Que problema estamos a resolver?

Cada transação em um Rollup ocupa uma grande quantidade de espaço de dados on-chain: uma transferência ERC20 requer cerca de 180 bytes. Mesmo com amostragem ideal de disponibilidade de dados, isso limita a escalabilidade do protocolo Layer. Cada slot 16 MB, obtemos:

16000000 / 12 / 180 = 7407 TPS

E se pudermos resolver não apenas os problemas do numerador, mas também os problemas do denominador, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?

O que é isso, como funciona?

Na minha opinião, a melhor explicação é esta imagem de há dois anos:

![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###

A compressão de zeros é feita substituindo cada sequência longa de zeros por dois bytes, indicando quantos zeros existem. Além disso, aproveitamos as propriedades específicas das transações:

Agregação de assinaturas: mudamos de assinaturas ECDSA para assinaturas BLS