Ethereum可能的未来：The Surge

O roteiro do Ethereum inicialmente incluía duas estratégias de escalabilidade: sharding e protocolos Layer 2. Com a pesquisa em profundidade, esses dois caminhos se fundiram, formando um roteiro centrado em Rollups, que ainda é a estratégia de escalabilidade atual do Ethereum.

O roteiro centrado em Rollup propõe uma divisão simples de trabalho: o L1 do Ethereum se concentra em ser 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) 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 sólida camada base, promovendo 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 da Máquina Virtual Ethereum (EVM) entraram na primeira fase. Cada L2 existe como um "shard" com suas próprias regras e lógica internas, e a diversidade e variedade na implementação de shards tornou-se uma realidade. Mas este caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar o roteiro centrado em Rollup e resolver esses problemas, enquanto mantemos 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 ( de confiança, abertura e resistência à censura );
4. Ethereum deve sentir-se como um ecossistema unificado, em vez de 34 blockchains diferentes.

Conteúdo do artigo

1. Paradoxo triangular 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 na L1

Paradoxo da Tríade da Escalabilidade

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

O paradoxo do triângulo não é um teorema, mas apresenta 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 destruir alguns nós para realizar uma transação maliciosa, ou (ii) seus nós se tornarão poderosos, enquanto sua cadeia não será descentralizada.

Durante anos, algumas cadeias de alto desempenho afirmam resolver o paradoxo triádico 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 na 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 passos de computação foi executada corretamente, fazendo apenas o download de uma pequena quantidade de dados e executando uma quantidade mínima de cálculos. Os SNARKs são sem necessidade de confiança. A amostragem de disponibilidade de dados possui um modelo de confiança sutil do tipo 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.

Uma outra forma de resolver o dilema de três dificuldades é 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. Já em 2017-2019, quando tínhamos apenas a prova de fraude como meio para expandir a capacidade computacional, o Plasma tinha limitações significativas na execução segura, mas com a popularização dos SNARKs(, provas não interativas de conhecimento zero concisas), a arquitetura Plasma se tornou 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

Estamos a resolver que problema?

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 seja, uma largura de banda de dados disponível por slot de aproximadamente 375 kB. Supondo que os dados da transação sejam publicados diretamente na cadeia, uma transferência ERC20 tem cerca de 180 bytes, portanto, o máximo de TPS para 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 / cada 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á à calldata 463-926 TPS.

Esta é uma melhoria significativa para o Ethereum L1, mas não é suficiente. Queremos mais escalabilidade. O nosso objetivo a médio prazo é 16 MB por slot, o que, 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 4096 graus no campo primo (. 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 ) pode ser recuperado de acordo com os parâmetros propostos atualmente: qualquer 64 entre 128 possíveis amostras (.

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 aos pares na rede p2p global ) quem irá escutar diferentes sub-redes ( para pedir os blobs de que precisa em outras sub-redes. A versão mais conservadora, SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais ao nível de pares. A proposta atual é que os nós que participam da prova de participação utilizem o SubnetDAS, enquanto os outros nós ), ou clientes (, utilizem o PeerDAS.

Em teoria, podemos escalar uma "amostragem 1D" para um tamanho considerável: se aumentarmos o número máximo de blobs para 256) com um alvo de 128(, conseguiremos atingir a meta de 16MB, onde a amostragem de disponibilidade de dados para cada nó é de 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 isso significa que clientes com largura de banda limitada não conseguem amostrar. Podemos otimizar isso em certa medida reduzindo o número de blobs e aumentando o tamanho dos blobs, mas isso aumentará o custo de reconstrução.

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

É crucial que a expansão da promessa 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 só precisam ter a promessa KZG de blobs, 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( também é essencialmente 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, ao mesmo tempo que 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 regulamentar o PeerDAS e outras versões do DAS e sua interação com questões de segurança, como as regras de escolha de fork.

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 ser capazes de passar do KZG para uma alternativa que seja segura contra quântica e não exija configuração de confiança. Atualmente, não está claro quais candidatos são amigáveis para a construção de blocos distribuídos. Mesmo usando a cara técnica de "força bruta", ou seja, usando STARK recursivo para gerar provas de validade para reconstruir linhas e colunas, isso 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 tamanho de todo o blob.

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

1. Implementar o ideal DAS 2D;
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 interesse.

Por favor, note que, mesmo que decidamos expandir a execução diretamente na camada L1, essa opção existe. Isso se deve ao fato de que, 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 ter um método eficiente para 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 diminuirá, ou pelo menos será atrasada; se o Plasma for amplamente utilizado, a demanda diminuirá ainda mais. O DAS também apresenta desafios para protocolos e mecanismos de construção de blocos distribuídos: embora o DAS teoricamente seja 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 fork ao redor.

Compressão de Dados

Que problema estamos a resolver?

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

16000000 / 12 / 180 = 7407 TPS

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

( O que é, como funciona?

Na compressão de zero bytes, usamos dois bytes para substituir cada sequência longa de zero bytes, representando quantos zero bytes existem. Além disso, aproveitamos as propriedades específicas das transações:

Agregação de assinaturas: Mudamos de assinaturas ECDSA para assinaturas BLS. A característica das assinaturas BLS é que várias assinaturas podem ser combinadas em uma única assinatura, essa assinatura pode provar a validade de todas as assinaturas originais. No nível L1, devido ao alto custo computacional da 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 é significativo. A característica de agregação do ERC-4337 oferece um caminho para implementar essa funcionalidade.

Substituir endereços por pointers: Se já utilizou um determinado endereço, podemos substituir o endereço de 20 bytes por um pointer de 4 bytes que aponta para uma localização no histórico.

Serialização personalizada de valores de transação------A maioria dos valores de transação tem poucos dígitos, por exemplo, 0,25 Éter é representado como 250.000.000.000.000.000 wei. A taxa básica máxima e a taxa prioritária também são semelhantes. Portanto, podemos usar um formato decimal flutuante personalizado para representar a maioria dos valores monetários.

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

A próxima etapa é implementar efetivamente o plano mencionado acima. Os principais trade-offs incluem:

1. Mudar para a assinatura BLS requer um grande esforço e vai reduzir a capacidade de melhorar a segurança.