Análise da atualização técnica do Ethereum The Surge

Desde outubro deste ano, o cofundador do Ethereum publicou uma série de artigos sobre as possíveis futuras do protocolo Ethereum, abrangendo seis partes do roteiro de desenvolvimento do Ethereum. Este artigo irá interpretar a segunda parte dessa série, The Surge, focando na escalabilidade e no desenvolvimento a longo prazo do Ethereum. A partir do roteiro técnico desta fase, podemos entender profundamente como o Ethereum irá se transformar em um protocolo capaz de lidar com uma enorme demanda (TPS chegando a 100.000+), enquanto mantém a descentralização e a segurança.

Visão central do Ethereum

Em essência, o Ethereum visa ser a camada base da internet descentralizada. O Éter suporta aplicações descentralizadas complexas através de códigos de contratos inteligentes autoexecutáveis, e essa flexibilidade torna-o a blockchain preferida dos desenvolvedores para construir aplicações descentralizadas, incluindo DeFi, NFTs e outras.

No entanto, o Ethereum tem limitações em termos de escalabilidade. O Ethereum L1 só consegue processar cerca de 15 a 30 transações por segundo, o que representa uma grande diferença em relação às redes de pagamento tradicionais. Isso resulta em taxas de gás elevadas durante períodos de congestionamento da rede e limita a capacidade do Ethereum de se tornar uma infraestrutura de escala global. Este é precisamente o problema que o The Surge visa resolver.

Os principais objetivos do Surge são os seguintes:

• Ethereum L1+L2 alcança 100.000+ TPS;
• Manter a descentralização e robustez do L1;
• Pelo menos algumas L2 herdam completamente as propriedades centrais do Ethereum (sem necessidade de confiança, abertas, resistentes à censura);
• Maximizar a interoperabilidade entre L2: Ethereum deve funcionar como um ecossistema, e não como várias blockchains diferentes.

Futuro centrado no rollup

A Surge refere-se ao plano do Ethereum para aumentar significativamente a escalabilidade, principalmente através de soluções L2. O rollup é uma parte fundamental desta estratégia. O roteiro centrado em rollup propõe uma divisão de trabalho simples: o Ethereum L1 foca em se tornar uma camada base robusta e descentralizada, enquanto o L2 assume a tarefa de ajudar a expandir o ecossistema.

Rollup agrupa transações fora da cadeia e, em seguida, as submete de volta à rede principal do Ethereum, aumentando significativamente a taxa de transferência enquanto mantém a segurança e a descentralização. O rollup pode aumentar a escalabilidade do Ethereum para mais de 100.000 TPS. Isso será uma expansão transformadora, pois permite que o Ethereum processe aplicativos em escala global sem comprometer o espírito de descentralização.

O roadmap centrado em rollup é visto como uma solução de escalabilidade de longo prazo. O Ethereum 2.0 diminuiu o consumo de energia ao fazer a transição de PoW para PoS através do The Merge, enquanto o rollup é considerado o próximo marco importante como solução de escalabilidade de longo prazo.

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 da Ethereum L1 aumentou significativamente, e vários rollups da Máquina Virtual Ethereum (EVM) entraram na primeira fase. Cada L2 existe como um fragmento com suas próprias regras e lógicas internas, e a diversidade e pluralidade na implementação de fragmentos tornaram-se uma realidade.

Amostragem de Disponibilidade de Dados (DAS)desenvolvimento adicional

Outro aspecto crucial do Surge é a amostragem de disponibilidade de dados (DAS), uma técnica destinada a resolver problemas de disponibilidade de dados. Em redes descentralizadas como Ethereum, é fundamental que todos os nós possam validar dados sem a necessidade de armazenar ou descarregar todo o conteúdo.

DAS permite que os nós verifiquem dados sem acessar o conjunto de dados completo, melhorando assim a escalabilidade e a eficiência.

Existem duas formas de DAS: PeerDAS e 2D DAS. O PeerDAS promete melhorar as suposições de confiança no rollup, tornando-o mais seguro. O 2D DAS não só realiza amostragem aleatória dentro do blob, mas também entre os blobs. Aproveitando as propriedades lineares do compromisso KZG, expande-se um conjunto de blobs dentro de um bloco através de um novo conjunto de blobs virtuais, que codificam as mesmas informações redundantes.

