Autor original | Vitalik

Compilação | Odaily Planeta Diário Namji

Uma das características importantes de uma boa experiência do usuário em blockchain é o tempo rápido de confirmação das transações. Hoje, o Ethereum teve grandes melhorias em comparação com cinco anos atrás. Graças ao EIP-1559 e ao tempo de bloco estável após a transição para PoS (The Merge), as transações enviadas pelos usuários na L1 geralmente são confirmadas em 5 a 20 segundos, o que é comparável à experiência de pagamento com cartão de crédito. No entanto, melhorar ainda mais a experiência do usuário é valioso, e algumas aplicações exigem atrasos de centenas de milissegundos ou até mesmo mais curtos. Este artigo discutirá algumas opções práticas para melhorar o tempo de confirmação das transações no Ethereum.

Visão geral das ideias e tecnologias existentes

Finalidade Única

Atualmente, o consenso Gasper do Ethereum usa uma arquitetura com um único slot e epoch. A cada 12 segundos, um slot é atribuído e um grupo de validadores vota na cabeça da cadeia. Dentro de 32 slots (6,4 minutos), todos os validadores têm a chance de votar uma vez. Esses votos são então interpretados como mensagens em um algoritmo de consenso semelhante ao PBFT. Após dois epochs (12,8 minutos), é fornecida uma forte garantia econômica chamada finalidade.

Nos últimos anos, estamos cada vez mais insatisfeitos com os métodos atuais. Existem duas razões principais para isso, em primeiro lugar, este método é muito complexo, com muitos erros de interação entre o mecanismo de votação de slot para slot e o mecanismo de finalidade de Epoch para Epoch, em segundo lugar, 12,8 minutos é muito tempo, ninguém quer esperar tanto tempo.

A finalidade do slot único (Single Slot Finaty, SSF) substitui essa arquitetura por um mecanismo semelhante ao consenso do Tendermint, onde o bloco N é finalmente determinado antes de ser gerado o bloco N+1. A principal diferença em relação ao Tendermint é que mantemos o mecanismo de "vazamento de inatividade", o que permite que a cadeia continue a funcionar e se recupere quando mais de 1/3 dos validadores estão offline.

O principal desafio da finalidade única é que cada validador Ethereum precisa enviar duas mensagens a cada 12 segundos, o que é uma carga significativa para a cadeia. Existem algumas ideias inteligentes para mitigar esse problema, incluindo a recente proposta do Orbit SSF. Embora isso acelere significativamente a 'finalidade' para melhorar a experiência do usuário, não muda o fato de que os usuários precisam esperar de 5 a 20 segundos.

Confirmação antecipada de Rollup

Nos últimos anos, o Ethereum tem seguido consistentemente um roteiro centrado em rollup, projetando a camada base do Ethereum (L1) para suportar a disponibilidade de dados e outras funcionalidades, que podem ser utilizadas por protocolos L2 (como rollups, validiums e plasmas) para proporcionar segurança aos usuários em uma escala maior, equiparável à do Ethereum.

Isso levou à separação dos pontos de atenção dentro do ecossistema do Ethereum: o Ethereum L1 se concentra em ser anticensura, confiável, estável, além de manter e melhorar as funcionalidades centrais de uma camada base, enquanto o L2 se concentra em interagir diretamente com os usuários por meio de culturas e tecnologias diferentes. No entanto, ao seguir por esse caminho, surge um problema inevitável: o L2 deseja fornecer confirmações mais rápidas do que os 5-20 segundos para os usuários.

Até agora, pelo menos em teoria, criar a sua própria rede de "validadores descentralizados" é a responsabilidade da L2. Um pequeno grupo de validadores pode assinar um bloco a cada poucas centenas de milissegundos e alocar os seus ativos de stake nestes blocos. Eventualmente, os cabeçalhos destes blocos L2 serão publicados para o L1.

Mas o conjunto de validadores L2 pode ser "enganado": eles podem assinar Bloco B1 antes de assinar um Bloco B2 conflitante e enviá-lo ao na cadeia antes de B1. Mas, se o fizerem, serão identificados e perderão os seus bens stake. Na verdade, vimos exemplos reais de versões centralizadas, mas, por outro lado, rollups demoraram a desenvolver redes de ordenação de descentralização. Você poderia argumentar que é injusto exigir que todos os L2s tenham pedidos de descentralização: estamos pedindo que rollups façam praticamente o mesmo trabalho que criar um novo L1. Como resultado, Justin Drake tem promovido uma abordagem que permitiria que todos os L2 (e L1s) usassem um mecanismo de pré-confirmação compartilhado em toda a Ethereum: pré-confirmação de base.

Confirmação Prévia Básica

O método de pré-confirmações baseadas pressupõe que os proponentes da Ethereum são participantes altamente complexos relacionados ao MEV. Este método baseado em pré-confirmação incentiva esses proponentes complexos a assumir a responsabilidade de fornecer serviços de pré-confirmação para aproveitar essa complexidade.

A ideia básica deste método é criar um protocolo padronizado, no qual os utilizadores podem fornecer uma taxa extra para garantir uma 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 da transação. Se o proponente violar qualquer compromisso feito a qualquer utilizador, poderá ser sujeito a corte.

