Acelerar a confirmação de transações Ethereum: explorar novas soluções para melhorar a experiência do usuário

Um dos elementos centrais da experiência do usuário em blockchain é o rápido tempo de confirmação das transações. Nos últimos anos, o Ethereum fez progressos significativos nessa área. Graças ao EIP-1559 e à mudança para um tempo de bloqueio estável após a prova de participação, as transações enviadas pelos usuários na mainnet normalmente podem ser confirmadas em 5 a 20 segundos, atingindo basicamente o nível de experiência de pagamento com cartão de crédito. No entanto, ainda é valioso encurtar ainda mais o tempo de confirmação, e algumas aplicações até exigem latências abaixo de um segundo. Este artigo explorará várias soluções viáveis para o Ethereum melhorar o tempo de confirmação das transações.

Visão geral da tecnologia existente

finalização de slot único

Atualmente, o consenso Gasper do Ethereum adota uma estrutura de dupla camada com slots e épocas. A cada 12 segundos, um slot, um grupo de validadores vota no cabeçalho da cadeia, 32 slots (6.4 minutos ) todos os validadores têm a oportunidade de votar uma vez. Esses votos são então interpretados como mensagens no algoritmo de consenso tipo PBFT, duas épocas (12.8 minutos ) após fornecer garantias econômicas fortes de finalização.

Nos últimos anos, as limitações desse método tornaram-se cada vez mais evidentes. Em primeiro lugar, a complexidade é alta, existindo muitos problemas de interação entre a votação a nível de slot e a finalização a nível de época. Em segundo lugar, o tempo de espera de 12,8 minutos é demasiado longo, resultando numa experiência do utilizador insatisfatória.

A finalização de slot único (SSF) substituiu essa arquitetura por um mecanismo semelhante ao Tendermint, permitindo a confirmação final do bloco N antes da geração do bloco N+1. A principal diferença em relação ao Tendermint é que o mecanismo de "vazamento inativo" foi mantido, permitindo que a cadeia continue a funcionar e se recupere mesmo com mais de 1/3 dos validadores offline.

O principal desafio do SSF é que cada participante deve publicar duas mensagens a cada 12 segundos, o que gera uma carga considerável na cadeia. Embora haja algumas soluções engenhosas que podem aliviar esse problema, como o recentemente proposto Orbit SSF, os usuários ainda precisam esperar de 5 a 20 segundos.

Pré-confirmação de Rollup

Nos últimos anos, o Ethereum tem seguido um roteiro centrado em rollup, projetando a camada base para suportar a disponibilidade de dados e outras funcionalidades, para uso por protocolos L2, a fim de fornecer garantias de segurança em maior escala aos usuários.

Isso levou a uma separação de focos dentro do ecossistema Ethereum: L1 foca na resistência à censura, confiabilidade e melhorias nas funcionalidades centrais, enquanto L2 serve diretamente os usuários através de diferentes culturas e tecnologias. No entanto, L2 espera oferecer confirmações mais rápidas do que 5-20 segundos.

Teoricamente, é responsabilidade do L2 criar uma rede de ordenadores descentralizada. Um pequeno grupo de validadores pode assinar blocos a cada poucas centenas de milissegundos e fazer staking de ativos. Os cabeçalhos desses blocos L2 acabarão por ser publicados no L1.

Os validadores de L2 podem trapacear: assinar primeiro o bloco B1, depois assinar o bloco B2 em conflito e submeter B2 à cadeia antes de B1. Mas fazer isso fará com que sejam descobertos e percam os ativos em staking. Embora já existam casos reais de versões centralizadas, o rollup está avançando lentamente no desenvolvimento de redes de ordenação descentralizadas.

Exigir que todos os L2 realizem uma ordenação descentralizada parece um pouco irrazoável, pois isso equivale a exigir que o rollup faça um trabalho quase idêntico ao de criar um novo L1. Assim, alguém propôs que todos os L2 (e L1) utilizem um mecanismo de pré-confirmação compartilhado dentro do âmbito do Ethereum: pré-confirmação básica.

