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. Esses dois caminhos 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 L1 do Ethereum se concentra em se tornar uma camada base forte e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Esse modelo é onipresente na sociedade: a existência do sistema judicial (L1) é 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 significativos: com o lançamento dos blobs EIP-4844, a largura de banda de dados do Ethereum L1 aumentou consideravelmente, e vários Rollups da Ethereum Virtual Machine ( EVM ) entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógica internas, e a diversidade e pluralidade na implementação de fragmentos tornaram-se uma realidade. Mas, como podemos ver, seguir este caminho enfrenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, enquanto mantemos a robustez e a descentralização características do Ethereum L1.

The Surge: Objetivo-chave

1. O futuro do Ethereum através do L2 pode alcançar mais de 100.000 TPS;

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

3. Pelo menos alguns L2 herdam completamente as propriedades centrais do Ethereum ( de confiança, abertura e resistência à 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. Melhorias na interoperabilidade entre L2
7. Expandir a execução no L1

paradoxo do triângulo de escalabilidade

O triângulo 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: o baixo custo para operar nós ), escalabilidade (, que lida com um grande número de transações ), e segurança (, onde um atacante precisaria comprometer uma grande parte dos nós na rede para falhar uma única transação ).

É importante notar que a paradoxo triangular não é um teorema, e os posts que introduzem o paradoxo triangular não incluem provas matemáticas. Ele realmente fornece um argumento matemático heurístico: se um nó amigável à descentralização (, 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 pode ser vista por apenas 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 será descentralizada. O objetivo deste artigo nunca foi provar que quebrar o paradoxo triangular é 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 nessa argumentação.

Ao longo dos anos, algumas cadeias de alto desempenho frequentemente afirmam que resolveram o triângulo da impossibilidade sem mudar fundamentalmente a arquitetura, geralmente utilizando 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 explorará por que isso ocorre e por que a engenharia de software do cliente L1 por si só não pode escalar o Ethereum.

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

Uma outra maneira de resolver o dilema das três dificuldades é a arquitetura Plasma, que usa uma tecnologia engenhosa para transferir a responsabilidade pela disponibilidade dos dados de monitoramento para os usuários de uma maneira compatível com incentivos. Já em 2017-2019, quando só tínhamos 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( e das provas não interativas de conhecimento zero concisas), a arquitetura Plasma tornou-se mais viável para um leque de cenários de uso mais amplo 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 em cada slot de 12 segundos, ou seja, uma largura de banda de dados disponível por slot de cerca de 375 kB. Supõe-se que os dados das transações sejam publicados diretamente na cadeia, portanto, uma transferência ERC20 tem cerca de 180 bytes, assim, o máximo de TPS para Rollup em Ethereum é: 375000 / 12 / 180 = 173,6 TPS.

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

Esta é uma grande melhoria para o Ethereum L1, mas ainda não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é de 16 MB por slot, o que, em combinação com melhorias na compressão de dados Rollup, 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 sobre o 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. Desses 8192 valores de avaliação, qualquer 4096 ) pode ser recuperado com base nos parâmetros atualmente propostos: qualquer 64 entre 128 amostras possíveis ( podem recuperar o blob.

O funcionamento do PeerDAS é permitir que cada cliente escute um pequeno número de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob, e solicita a outros pares na rede p2p global ) quem escutará diferentes sub-redes ( para pedir os blobs que precisa de outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem perguntas adicionais à camada de pares. A proposta atual é que os nós que participam na prova de participação utilizem o SubnetDAS, enquanto os outros nós ), ou seja, os clientes (, utilizem o PeerDAS.

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

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

Portanto, no final, queremos ir mais longe e realizar amostragem 2D, que não só acontece dentro do blob, mas também entre os blobs de forma aleatória. A propriedade linear do compromisso KZG é usada para expandir um conjunto de blobs dentro de um bloco, que contém uma nova lista de blobs virtuais com codificação redundante para as mesmas informações.

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

![Vitalik nova publicação: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(

)# O que mais precisa ser feito? Quais são as compensações?

A próxima etapa é a implementação e lançamento do PeerDAS. Em seguida, aumentar constantemente o número de blobs no PeerDAS, enquanto observamos cuidadosamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalhos acadêmicos 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 forks.

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

O caminho de 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 de dados mais baixo em prol da simplicidade e robustez.
3. Abandonar o DA e aceitar completamente o Plasma como a nossa principal estrutura Layer 2 de interesse.

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

)# Como interagir com as outras partes do roteiro?

Se a compressão de dados for realizada, 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 de lista de inclusão de pacotes e os mecanismos de escolha de forks ao seu 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 uma amostragem ideal de disponibilidade de dados, isso limita a escalabilidade dos protocolos Layer. Cada slot tem 16 MB, obtemos:

16000000 / 12 / 180 = 7407 TPS

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

O que é e como funciona?

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

Na compressão de zero bytes, cada sequência longa de zero bytes é substituída por dois bytes, indicando quantos zero bytes existem. Além disso, aproveitamos propriedades específicas das transações:

Agregação de assinaturas: Nós mudamos de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, que pode provar a validade de todas as assinaturas originais. No nível L1, devido ao alto custo computacional de verificação mesmo com agregação, não se considera o uso de assinaturas BLS. Mas em um ambiente L2 com escassez de dados, o uso de assinaturas BLS faz sentido. A característica de agregação do ERC-4337 fornece um caminho para implementar essa funcionalidade.

Substituir endereços por pointers: se é