O futuro potencial do Ethereum: The Surge

O roteiro do Ethereum tinha inicialmente duas estratégias de escalabilidade: sharding e protocolos Layer 2. À medida que a pesquisa avançava, esses dois caminhos se fundiram, 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 simples de funções: o Ethereum L1 se concentra em se tornar uma camada de base forte e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema. Este modelo é comum na sociedade: a existência do sistema judicial (L1) não é para buscar eficiência, mas para proteger contratos e direitos de propriedade, enquanto os empreendedores (L2) constroem sobre essa base sólida, impulsionando o desenvolvimento humano.

Este ano, o roteiro centrado em Rollup fez progressos significativos: o lançamento dos blobs EIP-4844 aumentou drasticamente a largura de banda de dados do Ethereum L1, e múltiplos EVM Rollup entraram na primeira fase. Cada L2 existe como uma "partição" com suas próprias regras e lógica, e a diversidade de implementações de partições tornou-se uma realidade. Mas este caminho também enfrenta alguns desafios únicos. Nossa tarefa agora é completar o roteiro centrado em Rollup, resolver esses problemas, enquanto mantemos a robustez e a descentralização características do Ethereum L1.

The Surge: Objetivos-chave

1. O Ethereum no futuro poderá alcançar mais de 100 mil 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 ( de confiança, abertura e resistência à censura );
4. Ethereum deve parecer um ecossistema unificado, e não 34 blockchains diferentes.

Paradoxo da Tríade da Escalabilidade

O paradoxo da triangularidade da escalabilidade afirma que há uma contradição entre as três características da descentralização, escalabilidade e segurança do blockchain. Não se trata de um teorema, mas sim de uma perspectiva heurística. Ao longo dos anos, algumas cadeias de alto desempenho afirmaram ter resolvido o paradoxo ternário, mas isso geralmente é enganoso.

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, baixando apenas uma pequena quantidade de dados e executando uma quantidade mínima de cálculos.

Outra abordagem para resolver o dilema dos três é a arquitetura Plasma, que coloca a responsabilidade pela disponibilidade dos dados de monitorização nas mãos dos utilizadores de uma forma compatível com incentivos. Com a popularização dos SNARKs, a arquitetura Plasma torna-se mais viável para uma gama mais ampla de cenários de uso.

Avanços adicionais na amostragem de disponibilidade de dados

Estamos a resolver que problema?

Após a atualização Dencun em 13 de março de 2024, o Ethereum terá 3 blobs de cerca de 125 kB a cada 12 segundos por slot, ou uma largura de banda de dados disponível de cerca de 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 máximo de TPS do Rollup no Ethereum é de 173,6 TPS.

Com a calldata do Ethereum, 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 a calldata.

Esta é uma grande melhoria para o Ethereum L1, mas ainda não é suficiente. O nosso objetivo a médio prazo é de 16 MB por slot, o que, combinado 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 grau 4096 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 em 16 coordenadas adjacentes de um total de 8192 coordenadas. Dentre esses 8192 valores de avaliação, qualquer 4096 podem ser usados para 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 os blobs de outras sub-redes que necessita, perguntando a pares na rede p2p global. Uma versão mais conservadora, o SubnetDAS, utiliza apenas o mecanismo de sub-rede, sem consultas adicionais à camada de pares. A proposta atual é permitir que os nós que participam da prova de participação utilizem o SubnetDAS, enquanto os outros nós utilizem o PeerDAS.

Teoricamente, podemos escalar o "1D sampling" a um tamanho considerável: se aumentarmos o número máximo de blobs para 256, conseguiremos atingir a meta de 16MB, enquanto cada nó em cada slot de amostragem de disponibilidade de dados precisa apenas de 1 MB de largura de banda de dados. 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 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 amostragem 2D, que não apenas amostra aleatoriamente dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expandimos o conjunto de blobs em um bloco por meio de um novo conjunto de blobs virtuais, que codificam redundantemente as mesmas informações.

É crucial que a expansão do compromisso de cálculo não precise de blob, portanto, essa abordagem é fundamentalmente amigável à construção de blocos distribuídos. Os nós que realmente constroem os blocos só precisam possuir o compromisso KZG do 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 concessões?

A seguir está 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. Ao mesmo tempo, esperamos ter mais trabalhos acadêmicos para padronizar o PeerDAS e outras versões do DAS, bem como a interação destes com questões de segurança relacionadas às regras de escolha 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 conseguir passar do KZG para uma alternativa que seja segura contra quânticos e que não exija configurações confiáveis. Neste momento, ainda não está claro quais opções candidatas são amigas da construção de blocos distribuídos.

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 arquitetura Layer2 de interesse.

Por favor, note que, mesmo que decidamos expandir a execução diretamente na camada L1, essa escolha ainda existe. Isso porque, se a camada L1 tiver que lidar com um grande número de TPS, os blocos L1 se tornarão muito grandes, e os clientes desejarão uma forma eficiente de validar 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 necessidade de DAS 2D diminuirá, ou pelo menos será adiada; se o Plasma for amplamente utilizado, a necessidade 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 à reconstrução distribuída, na prática isso precisa ser combinado com a proposta da lista de inclusão de pacotes e seu mecanismo de escolha de bifurcações associado.

Compressão de Dados

Que problema estamos a resolver?

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

16000000 / 12 / 180 = 7407 TPS

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

O que é, como funciona?

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

Agregação de assinaturas: estamos mudando 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 validaçã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, faz sentido usar assinaturas BLS. A característica de agregação do ERC-4337 fornece um caminho para implementar essa funcionalidade.

Substitua o endereço por ponteiros: Se já usou um determinado endereço, podemos substituir o endereço de 20 bytes por um ponteiro de 4 bytes que aponta para uma posição em um 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. As taxas básicas máximas e as taxas prioritárias também são semelhantes. Portanto, podemos usar um formato de ponto flutuante decimal personalizado para representar a maioria dos valores monetários.

O que mais precisa ser feito, quais são as concessões?

A próxima etapa é implementar efetivamente o plano acima. As principais considerações incluem:

1. Mudar para a assinatura BLS requer um grande esforço e diminuirá a compatibilidade com chips de hardware confiáveis que podem aumentar a segurança. Pode-se usar o encapsulamento ZK-SNARK de outros esquemas de assinatura como alternativa.

2. Compressão dinâmica ( Por exemplo, substituir endereços ) por ponteiros tornará o código do cliente mais complexo.

3. Publicar as diferenças de estado na cadeia em vez de transações reduzirá a auditabilidade e fará com que muitos softwares (, como exploradores de blocos ), não funcionem.

Como interagir com outras partes do roteiro?

A adoção do ERC-4337 e a eventual incorporação de parte do seu conteúdo no EVM L2 podem acelerar significativamente a implementação da tecnologia de agregação. Colocar parte do conteúdo do ERC-4337 na L1 pode acelerar sua implementação na L2.

Plasma Generalizado

Estamos a resolver que problema?

Mesmo com blobs de 16 MB e compressão de dados, 58.000 TPS pode não ser suficiente para atender completamente às necessidades de pagamentos de consumidores, redes sociais descentralizadas ou outros campos de alta largura de banda, especialmente quando começamos a considerar fatores de privacidade, o que pode reduzir a escalabilidade em 3 a 8 vezes. Para cenários de aplicação de alto volume de transações e baixo valor, atualmente