Como mencionado, é fornecida uma garantia prévia para transações L1 com base na confirmação. Se os rollups são "baseados", então todos os blocos L2 são transações L1, portanto, o mesmo mecanismo pode ser usado para fornecer pré-confirmação para qualquer L2.

O que estamos realmente a ver?

Suponhamos que tenhamos alcançado a finalização de uma única slot. Usamos uma tecnologia semelhante à Orbit para reduzir a quantidade de validadores que assinam cada slot, mas não reduziremos muito, para que também possamos progredir no objetivo crítico de reduzir o limite mínimo de stake de 32 ETH. O tempo da slot pode aumentar para 16 segundos, e então usamos pré-confirmação de rollup ou pré-confirmação de base para fornecer confirmações mais rápidas aos usuários. No final, o que conseguimos é uma estrutura de slot de época.

Há uma razão filosófica profunda pela qual a arquitetura de epoch-and-slot parece ser tão difícil de evitar: leva menos tempo para chegar a um consenso aproximado sobre algo do que chegar a um acordo máximo de 'finalidade econômica' sobre algo.

Uma razão simples é a quantidade de nós. Embora devido à agregação BLS super otimizada e aos próximos ZK-STARKs, as antigas compensações lineares de descentralização/tempo final/custo parecem agora mais suaves, as seguintes razões não podem ser ignoradas:

• O 'consenso aproximado' requer apenas alguns nós, enquanto a finalidade econômica requer a maioria dos nós.
• Uma vez que o número de nós ultrapassa um certo limite, você precisa gastar mais tempo coletando assinaturas.

Na Ethereum de hoje, o slot de 12 segundos é dividido em três sub-slots: publicação e distribuição de blocos, prova, agregação de prova. Se o número de provadores diminuir significativamente, podemos reduzir para dois sub-slots e usar um tempo de slot de 8 segundos. Outro fator prático maior é a “qualidade” dos nós. Outro fator maior é a “qualidade” dos nós. Se também pudermos depender de um subconjunto de nós especializados para alcançar um acordo aproximado (e ainda assim usar o conjunto completo de validadores para determinar a finalidade), podemos reduzi-lo para cerca de 2 segundos.

Portanto, na minha opinião, a arquitetura de epoch-and-slot é claramente a correta, mas nem todas as arquiteturas de epoch-and-slot são iguais. É valioso explorar mais amplamente o espaço de design. A direção que vale a pena estudar não é uma integração tão estreita como a do Gasper, mas sim um foco separado mais forte entre os dois mecanismos.

Como a L2 deve ser feita?

Na minha opinião, L2 atualmente tem três estratégias razoáveis:

• Tecnicamente e espiritualmente 'baseado'. Ou seja, otimizam as propriedades técnicas e os valores fundamentais do Ethereum (altamente descentralizado, resistente à censura, etc.). Na forma mais simples, você pode ver esses rollups como 'fragmentação de marca', mas também podem ter ambições maiores, experimentando muito em novos designs de máquinas virtuais e outras melhorias tecnológicas.
• Tornar-se um servidor com um esqueleto de blockchain e tirar o máximo partido dele. Se começar com um servidor e adicionar a prova de validade STARK para garantir que o servidor siga as regras; garantir o direito dos utilizadores a sair ou forçar transações; liberdade de escolha coletiva, através de uma saída em grande escala coordenada ou mudando o voto dos ordenadores, então já obteve a maioria dos benefícios de estar na cadeia, ao mesmo tempo que mantém a maior parte da eficiência do servidor. *Método de Compromisso: Uma cadeia rápida com cem nós, o Ethereum fornece interoperacionalidade e segurança adicionais. Este é o roteiro real de muitos projetos L2 atuais.

Para algumas aplicações (como ENS, armazenamento de chaves e alguns protocolos de pagamento), um tempo de bloco de 12 segundos é suficiente. Para as aplicações que não são adequadas, a única solução é a arquitetura de época e slot. Em todos os três casos, 'época' é o SSF do Ethereum, mas 'slot' é diferente em cada um dos três casos acima mencionados:

• Uma arquitetura de época e slot nativa do Ethereum
• Servidor Pré-Confirmado
• Comissão pré-confirmada

Uma questão-chave é o quão bem podemos fazer na Categoria 1? Especialmente se isso se tornar muito bom, então o significado da Categoria 3 não será tão grande. Porque todos os esquemas "baseados" não se aplicam aos dados fora da cadeia, como plasmas e validiums L2, a Categoria 2 existirá para sempre. Se uma arquitetura de epoch-and-slot nativa do Ethereum pode reduzir o tempo do slot para 1 segundo, então o espaço da Categoria 3 será muito menor.

Hoje, estamos longe de ter as respostas finais para essas questões. Uma questão-chave é: o quão complexos os proponentes de blocos se tornarão, o que ainda é uma área de grande incerteza. Designs inovadores, como o Orbit SSF, são muito novos, portanto, ainda vale a pena explorar totalmente o espaço de design do Orbit SSF, por exemplo, como um esquema para epochs e slots em epoch. Quanto mais opções tivermos, melhor poderemos atender aos usuários de L1 e L2, além de simplificar o trabalho dos desenvolvedores de L2.