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. Essas duas abordagens acabaram se fundindo, formando um roteiro centrado em Rollup, que ainda é a estratégia de escalonamento 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 escalar o ecossistema.

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 da Máquina Virtual Ethereum (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 variedade na implementação das partições tornaram-se uma realidade. Mas, como vimos, seguir esse caminho também apresenta alguns desafios únicos. Portanto, nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, mantendo, ao mesmo tempo, a robustez e a descentralização que são características do Ethereum L1.

The Surge: Objetivos-chave

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

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

3. Pelo menos alguns 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.

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

Este capítulo

1. Paradoxo do triângulo de 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 na L1

Paradoxo da Tríade da Escalabilidade

O paradoxo do triângulo da escalabilidade é uma ideia proposta em 2017, que sugere que existe uma contradição entre três características da blockchain: descentralização ) mais especificamente: baixo custo de execução dos nós (, escalabilidade ) quantidade elevada de transações processadas ( 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 uma prova matemática. 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 só pode ser vista por 1/k nós, o que significa que um atacante só precisaria comprometer alguns nós para realizar uma transação maliciosa, ou )ii( seus nós se tornariam poderosos, enquanto sua cadeia não se descentralizaria. O objetivo deste artigo nunca foi provar que quebrar a paradoxo triangular é impossível; em vez disso, visa mostrar que quebrar a paradoxo ternário é difícil e que requer, de certa forma, sair da estrutura de pensamento implícita nesse argumento.

Ao longo dos anos, algumas cadeias de alto desempenho afirmam frequentemente que resolveram o trilema sem mudar fundamentalmente a arquitetura, muitas vezes otimizando nós através de técnicas de engenharia de software. Isso é sempre enganoso, pois operar nós nessas cadeias é muito mais difícil do que operar 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 é suficiente para 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 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 reduzido de cálculos. 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 de uma cadeia que não pode ser escalada, ou seja, mesmo um ataque de 51% não pode forçar blocos ruins a serem aceitos pela rede.

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

Outra abordagem para resolver o dilema dos três lados é 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) e das provas de conhecimento zero concisas e não interativas(, a arquitetura Plasma tornou-se mais viável para uma gama mais ampla de cenários de uso do que nunca.

Avanços adicionais na amostragem de disponibilidade de dados

) Estamos resolvendo que problema?

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 12 segundos, ou seja, uma largura de banda de dados disponível de aproximadamente 375 kB por slot. Supondo que os dados das transações sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o TPS máximo do Rollup na Ethereum é: 375000 / 12 / 180 = 173,6 TPS.

Se adicionarmos o valor máximo teórico da 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 PeerDAS, o número de blobs pode aumentar para 8-16, o que proporcionará 463-926 TPS para a calldata.

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

) O que é? 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. Desses 8192 valores de avaliação, qualquer 4096 (, de acordo com os parâmetros propostos atualmente: qualquer 64 entre 128 amostras possíveis ) podem recuperar o blob.

O funcionamento do PeerDAS é permitir que cada cliente escute uma pequena quantidade de sub-redes, onde a i-ésima sub-rede transmite o i-ésimo exemplo de qualquer blob e solicita aos pares na rede p2p global ( quem irá escutar diferentes sub-redes ) para obter os blobs necessários em outras sub-redes. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais na camada de pares. A proposta atual é que os nós que participam da prova de participação 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 uma meta de 128), então podemos alcançar a meta de 16MB, enquanto a amostragem de disponibilidade de dados tem 16 amostras * 128 blobs * 512 bytes por amostra de cada blob = 1 MB de largura de banda de dados por slot. Isso está apenas dentro do nosso limite 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 finalmente ir mais longe, realizando a amostragem 2D (2D sampling), este método não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Utilizando a propriedade linear do compromisso KZG, expandimos o conjunto de blobs em um bloco através de um conjunto de novos blobs virtuais, que codificam redundantemente a mesma informação.

Portanto, no final, queremos ir mais longe e realizar amostragem 2D, que não só ocorre dentro do blob, mas também entre os blobs de forma aleatória. 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 codificados de forma redundante com as mesmas informações.

É crucial que a expansão do compromisso de cálculo não necessite de blob, portanto, esta 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 blob, e podem confiar na amostragem de disponibilidade de dados (DAS) para verificar 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 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 se observa cuidadosamente a rede e se melhora o software para garantir a segurança, é um processo gradual. Ao mesmo tempo, esperamos ter mais trabalhos acadêmicos para regular 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, precisaremos fazer mais trabalho para determinar a versão ideal do 2D DAS e provar suas propriedades de segurança. Também esperamos poder finalmente transitar de KZG para uma alternativa que seja segura contra quânticos e que não exija configurações confiáveis. Atualmente, ainda não está claro quais opções candidatas são amigáveis para a construção de blocos distribuídos. Mesmo usando a cara técnica de "força bruta", ou seja, utilizando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso não é suficiente para atender à demanda, uma vez que, embora tecnicamente, um STARK tenha tamanho O)log(n) * log###log(n() hash ( utilizando STIR(, na prática, o STARK é quase do tamanho de todo o blob.

Eu acho que o caminho de realidade a longo prazo é:

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. Desistir do DA e aceitar completamente o Plasma como nossa principal arquitetura Layer2 de foco.

Por favor, note que, mesmo que decidamos expandir a execução diretamente na camada L1, essa opção existe. Isso ocorre 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 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 implementada, a demanda por 2D DAS diminuirá, ou pelo menos será atrasada; 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 seus mecanismos de escolha de forks.

Compressão de Dados

) Que problema estamos a resolver?

Cada transação em Rollup ocupa uma grande quantidade de espaço de dados na cadeia: uma transferência ERC20 requer aproximadamente 180 bytes. Mesmo com uma 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 pudéssemos resolver não apenas o problema do numerador, mas também o problema do denominador, fazendo com que cada transação dentro de um Rollup ocupe menos bytes na cadeia?

O que é isso, como funciona?

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

A compressão de zero bytes está em andamento, substituindo cada sequência longa de bytes zero por dois bytes, indicando quantos bytes zero 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, e essa assinatura pode provar a validade de todas as assinaturas originais. No nível 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 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