Autor original | Vitalik
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).
Nos últimos anos, ficamos cada vez mais insatisfeitos com a nossa abordagem atual. Há duas razões principais para isso. Em primeiro lugar, este método é complicado e há muitos erros de interação entre o mecanismo de votação entre intervalos e o mecanismo de finalização de época para época. Em segundo lugar, 12,8 minutos é muito longo e ninguém quer. esperar 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.
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.
Pré-confirmação de rollup
Ethereum tem seguido um roteiro centrado em rollup nos últimos anos, 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. fornecer aos usuários o mesmo nível de segurança que o Ethereum em uma escala maior.
Isto cria uma separação de preocupações dentro do ecossistema Ethereum: Ethereum L1 concentra-se na resistência à censura, confiabilidade, estabilidade e manutenção e melhoria da funcionalidade central de uma determinada camada base, enquanto L2 se concentra na comunicação mais direta através de diferentes culturas e tecnologias Reach out. aos 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 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 cometer “fraude”: eles podem assinar o bloco B1 primeiro e depois assinar um bloco B2 conflitante e enviá-lo para a cadeia antes de B1. 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 sido lento no desenvolvimento de redes de pedidos descentralizadas. Você poderia argumentar que é injusto exigir que todos os L2s sejam descentralizados: estamos pedindo ao rollup que faça quase o mesmo trabalho que criar um L1 completamente novo. Como resultado, 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 básica.
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 são transações L1, portanto o mesmo mecanismo pode ser usado para fornecer pré-confirmação para qualquer L2.
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 de 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 obtivemos no final: 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 grande 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 mais realista e maior é a “qualidade” do nó. 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 isso para aproximadamente 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 criadas 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 em 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:
Tanto técnica quanto espiritualmente "baseados". 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.
Torne-se um “servidor com andaime 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 a liberdade de escolha coletiva, seja por meio de retiradas em massa coordenadas ou pela alteração do ordenante; vote, então você obteve a maioria dos benefícios do uplinking, mantendo a maior parte da eficiência do servidor.
O meio-termo: uma cadeia rápida com cem nós, o Ethereum oferece interoperabilidade e segurança extras. Este é o roteiro atual de facto para muitos projetos L2.
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 três casos, a “época” é o SSF do Ethereum, mas o slot é diferente em cada um dos três casos acima:
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? Em particular, se ficar realmente bom, parece que a Categoria 3 não significará tanto. Como todas as soluções “baseadas” não funcionam com dados L2 fora da cadeia, como plasmas e validiums, a categoria 2 sempre existirá. Se uma arquitetura de época e slot nativa do Ethereum puder ser reduzida para 1 segundo de slot time, então o espaço para a Categoria 3 se tornará 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, o espaço de design de esquemas como o uso do Orbit SSF como uma época em época e slot ainda é digno de exploração completa. 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.