Com o DAS, o Ethereum pode processar uma quantidade maior de dados, permitindo rollups mais rápidos e baratos, sem comprometer a descentralização.

Em fases mais avançadas no futuro, será necessário fazer mais trabalho para determinar a versão ideal do DAS 2D e provar suas propriedades de segurança.

O caminho da realidade a longo prazo é:

1. Implementar o DAS 2D ideal;
2. Continuar a usar 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 principal arquitetura Layer2.

É importante notar que, mesmo que a decisão seja expandir a execução diretamente na camada L1, essa opção 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, terão que usar na camada L1 as mesmas tecnologias que os rollups (como ZK-EVM e DAS).

Plasma e outras soluções

Além do Rollup, uma das primeiras soluções de escalabilidade off-chain propostas, Plasma é outra solução L2.

Plasma cria sub-redes que processam transações de forma independente da cadeia principal Ethereum, submetendo resumos à rede principal regularmente. Para cada bloco, os operadores enviam um ramo Merkle a cada usuário para provar a mudança de estado dos ativos desse usuário. Os usuários podem retirar seus ativos fornecendo o ramo Merkle. É importante que este ramo não precise ser a raiz do estado mais recente.

Assim, mesmo que haja problemas de disponibilidade de dados, os usuários ainda podem recuperar seus ativos extraindo o estado mais recente disponível. Se um usuário submeter um ramo inválido (por exemplo, tentar retirar ativos que já foram enviados para outras pessoas, ou se o operador criar um ativo do nada), a legalidade da posse do ativo pode ser determinada através do mecanismo de desafio na cadeia.

Embora o desenvolvimento do Plasma esteja, de certa forma, atrasado em relação ao rollup, ainda é visto como parte do conjunto de ferramentas de escalabilidade mais amplo do Ethereum.

Além disso, há discussões sobre a melhoria da tecnologia de compressão de dados e das provas criptográficas, para aumentar ainda mais a eficiência do rollup e de outras soluções L2. A ideia é comprimir o máximo possível de dados, enquanto garante que todas as informações necessárias ainda estejam disponíveis para a validação pelos nós do Ethereum. Essas melhorias tecnológicas provavelmente desempenharão um papel crucial no processo de implementação de uma maior capacidade de throughput no Ethereum.

As versões iniciais do Plasma só conseguiam lidar com casos de pagamento, não sendo eficazes para uma maior promoção. No entanto, se for exigido que cada raiz seja verificada com SNARK, então o Plasma se tornará muito mais poderoso. O seu processo pode ser muito simplificado, uma vez que a maior parte das possíveis rotas de fraude dos operadores é excluída. Ao mesmo tempo, novas rotas são abertas, onde os usuários podem retirar fundos imediatamente, sem precisar esperar uma semana pelo período de contestação, desde que o operador não esteja a fraudar.

Uma forma de criar uma cadeia plasma EVM (não é a única forma) é: usar ZK-SNARK para construir uma árvore UTXO paralela, que reflete as alterações de saldo feitas pela EVM, definindo um mapeamento único para a "mesma moeda" em diferentes períodos históricos. Em seguida, pode-se construir a estrutura Plasma com base nisso.

O desempenho do Plasma é bastante bom, e essa é a razão chave pela qual todos precisam projetar estruturas de técnicas para superar suas deficiências de segurança.

Melhoria da Interoperabilidade entre L2

Um dos principais desafios que o ecossistema L2 enfrenta atualmente é a fraca interoperabilidade entre L2, sendo urgente melhorar como a experiência de usar o ecossistema L2 se assemelha à de um ecossistema Ethereum unificado.

As melhorias de interoperabilidade entre L2 têm muitas categorias. Teoricamente, Ethereum centrado em Rollup é semelhante ao L1 de fragmentação de execução. O atual ecossistema L2 do Ethereum ainda enfrenta os seguintes problemas na prática em relação ao estado ideal:

• Endereço de cadeia específico: o endereço deve conter informações da cadeia (L1, Optimism, Arbitrum......). Uma vez que isso seja realizado, o processo de envio entre L2 pode ser efetuado simplesmente colocando o endereço no campo de envio, momento em que a carteira pode lidar em segundo plano com a forma de envio (incluindo o uso de protocolos de cross-chain).

