Novo artigo de Vitalik: O futuro possível do Ethereum, The Surge

O roteiro do Ethereum inicialmente incluía duas estratégias de escalabilidade: sharding e protocolos Layer 2. O sharding permite que cada nó valide e armazene apenas uma pequena parte das transações, enquanto os protocolos Layer 2 mantêm a maior parte dos dados e cálculos fora da cadeia principal. Essas duas abordagens acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalabilidade atual do Ethereum.

O roteiro centrado em Rollup propõe uma divisão de trabalho simples: o Ethereum L1 se concentra em se tornar uma camada base poderosa e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Este ano, esse roteiro alcançou resultados importantes: o lançamento dos blobs EIP-4844 aumentou significativamente a largura de banda de dados do Ethereum L1, vários (EVM) Rollup entraram na primeira fase. No entanto, esse caminho também enfrenta alguns desafios únicos.

Os principais objetivos do Surge incluem:

1. No futuro, o Ethereum pode alcançar mais de 100 mil TPS através do L2;
2. Manter a descentralização e a robustez do L1;
3. Pelo menos algumas L2 herdam completamente as propriedades centrais do Ethereum, (, de confiança, abertas e resistentes à censura );
4. Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.

Este artigo irá explorar os seguintes aspectos:

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 execução na L1

Paradoxo da Escalabilidade

O paradoxo do triângulo da escalabilidade argumenta que há uma contradição entre a descentralização, escalabilidade e segurança da blockchain. Embora não seja um teorema matemático rigoroso, ele destaca a dificuldade de quebrar essa contradição. Algumas cadeias de alto desempenho afirmam ter resolvido o paradoxo tríplice, mas na realidade, operar nós é mais difícil do que no Ethereum.

A combinação de amostragem de disponibilidade de dados e SNARKs realmente resolve o paradoxo triangular: ela permite que o cliente valide que uma certa quantidade de dados está disponível e que uma certa quantidade de etapas de cálculo é executada corretamente, baixando apenas uma pequena quantidade de dados e executando um número muito limitado de cálculos. A arquitetura Plasma também é uma solução, pois transfere a responsabilidade de monitorar a disponibilidade de dados para os usuários de uma maneira compatível com incentivos.

Avanços adicionais na amostragem de disponibilidade de dados

O nosso objetivo é alcançar uma largura de banda de disponibilidade de dados de 16 MB por slot, combinando melhorias na compressão de dados da Rollup, o que trará cerca de 58000 TPS.

PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de 4096 graus sobre um 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 de um total de 8192 coordenadas. Qualquer conjunto de 4096 valores de avaliação pode recuperar o blob.

O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes e solicite blobs de outras sub-redes que necessita, perguntando a pares na rede p2p global. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível de pares.

Teoricamente, podemos escalar o "1D sampling" para um tamanho bastante grande, mas isso impediria os clientes com largura de banda limitada de amostrar. Portanto, queremos avançar ainda mais e realizar a amostragem 2D, que não apenas realiza amostragem aleatória dentro do blob, mas também entre os blobs.

A próxima etapa é a implementação e lançamento do PeerDAS. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Também precisamos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança.

Compressão de Dados

Atualmente, cada transação Rollup ocupa uma grande quantidade de espaço de dados na cadeia. Precisamos fazer com que cada transação dentro do Rollup ocupe menos bytes na cadeia.

Os métodos de compressão de dados incluem:

1. Compressão de zero bytes
2. Agregação de Assinaturas
3. Substituir endereços por ponteiros
4. Serialização personalizada do valor da transação
5. Publicar diferenças de estado em vez de transações

Adotar o ERC-4337 e, finalmente, incorporar parte do seu conteúdo no L2 EVM pode acelerar significativamente a implementação da tecnologia de agregação.

Plasma Generalizado

Plasma é uma solução de escalabilidade que envolve um operador publicando blocos fora da cadeia e colocando a raiz Merkle desses blocos na cadeia. As versões iniciais do Plasma só podiam lidar com casos de pagamento, sem conseguir expandir efetivamente.

Se exigirmos que cada raiz seja verificada com SNARK, então o Plasma se tornará muito mais poderoso. Cada jogo de desafio pode ser significativamente simplificado, uma vez que eliminamos a maior parte das possíveis rotas de fraude dos operadores. Ao mesmo tempo, isso também abre novos caminhos, permitindo que a tecnologia Plasma se expanda para uma gama mais ampla de categorias de ativos.

O sistema Plasma não precisa ser perfeito. Mesmo que você só consiga proteger um subconjunto de ativos, você já melhorou significativamente a situação atual do EVM super escalável.

Sistema de prova L2 maduro

Atualmente, a maioria dos Rollups ainda não é realmente sem confiança. Existe um comitê de segurança que tem a capacidade de sobrepor o comportamento do sistema de prova. Precisamos de Rollups sem confiança, por isso devemos enfrentar e resolver este problema.

O principal desafio para alcançar Rollup sem confiança é obter confiança suficiente de que o sistema de prova é realmente confiável o suficiente. Existem duas principais maneiras de fazer isso:

1. Verificação formal: usar matemática moderna e técnicas computacionais para provar que o sistema de prova só aceita blocos que seguem a especificação do EVM.

2. Múltiplas provas: criar vários sistemas de prova e investir fundos nesses sistemas de prova e no comitê de segurança. Se o sistema de prova concordar, o comitê de segurança não tem poder; se eles não concordarem, o comitê de segurança só pode escolher entre um deles.

Melhorias na Interoperabilidade entre L2

Precisamos fazer com que a experiência de usar um ecossistema L2 se sinta como usar um ecossistema Ethereum unificado. As melhorias na interoperabilidade entre L2 incluem:

1. Endereço de uma cadeia específica
2. Pedido de pagamento da cadeia específica
3. Troca entre cadeias e pagamento de Gas
4. Cliente leve
5. Carteira Keystore
6. Ponte de tokens compartilhados
7. Sincronização Combinatória

A maioria das propostas são estruturas de "nível superior", portanto, as considerações sobre o nível L1 não têm grande impacto. Uma exceção é a ordenação compartilhada, que tem um impacto significativo no valor máximo extraível (MEV).

Escalando a execução na L1

Se o L2 se tornar muito escalável e bem-sucedido, mas o L1 ainda só puder lidar com uma quantidade muito reduzida de volume de transações, então o Ethereum pode enfrentar alguns riscos. Portanto, continuar a expandir o L1 em si e garantir que ele possa continuar a acomodar um número crescente de casos de uso é muito valioso.

As estratégias de expansão L1 incluem:

1. Melhorar a tecnologia para tornar o L1 mais fácil de verificar e, em seguida, aumentar o limite de Gas.
2. Reduzir o custo de operações específicas, aumentando a capacidade média sem aumentar o risco do pior caso.
3. Rollups nativos: criar N cópias paralelas do EVM.

Uma questão importante que qualquer roteiro de escalabilidade L1 deve responder é: qual é a visão final para L1 e L2? Precisamos de alguns princípios orientadores para garantir que a descentralização do Ethereum L1 não seja seriamente comprometida.

Trazer mais usuários para o L1 não significa apenas aumentar a escalabilidade, mas também melhorar outros aspectos do L1. Isso significa que mais MEV ficará no L1, portanto, a necessidade de lidar com MEV de forma clara se tornará mais urgente. Isso aumentará significativamente o valor do tempo de slot rápido no L1. Ao mesmo tempo, isso também depende muito do bom funcionamento da validação do L1.