Proporcionar tempos de confirmação de transação mais rápidos para ETH, melhorando a experiência do usuário

O tempo rápido de confirmação de transações é uma das características importantes de uma boa experiência de usuário em blockchain. Nos últimos anos, o Ethereum fez progressos significativos nessa área. Graças ao EIP-1559 e à estabilidade do tempo de blocos após a transição para PoS, as transações enviadas pelos usuários na L1 podem geralmente ser confirmadas em 5 a 20 segundos, o que é basicamente equivalente à experiência de pagamento com cartão de crédito. No entanto, ainda é valioso melhorar a experiência do usuário, pois algumas aplicações exigem até mesmo latências em nível sub-segundo. Este artigo explorará algumas opções viáveis que o Ethereum tem para melhorar o tempo de confirmação de transações.

Visão geral da tecnologia existente

finalidade de slot único

Atualmente, o consenso Gasper do Ethereum adota uma arquitetura de slots e épocas. A cada 12 segundos, um slot, onde parte dos validadores vota no cabeçalho da cadeia, e todos os validadores têm a oportunidade de votar uma vez dentro de 32 slots (6,4 minutos). Esses votos são reinterpretados como mensagens semelhantes ao algoritmo de consenso PBFT, e após duas épocas (12,8 minutos), oferecem uma garantia econômica forte conhecida como finalização.

Nos últimos anos, este método tem vindo a perder popularidade, principalmente por duas razões: primeiro, é demasiado complexo, existindo muitos problemas de interação entre o mecanismo de votação por slot e o mecanismo de finalização por época; segundo, o tempo de espera de 12,8 minutos é demasiado longo.

A finalização de slot único (SSF) substitui essa arquitetura através de um mecanismo semelhante ao Tendermint, onde o bloco N é finalizado antes da geração do bloco N+1. A principal diferença em relação ao Tendermint é a preservação do mecanismo de "vazamento inativo", que permite que a cadeia continue a operar e se recupere mesmo quando mais de 1/3 dos validadores estão offline.

O principal desafio do SSF é que cada staker precisa publicar duas mensagens a cada 12 segundos, o que representa uma grande carga para a cadeia. Embora haja algumas ideias inovadoras como o Orbit SSF que podem aliviar esse problema, os usuários ainda precisam esperar de 5 a 20 segundos.

Pré-confirmação de Rollup

A Ethereum sempre seguiu um roteiro centrado em rollups, projetando a camada base (L1) para suportar a disponibilidade de dados e outras funcionalidades, para uso pelos protocolos L2. Isso cria uma separação de preocupações dentro do ecossistema: L1 foca na resistência à censura, confiabilidade e estabilidade, enquanto L2 se dirige mais diretamente aos usuários.

Teoricamente, a criação de uma rede de ordenadores descentralizados é responsabilidade do L2. Um pequeno grupo de validadores pode assinar blocos a cada poucos centenas de milissegundos e, em seguida, investir ativos em garantia nesses blocos. Os cabeçalhos desses blocos L2 serão eventualmente publicados no L1.

No entanto, exigir que todos os L2 realizem uma ordenação descentralizada parece um pouco injusto, o que equivale a exigir que o rollup complete um trabalho quase idêntico ao de criar um novo L1. Assim, foi sugerido que todos os L2 (e L1) utilizem um mecanismo de pré-confirmação compartilhado dentro do alcance do Ethereum: a pré-confirmação básica.

pré-confirmação básica

O método básico de pré-confirmação assume que os proponentes do Ethereum são participantes altamente complexos relacionados com o MEV. Ele aproveita essa complexidade incentivando esses proponentes a aceitarem a responsabilidade de fornecer serviços de pré-confirmação.

Este método cria um protocolo padronizado, onde os usuários podem fornecer taxas adicionais para garantir instantaneamente que a transação será incluída no próximo bloco, bem como uma declaração sobre o resultado da execução dessa transação. Se o proponente violar o compromisso, poderá ser penalizado.

Este mecanismo não só garante as transações L1, mas para os rollups "baseados", 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 um único slot foi alcançada, utilizando tecnologias semelhantes ao Orbit para reduzir o número de validadores que assinam cada slot, ao mesmo tempo em que se avança na redução do limite mínimo de staking de 32 ETH. A duração do slot pode aumentar para 16 segundos, e em seguida, usar pré-confirmação de rollup ou pré-confirmação básica para fornecer uma confirmação mais rápida aos usuários. No final, chegamos a uma nova era - a arquitetura de slots.

Esta arquitetura parece difícil de evitar, pois o tempo necessário para alcançar um consenso aproximado sobre algo é mais curto do que o tempo 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 especializado de nós para alcançar um acordo aproximado (ainda utilizando o conjunto completo de validadores para determinar a finalidade), podemos reduzir o tempo de confirmação para cerca de 2 segundos.

Portanto, explorar o espaço de design ainda é valioso, especialmente em direções onde há uma separação mais forte dos pontos de foco entre os dois mecanismos.

Escolha de estratégia L2

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

1. Em termos técnicos e de conceito, "baseado" no ETH, otimizando suas propriedades técnicas fundamentais e valores.
2. Tornar-se "servidor com estrutura de blockchain", aproveitando ao máximo a eficiência do servidor e a segurança da blockchain.
3. Método de compromisso: uma cadeia rápida com cerca de cem nós, fornecendo interoperabilidade e segurança adicionais através do Ethereum.

Para algumas aplicações, um tempo de bloco de 12 segundos já é suficiente. Para outras aplicações, a única solução é a arquitetura de época-slot. A questão chave é quão bem a arquitetura nativa de época-slot do Ethereum pode funcionar. Se conseguir reduzir para um tempo de slot de 1 segundo, então o espaço para a terceira estratégia se tornará muito pequeno.

Atualmente, ainda estamos longe das respostas finais para essas questões. A complexidade dos proponentes de blocos ainda é incerta, e novos designs como o Orbit SSF também merecem uma exploração mais aprofundada. Quanto mais opções tivermos, melhor poderemos atender os usuários de L1 e L2, além de simplificar o trabalho dos desenvolvedores de L2.