Ethereum possível futuro: The Surge

O roteiro do Ethereum originalmente incluía duas estratégias de escalabilidade: fragmentação e protocolos Layer2. Esses dois caminhos acabaram se fundindo, formando um roteiro centrado em Rollup, que continua a ser a estratégia de expansão atual do Ethereum.

O roteiro centrado em Rollup propõe uma divisão simples de tarefas: Ethereum L1 foca em se tornar uma camada base poderosa e descentralizada, enquanto L2 assume a tarefa de ajudar a expandir o ecossistema. Este modelo é comum na sociedade: a existência do sistema judicial (L1) é para proteger contratos e propriedade, enquanto os empreendedores (L2) constroem sobre essa base, impulsionando o desenvolvimento.

Este ano, o roteiro centrado no Rollup alcançou progressos 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 Máquina Virtual Ethereum entraram na primeira fase. Cada L2 existe como um "fragmento" com suas próprias regras e lógica, e a diversidade e pluralidade das formas de implementação dos fragmentos tornaram-se uma realidade. Mas este caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar o roteiro centrado no Rollup, resolver esses problemas, enquanto mantemos a robustez e a descentralização do Ethereum L1.

A Ascensão: Objetivos-chave

1. O Ethereum no futuro pode atingir mais de 100.000 TPS através do L2;

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

3. Pelo menos algumas L2 herdam completamente as propriedades centrais do Ethereum (, como a confiança, a abertura e a resistência à censura );

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

Conteúdo deste capítulo

1. O 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 da Tríade da Escalabilidade

O paradoxo do triângulo da escalabilidade argumenta que existe uma contradição entre três características da blockchain: descentralização, custo baixo para nodes de operação (, escalabilidade ) com um grande número de transações processadas ( e segurança ), onde um atacante precisaria comprometer uma grande parte dos nodes na rede para fazer uma única transação falhar (.

Vale a pena notar que a paradoxo triangular não é um teorema, e as postagens que introduzem o paradoxo triangular também não incluem uma prova matemática. Ele fornece um argumento matemático heurístico: se um nó amigável à descentralização 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 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; em vez disso, ele visa mostrar que quebrar o paradoxo ternário é difícil e que requer, de certa forma, sair da estrutura de pensamento implícita por esse argumento.

Durante anos, algumas cadeias de alto desempenho afirmaram que resolveram o paradoxo trino sem alterar fundamentalmente a arquitetura, geralmente otimizando os nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois executar nós nessas cadeias é muito mais difícil do que executar nós em Ethereum.

No entanto, a combinação de 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 passos de cálculo foi executada corretamente, enquanto baixam apenas uma pequena quantidade de dados e realizam muito poucos cálculos. Os SNARKs são sem confiança. A amostragem de disponibilidade de dados tem um modelo de confiança sutil de few-of-N, mas mantém as características básicas que uma cadeia não escalável possui, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceites pela rede.

Uma outra forma de resolver o dilema das três questões é a arquitetura Plasma, que utiliza 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 tinha limitações significativas em termos de execução segura, mas com a popularização dos SNARKs, a arquitetura Plasma tornou-se mais viável para uma gama de cenários de uso mais ampla do que nunca.

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

Avanços adicionais na amostragem de disponibilidade de dados

) Que problema estamos resolvendo?

No dia 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 uma largura de banda de dados disponível de cerca de 375 kB por slot. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o TPS máximo para Rollups na Ethereum é: 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 / cada 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, que, se combinado com melhorias na compressão de dados Rollup, resultará em ~58000 TPS.

) O que é isso? Como funciona?

PeerDAS é uma implementação relativamente simples de "1D sampling". No Ethereum, cada blob é um polinômio de grau 4096 sobre um campo primo de 253 bits. Nós transmitimos as shares do polinômio, onde cada share 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 de ### de acordo com os parâmetros propostos atualmente: qualquer 64 de 128 possíveis amostras de ( 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 irá escutar diferentes sub-redes ( para obter os blobs de que precisa em outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é que os nós que participam do proof of stake utilizem o SubnetDAS, enquanto outros nós ), ou seja, clientes (, utilizem o PeerDAS.

Teoricamente, podemos escalar uma "amostragem 1D" bastante grande: se aumentarmos o número máximo de blobs para 256) com um objetivo de 128(, conseguiremos atingir a meta de 16MB, enquanto na amostragem de disponibilidade de dados, 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 do nosso limite de tolerância: é viável, mas 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 aumentará o custo de reconstrução.

Portanto, queremos avançar ainda mais e realizar amostragem 2D, um método que não só amostra aleatoriamente dentro do blob, mas também entre os blobs. Utilizando a propriedade linear dos compromissos KZG, ampliamos o conjunto de blobs em um bloco através de um novo conjunto de 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 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 para a mesma informação.

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

![Vitalik novo artigo: O futuro possível do Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.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. Depois, aumentar continuamente o número de blobs no PeerDAS, enquanto observamos atentamente a rede e melhoramos o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalho acadêmico para regulamentar 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 eventualmente conseguir transitar do KZG para uma alternativa que seja segura quânticamente e que não exija configuração de confiança. Neste momento, ainda não está claro quais candidatos são amigáveis à construção de blocos distribuídos. Mesmo usando tecnologia "bruta" cara, ou seja, usando STARKs recursivos 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 do mesmo tamanho que todo o blob.

O caminho real 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 arquitetura Layer2 de 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 processar uma grande quantidade de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão ter 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 as outras partes do roteiro?

Se a compressão de dados for realizada, a demanda por 2D DAS será reduzida, ou pelo menos 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 teoricamente seja amigável para a 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 fork ao seu redor.

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

Compressão de Dados

) Que problema estamos a resolver?

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

16000000 / 12 / 180 = 7407 TPS

E se pudéssemos resolver não apenas os problemas dos numeradores, mas também os problemas dos denominadores, fazendo com que cada transação em um Rollup ocupe menos bytes na cadeia?

O que é isso e como funciona?

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

![Vitalik nova peça: O futuro possível do Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(

Na compressão de zeros, substituímos 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: 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. Na camada L1, devido ao alto custo computacional de verificação mesmo com a agregação, não se considera o uso de assinaturas BLS. Mas em um ambiente como L2, onde os dados são escassos, o uso de assinaturas BLS faz sentido. A característica de agregação do ERC-4337 oferece um caminho para implementar essa funcionalidade.

Usar po