"A arquitetura de época e slot é obviamente a resposta certa, mas a arquitetura e as soluções de slot ainda precisam ser exploradas."
Autor original | Vitalik Buterin
Compilação | Odaily Planet Daily Nan Zhi
Um dos atributos importantes de uma boa experiência do usuário blockchain é o tempo rápido de confirmação da transação. Hoje, o Ethereum melhorou muito em relação ao que era há cinco anos. Graças ao EIP-1559 e ao tempo de bloqueio estável após a mudança para PoS (The Merge), as transações enviadas pelos usuários em L1 geralmente podem ser confirmadas dentro de 5 a 20 segundos, o que é aproximadamente equivalente à experiência de pagar com cartão de crédito. No entanto, há valor em melhorar ainda mais a experiência do usuário, e alguns aplicativos exigem latências de centenas de milissegundos ou menos. Este artigo explorará algumas opções práticas para melhorar os tempos de confirmação de transações no Ethereum.
Visão geral das ideias e técnicas existentes
finalidade de slot único
Atualmente, o consenso Gasper da Ethereum usa um único slot (Slot) e arquitetura Epoch. A cada 12 segundos um slot, um subconjunto de validadores vota no topo da cadeia, e a cada 32 slots (6,4 minutos), todos os validadores têm a chance de votar uma vez. Estes votos são então reinterpretados como mensagens num algoritmo de consenso semelhante ao PBFT, dando uma garantia económica muito forte chamada finalidade após duas Épocas (12,8 minutos).
(Observação diária: para obter detalhes sobre os princípios específicos, consulte "Explicação detalhada do princípio de funcionamento do Ethereum POS: Epoch, Slot e Beacon Block")
Nos últimos anos, ficamos cada vez mais insatisfeitos com a nossa abordagem atual. Existem duas razões principais para isto: em primeiro lugar, o método é complicado e existem muitos erros de interacção entre o mecanismo de votação slot-to-slot e o mecanismo de finalização de época a época e, em segundo lugar, 12,8 minutos é demasiado longo e ninguém quer espere tanto tempo.
O Single Slot Finality (SSF) substitui esta arquitetura por um mecanismo semelhante ao consenso do Tendermint, onde o bloco N é finalizado antes que o bloco N+ 1 seja gerado. A principal diferença do Tendermint é que mantemos o mecanismo de “vazamento de inatividade”, que permite que a cadeia continue funcionando e se recupere se mais de 1/3 dos validadores estiverem offline.
(Nota do Odaily: O vazamento de inatividade é um mecanismo em PoS projetado para punir validadores que estiveram inativos por um longo tempo. Uma vez marcados como inativos, seu ETH apostado continuará a ser punido. Tendermint é um algoritmo de consenso de tolerância a falhas bizantina eficiente e seguro permite para confirmação rápida de transações e garante que o sistema blockchain ainda possa operar normalmente, mesmo se alguns nós forem maliciosos ou offline.)
O principal desafio da finalidade de slot único é que isso significa que cada staker Ethereum precisa publicar duas mensagens a cada 12 segundos, o que é uma carga significativa na cadeia. Existem algumas ideias inteligentes para mitigar este problema, incluindo a recente proposta Orbit SSF. Embora isso acelere significativamente a “finalidade” para melhorar a experiência do usuário, isso não altera o fato de que os usuários precisam esperar de 5 a 20 segundos.
(Observação diária: a finalidade e a transação sendo empacotada em um bloco e confirmada não são o mesmo evento. Quando a transação é confirmada, mas a finalidade não é alcançada, pode ocorrer uma bifurcação ou reversão.)
Pré-confirmação de rollup
Nos últimos anos, Ethereum tem seguido um roteiro centrado em rollup, projetando a camada base Ethereum (L1) para suportar a disponibilidade de dados e outros recursos, que são então disponibilizados para protocolos L2, como rollups, validiums e plasmas. para fornecer aos usuários o mesmo nível de segurança do Ethereum em maior escala.
Isso cria uma separação de preocupações dentro do ecossistema Ethereum: Ethereum L1 se concentra na resistência à censura, confiabilidade, estabilidade e manutenção e melhoria das funções principais de uma determinada camada base, enquanto L2 se concentra em ser mais direto por meio de diferentes culturas e tecnologias que alcançam os usuários. . Mas se você seguir esse caminho, surge um problema inevitável: L2 quer fornecer aos usuários confirmações mais rápidas do que 5 a 20 segundos.
Até agora, pelo menos em teoria, tem sido responsabilidade do L2 criar a sua própria rede de “sequenciadores descentralizados”. Um pequeno grupo de validadores pode assinar blocos a cada centenas de milissegundos e apostar nesses blocos. Eventualmente, os arquivos de cabeçalho desses pedaços L2 são publicados em L1.
Mas o conjunto de validadores L2 pode “trapacear”: eles podem assinar o bloco B 1 primeiro e depois assinar um bloco B 2 conflitante e enviá-lo à cadeia antes de B 1. Mas se o fizerem, serão apanhados e perderão os bens prometidos. Na verdade, vimos exemplos práticos de versões centralizadas, mas o rollup, por outro lado, tem demorado a desenvolver uma rede de classificação descentralizada. Você poderia argumentar que exigir um pedido descentralizado de todos os L2s é injusto: estamos pedindo ao rollup que faça praticamente o mesmo trabalho que criar um L1 inteiramente novo. Como tal, Justin Drake tem promovido uma maneira para todos os L2 (bem como L1) usarem um mecanismo de pré-confirmação compartilhado em todo o Ethereum: pré-confirmação de base.
Pré-confirmação básica
A abordagem às pré-confirmações baseadas assume que os proponentes do Ethereum são participantes altamente sofisticados associados ao MEV. As abordagens baseadas na pré-confirmação exploram esta complexidade, incentivando estes proponentes complexos a aceitarem a responsabilidade pela prestação de serviços de pré-confirmação.
A ideia básica desta abordagem é criar um protocolo padronizado onde os usuários possam fornecer uma taxa adicional para garantir uma garantia instantânea de que uma transação será incluída no próximo bloco, bem como uma reclamação sobre os resultados da execução dessa transação. Se um proponente quebrar qualquer promessa feita a qualquer usuário, ele poderá ser cortado.
Conforme mencionado, as transações L1 são garantidas com base na pré-confirmação. Se os rollups forem "Baseados", então todos os blocos L2 serão transações L1, portanto o mesmo mecanismo pode ser usado para fornecer pré-confirmação para qualquer L2.
(Nota Odaily: Os proponentes do Ethereum podem usar o mecanismo de taxa para agrupar uma série de transações em um pacote e empacotá-las em um bloco para garantir a execução e a ordem da transação. Por exemplo, o conhecido clipe garante que a compra antes de uma determinada transação e venda mais tarde. O plano proposto aqui por Vitalik é conceitualmente o mesmo. Use este proponente para bloquear os resultados da transação antecipadamente e acelerar a execução.)
O que estamos realmente olhando?
Suponha que alcancemos a finalidade de slot único. Usamos tecnologia semelhante à Orbit para reduzir o número de validadores assinando por slot, mas não muito, para que também possamos progredir no objetivo principal de reduzir o mínimo de staking de 32 ETH. O tempo do intervalo pode ser aumentado para 16 segundos e, em seguida, usamos a pré-confirmação rollup ou a pré-confirmação básica para fornecer aos usuários uma confirmação mais rápida. O que obtemos: uma arquitetura de slot de época.
Há uma razão filosófica profunda pela qual a arquitectura de época e slot parece tão difícil de evitar: leva menos tempo para chegar a um acordo aproximado sobre algo do que para chegar a um acordo sobre algo com o maior grau de “finalidade económica”.
Um motivo simples é o número de nós. Embora a antiga compensação linear de descentralização/tempo de finalização/despesas gerais agora pareça moderada devido à agregação BLS ultra-otimizada e aos próximos ZK-STARKs, os seguintes motivos não podem ser ignorados:
O “consenso aproximado” requer apenas um pequeno número de nós, enquanto a finalidade económica requer uma maioria de nós.
Quando o número de nós exceder um determinado tamanho, você precisará gastar mais tempo coletando assinaturas.
No Ethereum de hoje, o slot de 12 segundos é dividido em três sub-slots: publicação e distribuição em bloco, atestado e agregação de atestado. Se o número de provadores for reduzido significativamente, podemos reduzir para dois subintervalos e usar o tempo de intervalo de 8 segundos. Outro fator importante é a “qualidade” do nó. Se também pudéssemos contar com um subconjunto especializado de nós para chegar a um acordo aproximado (e ainda usar o conjunto completo de validadores para determinar a finalidade), poderíamos reduzir esse tempo para cerca de 2 segundos.
Então, na minha opinião, a arquitetura de época e slot está claramente correta, mas nem todas as arquiteturas de época e slot são iguais e há valor em explorar o espaço de design de forma mais completa. Uma direção digna de mais investigação não é tão fortemente acoplada como Gasper, mas com uma separação mais forte de preocupações entre os dois mecanismos.
O que L2 deve fazer?
Na minha opinião, L2 tem atualmente três estratégias razoáveis:
1. É “baseado” técnica e espiritualmente. Ou seja, otimizam as propriedades técnicas da camada base do Ethereum e seus valores (alta descentralização, resistência à censura, etc.). Em sua forma mais simples, você pode pensar nesses rollups como “fragmentos de marca”, mas eles também podem ser muito mais ambiciosos, experimentando intensamente novos designs de máquinas virtuais e outras melhorias técnicas.
2. Torne-se um “servidor com estrutura blockchain” e aproveite ao máximo. Se você começar com um servidor e depois adicionar provas de validade STARK para garantir que o servidor siga as regras para garantir o direito dos usuários de retirar ou forçar transações e para garantir a liberdade de escolha coletiva, seja por meio de retirada em massa coordenada; uma votação dos solicitantes de mudança, então você A maioria dos benefícios de entrar na rede foi obtida, mantendo a maior parte da eficiência do servidor. (Observação diária: Scaffolding refere-se a uma ferramenta ou método que gera automaticamente a estrutura básica e a estrutura de código de um projeto para que os desenvolvedores possam iniciar a codificação rapidamente.)
3. Um meio-termo: uma cadeia rápida com cem nós, o Ethereum oferece interoperabilidade e segurança adicionais. Este é o roteiro real para muitos projetos L2 no momento.
Para algumas aplicações (por exemplo, ENS, armazenamento de chaves, alguns protocolos de pagamento), um tempo de bloqueio de 12 segundos é suficiente. Para aquelas aplicações onde isto não é aplicável, a única solução é uma arquitetura de época e slot. Em todos os três casos, a “época” é o SSF do Ethereum, mas o slot é diferente em cada um dos três casos:
Uma arquitetura de época e slot nativa do Ethereum
Pré-confirmação do servidor
pré-confirmação do comitê
Uma questão fundamental é: até que ponto podemos ser bons na categoria 1? Especialmente se ficar realmente bom, parece que a Categoria 3 não significará tanto. Como todas as soluções “baseadas” não são aplicáveis a dados L2 fora da cadeia, como plasmas e validiums, a categoria 2 sempre existirá. Se uma arquitetura de época e slot nativa do Ethereum pudesse ser reduzida para 1 segundo de slot time, então o espaço da Classe 3 se tornaria muito menor.
Hoje, estamos longe de respostas definitivas para essas questões. Uma questão chave é até que ponto os proponentes de blocos se tornarão complexos, o que continua a ser uma área de considerável incerteza. Projetos como o Orbit SSF são muito novos, portanto, ainda vale a pena explorar totalmente o espaço de design para esquemas como o Orbit SSF como uma época em uma época e slot. Quanto mais opções tivermos, melhor poderemos fazer para os usuários de L1 e L2, e poderemos facilitar a vida dos desenvolvedores de L2.
Link original
Este artigo foi reimpresso com permissão do Odaily Planet Daily
Fonte