• Pedido de pagamento em cadeia específica: deve ser possível criar facilmente e de forma padronizada uma mensagem na forma de "envie-me X tokens do tipo Y na cadeia Z". Existem principalmente dois cenários de aplicação: pagamento entre pessoas ou pagamento entre pessoas e serviços de comerciantes; dApp solicita financiamento.

• Troca entre cadeias e pagamento de Gas: deve haver um protocolo aberto padronizado para expressar operações entre cadeias. O ERC-7683 e o RIP-7755 tentaram isso, embora a aplicação de ambos seja mais ampla do que esses casos de uso específicos.

• Cliente leve: os usuários devem ser capazes de verificar efetivamente a cadeia com a qual estão interagindo, e não apenas confiar nos provedores de RPC. O ERC-3668 (CCIP-read) é uma estratégia para alcançar esse objetivo.

• Conceito de ponte de token compartilhado: suponha que em um mundo onde todos os L2 são rollups de prova de validade e cada slot é submetido ao Ethereum, para transferir um ativo de um L2 para outro em estado nativo, ainda é necessário retirar e depositar, o que requer o pagamento de altas taxas de Gas de L1.

Uma forma de resolver este problema é: criar um Rollup minimalista compartilhado, cuja única função é manter o registro de qual L2 possui cada tipo de token e quanto saldo cada um possui, permitindo que esses saldos sejam atualizados em lote através de uma série de operações de envio entre L2 iniciadas por qualquer L2. Isso permitirá que transferências entre L2 sejam realizadas sem ter que pagar a taxa de gás L1 a cada transferência, nem usar tecnologias baseadas em provedores de liquidez como a ERC-7683.

• Sincronização combinatória: permite que chamadas sincronizadas ocorram entre um L2 específico e um L1 ou entre vários L2. Isso ajuda a aumentar a eficiência financeira dos protocolos DeFi. O primeiro pode ser alcançado sem coordenação entre L2s; o segundo requer ordenação compartilhada. A tecnologia baseada em rollup se aplica automaticamente a todas essas tecnologias.

Muitos dos exemplos acima enfrentam o dilema de quando padronizar e quais camadas padronizar. Se a padronização ocorrer muito cedo, pode consolidar uma solução inferior. Se a padronização ocorrer muito tarde, pode causar uma fragmentação desnecessária.

Atualmente, há um consenso de que: em certas situações, existe uma solução de curto prazo com uma propriedade mais fraca, mas mais fácil de implementar, assim como uma solução de longo prazo que é "finalmente correta", mas que levará anos para ser realizada. Essas tarefas não são apenas questões técnicas, mas também (e talvez principalmente) questões sociais, que requerem a colaboração entre L2 e carteiras, bem como L1.

Continuar a expandir o Ethereum L1

Expandir o Ethereum L1 em si e garantir que ele possa continuar a acomodar cada vez mais casos de uso é extremamente valioso.

Existem três estratégias de expansão L1, que podem ser realizadas de forma independente ou em paralelo:

1. Melhorar a tecnologia (como código do cliente, cliente sem estado, expiração histórica) para facilitar a verificação do L1, e depois aumentar o limite de Gas;
2. Reduzir o custo de operações específicas, aumentando a capacidade média sem aumentar o risco do pior caso;
3. Rollups nativos (ou seja, criação de N cópias paralelas do EVM).

Essas diferentes tecnologias têm diferentes compromissos. Por exemplo, os rollups nativos apresentam a mesma fraqueza em termos de composibilidade que os rollups normais: não é possível enviar uma única transação para executar operações de forma sincronizada em vários rollups. Aumentar o limite de Gas pode enfraquecer outros benefícios que podem ser alcançados através da simplificação da verificação L1, como aumentar a proporção de usuários que executam nós de verificação e aumentar o número de validadores solo. Dependendo da maneira como é implementado, tornar operações específicas no EVM mais baratas pode aumentar a complexidade geral do EVM.

Descentralização e segurança

O equilíbrio entre escalabilidade e descentralização é um dos temas frequentemente mencionados. Muitos projetos de blockchain optam por sacrificar a descentralização em troca de uma maior taxa de transferência. Por exemplo, uma determinada blockchain a cada