confirmação prévia básica

A suposição básica de pré-confirmação é que os proponentes do Ethereum são participantes complexos que lidam com MEV. Este método utiliza a especialização desses proponentes ao incentivá-los a assumir a responsabilidade de fornecer serviços de pré-confirmação.

A sua ideia central é criar um protocolo padrão pelo qual os usuários podem pagar uma taxa extra para obter a garantia imediata de que a transação será incluída no próximo bloco, bem como uma declaração sobre o resultado da execução. Se o proponente violar o compromisso, enfrentará penalizações.

Este mecanismo não se aplica apenas às transações L1, para rollups "baseados em", todos os blocos L2 são transações L1, portanto, também pode fornecer pré-confirmação para qualquer L2.

Perspectivas Futuras

Suponha que a finalização de slot único tenha sido implementada, utilizando tecnologia semelhante ao Orbit para reduzir o número de validadores que assinam cada slot, ao mesmo tempo em que mantém o objetivo de reduzir o limite de estaca de 32 ETH. A duração do slot pode aumentar para 16 segundos, combinada com pré-confirmações de rollup ou pré-confirmações básicas para oferecer uma confirmação mais rápida aos usuários. No final, podemos obter uma arquitetura de época-slot.

Esta arquitetura parece difícil de evitar, uma vez que o tempo necessário para alcançar um consenso aproximado sobre algo é muito menor do que o necessário para alcançar a "finalidade econômica" máxima. As razões incluem o número de nós e a "qualidade" dos nós. Se pudermos contar com um subconjunto de nós especializados para alcançar um acordo aproximado, enquanto usamos um conjunto completo de validadores para determinar a finalidade, o tempo de confirmação pode diminuir para cerca de 2 segundos.

Portanto, a arquitetura Epoch-Slot parece ser a direção correta, mas existem diferenças entre as várias implementações. Vale a pena explorar a criação de um ponto de separação mais forte entre os dois mecanismos, em vez de ser acoplado de forma tão apertada como o Gasper.

Escolha de estratégia L2

Atualmente, existem três estratégias razoáveis para L2:

1. Tecnologicamente e em termos de conceito, "baseado" em Ethereum, otimizando suas propriedades e valores fundamentais.
2. Tornar-se um "servidor com estrutura de blockchain", aproveitando ao máximo a eficiência do servidor.
3. Solução de compromisso: uma cadeia rápida com cerca de cem nós, Ethereum oferece interoperabilidade e segurança adicionais.

Para algumas aplicações, um tempo de bloco de 12 segundos é suficiente. Para outras aplicações, a única solução é a arquitetura de Época - Slot. Nos três casos, "Época" é o SSF do Ethereum, mas os "Slots" são diferentes:

1. Estrutura de época-nativa do Ethereum - estrutura de slots
2. Pré-confirmação do servidor
3. Confirmação prévia do comitê

A questão chave é quão bem a primeira solução pode funcionar. Se os resultados forem significativos, o significado da terceira solução pode diminuir. A segunda solução sempre existirá, pois as soluções "baseadas em" não são aplicáveis a certos dados off-chain L2. Se a arquitetura de era-slot nativa do Ethereum puder reduzir o tempo do slot para 1 segundo, o espaço da terceira solução será consideravelmente reduzido.

Atualmente, as respostas finais para essas questões ainda não foram determinadas. Uma incerteza chave é quão complexos os proponentes de blocos se tornarão. Designs inovadores como o Orbit SSF oferecem oportunidades para exploração adicional, como utilizá-lo como um éon dentro de um slot de éon. Quanto mais opções houver, melhor poderemos servir os usuários de L1 e L2, ao mesmo tempo que simplificamos o trabalho dos desenvolvedores de L2.