Confirmação rápida de transações: uma nova direção para melhorar a experiência do usuário Ethereum

Um aspecto importante da experiência do usuário em blockchain é a velocidade de confirmação das transações. Nos últimos anos, o Ethereum fez grandes avanços nessa área. Graças ao EIP-1559 e ao tempo de bloco estável após a transição para PoS, as transações enviadas pelos usuários na L1 geralmente podem ser confirmadas em 5 a 20 segundos, o que é aproximadamente equivalente à experiência de pagamento com cartão de crédito. No entanto, ainda há valor em encurtar ainda mais o tempo de confirmação, e algumas aplicações exigem até mesmo latência em subsegundos. Este artigo irá explorar várias soluções viáveis para melhorar a velocidade de confirmação das transações do Ethereum.

Visão Geral da Tecnologia Existente

finalidade de slot único

Atualmente, o consenso Gasper do Ethereum adota a arquitetura do Slot( e Epoch). A cada 12 segundos um slot, alguns validadores votam no cabeçalho da cadeia, 32 slots dentro de 6.4 minutos, todos os validadores votam uma vez em rodízio. Esses votos são interpretados como mensagens no algoritmo de consenso do tipo PBFT, e após dois epochs, 12.8 minutos, é fornecida uma finalização com forte garantia econômica.

Nos últimos anos, este método começou a mostrar deficiências: primeiro, a complexidade é alta, a interação entre os mecanismos de nível de slot e de época é propensa a erros; segundo, o tempo de espera de 12,8 minutos é demasiado longo. A Finalidade de Slot Único (Single Slot Finality, SSF) substituiu essa arquitetura através de um mecanismo semelhante ao Tendermint, permitindo que o bloco N seja confirmado definitivamente antes da geração do N+1. O SSF preserva o mecanismo de "vazamento inativo", permitindo que a cadeia continue a funcionar 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 traz uma enorme carga à cadeia. Embora haja algumas soluções de mitigação, como a recente proposta Orbit SSF, os usuários ainda precisam esperar de 5 a 20 segundos para confirmar a transação.

( Pré-confirmação de Rollup

Nos últimos anos, Ethereum tem seguido um roteiro centrado em rollups, projetando o L1 para suportar funcionalidades básicas como a disponibilidade de dados, para uso por protocolos L2 ) como rollups, validiums e plasmas (, oferecendo segurança equivalente aos usuários em uma escala maior.

Isto levou a uma divisão de trabalho dentro do ecossistema Ethereum: L1 foca na resistência à censura, fiabilidade e melhorias de funcionalidades principais, enquanto L2 serve mais diretamente as necessidades dos utilizadores. No entanto, L2 pretende oferecer confirmações mais rápidas do que 5-20 segundos.

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

Mas o conjunto de validadores L2 pode agir de forma maliciosa: assinar primeiro o bloco B1 e depois assinar o B2 em conflito e submetê-lo antecipadamente. Uma vez descobertos, eles perderão os ativos em staking. Já existem exemplos de versões centralizadas, mas o rollup está progredindo lentamente no desenvolvimento de redes de ordenação descentralizadas. Exigir que todos os L2 implementem uma ordenação descentralizada parece um pouco injusto, o que é quase equivalente a criar um novo L1. Portanto, foi sugerido que todos os L2) e L1( compartilhem um mecanismo de pré-confirmação dentro do alcance do Ethereum: pré-confirmação básica.

) Pré-confirmação básica

A suposição básica de pré-confirmação é que os proponentes do Ethereum são participantes altamente complexos relacionados ao MEV, aproveitando essa complexidade ao incentivá-los a assumir a responsabilidade pelos serviços de pré-confirmação.

A sua ideia básica é criar protocolos padronizados, onde os usuários podem pagar uma taxa adicional para garantir que a transação será incluída no próximo bloco, bem como para a declaração dos resultados da transação. Se o proponente incumprir, será penalizado.

Este mecanismo pode ser utilizado tanto para transações L1, como para blocos L2 "baseados" em rollups.

![Vitalik propôs o esquema de Epoch e slot: para fornecer tempos de confirmação de transação mais rápidos para o ETH, melhorando a experiência do usuário final]###https://img-cdn.gateio.im/webp-social/moments-cebb5794aeeb2ebb84fbdc0ea0ba2666.webp(

Perspectivas Futuras

Suponha que implementemos a finalização de um único slot, utilizando tecnologia semelhante ao Orbit para reduzir o número de validadores de assinatura por slot, enquanto avançamos na meta de redução do depósito de 32 ETH. A duração do slot pode aumentar para 16 segundos, e então utilizamos uma pré-confirmação rollup ou uma pré-confirmação básica para fornecer confirmações mais rápidas aos usuários. No final, temos uma nova era - arquitetura de slots.

A razão profunda pela qual essa arquitetura é difícil de evitar é que o tempo necessário para alcançar um consenso geral sobre algo é muito menor do que o tempo necessário para alcançar a "finalidade econômica" máxima.

As principais razões incluem o número de nós e a "qualidade" dos nós. A "consenso aproximado" requer apenas um pequeno número de nós, enquanto a finalização econômica necessita da participação da maioria dos nós. Um subconjunto de nós especializados pode reduzir o tempo do protocolo aproximado para cerca de 2 segundos.

Portanto, a arquitetura de epoch-slot parece ser a direção correta, mas existem diferenças entre as implementações. Vale a pena explorar a criação de um ponto de separação de foco mais forte entre os dois mecanismos, em vez de um acoplamento tão estreito como o Gasper.

![Vitalik propõe o esquema Epoch e slot: para fornecer tempos de confirmação de transação mais rápidos para o ETH, melhorando a experiência do usuário final])https://img-cdn.gateio.im/webp-social/moments-c36acc8d123e717d8dbd2c0b79a7a7ca.webp(

Escolha de L2

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

1. Tanto a nível técnico como de conceito, "baseado" em Ethereum, otimizando as propriedades fundamentais e os valores. Pode ser visto como "fragmentação de marca", e também pode inovar de forma audaciosa em áreas como o design de novas VM.

2. Tornar-se um "servidor com estrutura de blockchain", aproveitando ao máximo as vantagens da centralização, ao mesmo tempo garantindo a segurança através de provas de validade, mecanismos de saída, entre outros.

3. Solução de compromisso: uma cadeia rápida com cerca de cem nós, Ethereum oferece interoperabilidade e segurança adicionais. Esta é a rota atual de muitos projetos L2.

Para algumas aplicações ) como ENS, armazenamento de chaves, e alguns protocolos de pagamento ###, um tempo de bloco de 12 segundos é suficiente. Outras situações requerem a arquitetura de Época - Slot, onde "Época" é o SSF do Ethereum, e "Slot" varia conforme a aplicação.

A questão chave é até que ponto a arquitetura de época-slot nativa do Ethereum pode alcançar. Se o tempo de slot puder ser reduzido para 1 segundo, o espaço da terceira solução será significativamente reduzido.

Atualmente, ainda estamos longe das respostas finais para essas questões. A evolução da complexidade dos proponentes de blocos ainda apresenta uma grande incerteza. Designs inovadores como o Orbit SSF oferecem um amplo espaço para exploração. Quanto mais opções tivermos, melhor poderemos oferecer experiências para usuários de L1 e L2, além de simplificar o trabalho dos desenvolvedores de L2.