Encaminhar o Título Original 'Épocas e slots até o fim: formas de proporcionar aos utilizadores do Ethereum tempos de confirmação de transação mais rápidos'

Uma das propriedades importantes de uma boa experiência do usuário de blockchain é o tempo de confirmação rápido das transações. Hoje, o Ethereum já melhorou muito em comparação com cinco anos atrás. Graças à combinação de EIP-1559e tempos de bloco estáveis depoisa Fusão, as transações enviadas pelos utilizadores na L1 confirmam de forma fiável dentro de 5-20 segundos. Isto é aproximadamente competitivo com a experiência de pagar com um cartão de crédito. No entanto, há valor em melhorar ainda mais a experiência do utilizador, e existem algumas aplicações que exigem latências da ordem das centenas de milissegundos ou até menos. Este post irá abordar algumas das opções práticas que o Ethereum possui.

Visão geral das ideias e técnicas existentes

Finalidade de slot único

Hoje, o EthereumGaspero consenso usa uma arquitetura de slot e época. A cada slot de 12 segundos, um subconjunto de validadores publica um voto na cabeça da cadeia, e ao longo de 32 slots (6,4 minutos), todos os validadores têm a oportunidade de votar uma vez. Esses votos são então reinterpretados como mensagens de forma vaga semelhante ao PBFTalgoritmo de consenso, que após duas épocas (12,8 min) oferece uma garantia econômica muito difícil chamada finalidade.

Nos últimos anos, tornamo-nos cada vez mais desconfortáveis com a abordagem atual. As principais razões são que (i) é complicado e existem muitos bugs de interação entre o mecanismo de votação slot-by-slot e o mecanismo de finalidade epoch-by-epoch, e (ii) 12,8 minutos é muito longo e ninguém se importa em esperar tanto tempo.

A finalidade de um único slot substitui esta arquitetura por um mecanismo muito mais semelhante aconsenso do Tendermint, em que o bloco N é finalizado antes que o bloco N+1 seja feito. A principal divergência do Tendermint é que mantemos o “vazamento de inatividade"mecanismo, que permite à cadeia continuar e recuperar se mais de 1/3 dos validadores ficarem offline."

Um diagrama do principal propostodesign de finalidade de slot único_

O principal desafio com SSF é que, ingenuamente, parece implicar que cada validador de Ethereum precisaria publicar duas mensagens a cada 12 segundos, o que seria uma carga pesada para a rede lidar. Há ideias inteligentespara como mitigar isso, incluindo o muito recenteOrbit SSFproposta. Mas mesmo assim, embora isso melhore significativamente a UX ao fazer com que a "finalidade" chegue mais rápido, não muda o fato de que os usuários precisam esperar 5-20 segundos.

Pré-confirmações de Rollup

Nos últimos anos, o Ethereum tem seguido um roadmap centrado em rollup, projetando a camada base do Ethereum (o “L1”) em torno do suporte disponibilidade de dadose outras funcionalidades que podem ser usadas por protocolos de camada 2 como rollups(mas tambémvalidiumseplasmas) que pode oferecer aos utilizadores o mesmo nível de segurança do Ethereum, mas a uma escala muito maior.

Isto cria um separação-de-preocupaçõesdentro do ecossistema Ethereum: o Ethereum L1 pode focar em ser resistente à censura, confiável, estável, e manter e melhorar um certo núcleo de funcionalidades de nível base, e os L2s podem focar em alcançar mais diretamente os utilizadores - tanto através de diferentesculturale compensações tecnológicas. Mas se seguir por este caminho, surge inevitavelmente um problema: os L2s querem servir utilizadores que desejam confirmações muito mais rápidas do que 5-20 segundos.

Até agora, pelo menos na retórica, tem sido responsabilidade dos L2s criar suas próprias redes de "sequenciamento descentralizado". Um grupo menor de validadores assinaria os blocos, talvez uma vez a cada poucas centenas de milissegundos, e eles colocariam sua "aposta" por trás desses blocos. Eventualmente, cabeçalhos desses blocos L2 são publicados no L1.

Os conjuntos de validadores L2 poderiam trapacear: primeiro assinariam o bloco B1 e, em seguida, assinariam mais tarde um bloco conflituoso B2 e o comprometeriam na cadeia antes do B1. Mas se fizerem isso, seriam apanhados e perderiam os seus depósitos. Na prática, vimos versões centralizadas disso, mas os rollups têm sido lentos no desenvolvimento de redes de sequenciação descentralizadas. E pode argumentar que exigir que todos os L2 façam a sequenciação descentralizada é um acordo injusto: estamos pedindo aos rollups que basicamente realizem a maior parte do trabalho de criar um novo L1 inteiro. Por esta razão e outras, Justin Drake tem estado a promover uma forma de dar a todos os L2s (bem como ao L1) acesso a um mecanismo de pré-confirmação partilhado em toda a Ethereum:baseado em pré-confirmações.

Baseado em pré-confirmações

A abordagem de pré-confirmação baseada pressupõe que os proponentes do Ethereum se tornarão atores altamente sofisticados por razões relacionadas ao MEV (veja aquipara a minha explicação de MEV e veja também obilhetes de execuçãolinha de propostas). A abordagem baseada na pré-confirmação aproveita essa sofisticação ao incentivar esses proponentes sofisticados a aceitar a responsabilidade de oferecer pré-confirmações como serviço.

A ideia básica é criar um protocolo padronizado pelo qual um usuário pode oferecer uma taxa adicional em troca de uma garantia imediata de que a transação será incluída no próximo bloco, juntamente com possivelmente uma reivindicação sobre os resultados da execução dessa transação. Se o proponente violar qualquer promessa que fizer a qualquer usuário, ele pode ser penalizado.

Como descrito, as pré-confirmações baseadas fornecem garantias às transações L1. Se os rollups estiverem com base, então todos os blocos L2 são transações L1, e assim o mesmo mecanismo pode ser usado para fornecer pré-confirmações para qualquer L2.

O que estamos realmente a olhar aqui?

Suponhamos que implementemos finalidade de slot único. Usamos Órbitatécnicas semelhantes para reduzir o número de validadores que assinam por slot, mas não demasiado, para que também possamos progredir no objetivo chave de reduzir o mínimo de 32 ETH para apostar. Como resultado, talvez o tempo do slot se aproxime, para 16 seg. Em seguida, usamos pré-confirmações de rollup, ou pré-confirmações com base, para dar aos utilizadores garantias mais rápidas. O que temos agora? Uma arquitetura de época e slot.

O meme 'são a mesma imagem' está a ser bastante usado neste momento, por isso vou apenas colocar um antigo diagrama que desenhei há anos para descrever a arquitetura de slot e época do Gasper e um diagrama das pré-confirmações de L2 lado a lado, e espero que isso transmita a ideia.

Existe uma razão filosófica profunda pela qual as arquiteturas de época e slot parecem ser tão difíceis de evitar: inerentemente leva menos tempo para chegar a um acordo aproximado sobre algo, do que para chegar a um acordo de “finalidade econômica” maximamente endurecido sobre isso.

Uma simples razão é o número de nós. Enquanto o antigo linear @VitalikButerin/parametrizando-casper-o-tradeoff-mais-suave-da-descentralização-finalidade-tempo-sobrecarga-3f2011672735">adescentralização / finalidade tempo / tradeoff sobrecarga está parecendo mais suave agora devido à agregação BLS hiper-otimizada e, no futuro próximo, ZK-STARKs, ainda é fundamentalmente verdadeiro que:

1. O "acordo aproximado" só requer alguns nós, enquanto a finalidade econômica requer uma fração significativa de todos os nós.
2. Uma vez que o número de nós ultrapassa um determinado tamanho, você precisa gastar mais tempo para coletar assinaturas.

No Ethereum hoje, um slot de 12 segundos é dividido em três sub-slots, para (i) publicação e distribuição de blocos, (ii) testemunho, e (iii) agregação de testemunhos. Se a contagem de testemunhas fosse muito menor, poderíamos passar para dois sub-slots e ter um tempo de slot de 8 segundos. Outro fator, e realisticamente maior, é a “qualidade” dos nós. Se também pudéssemos depender de um subconjunto profissionalizado de nós para fazer acordos aproximados (e ainda usar o conjunto completo de validadores para a finalidade), poderíamos plausivelmente reduzir isso para ~2 segundos.

Portanto, parece-me que (i) as arquiteturas de slot e época são obviamente corretas, mas também (ii) nem todas as arquiteturas de slot e época são iguais, e há valor em explorar mais completamente o espaço de design. Em particular, vale a pena explorar opções que não são tão entrelaçadas como Gasper, e onde, em vez disso, há uma separação mais forte de preocupações entre os dois mecanismos.

O que devem os L2s fazer?

Na minha opinião, existem três estratégias razoáveis para as L2s adotarem no momento:

1. Ser “baseado”, tanto tecnologicamente como espiritualmente. Ou seja, otimizam-se para serem condutas de passagem para as propriedades técnicas da camada base do Ethereum e seus valores (alta descentralização, resistência à censura, etc). Na sua forma mais simples, pode pensar nestes rollups como sendo “fragmentos de marca”, mas também podem ser muito mais ambiciosos do que isso e experimentar bastante com novos desenhos de máquinas virtuais e outras melhorias técnicas.
2. Orgulhosamente seja um “servidor com andaime de blockchain”, e tire o melhor proveito disso. Se começar com um servidor e depois adicionar (i) provas de validade STARK para garantir que o servidor está a seguir as regras, (ii) direitos garantidos para o utilizador sair ou forçar transações e possivelmente (iii) liberdade de escolha coletiva, seja através de uma saída em massa coordenada ou através da capacidade de votar para alterar o sequenciador, então já obteve muitos dos benefícios de estar na cadeia, mantendo a maioria das eficiências de um servidor.
3. A abordagem de compromisso: uma cadeia rápida de cem nós, com Ethereum fornecendo interoperabilidade e segurança extras. Este é o roadmap atual de facto de muitos projetos L2.

Para algumas aplicações, (por exemplo, ENS, keystores) , alguns pagamentos), um tempo de bloco de 12 segundos é suficiente. Para essas aplicações que não são, a única solução é uma arquitetura de slot e época. Em todos os três casos, os “épocas” são SSF do Ethereum (talvez possamos retconizar esse acrônimo para significar algo além de “único slot”, por exemplo, poderia ser “Finalidade Segura Rápida”). Mas os “slots” são algo diferente em cada um dos três casos acima:

1. Uma arquitetura de slot e época nativa do Ethereum
2. Pré-confirmações do servidor
3. Preconfirmações do comité

Uma questão chave é, até que ponto podemos fazer algo bom na categoria (1)? Em particular, se ficar realmente bom, então parece que a categoria (3) deixa de ter tanto significado. A categoria (2) sempre existirá, pelo menos porque qualquer coisa “baseada” não funciona para L2s de dados off-chain, como plasmas e validiums. Mas se uma arquitetura de slot e época nativa do Ethereum puder chegar a tempos de 1 segundo de “slot” (ou seja, pré-confirmação), então o espaço para a categoria (3) se torna um pouco menor.

Hoje, estamos longe de ter respostas finais para estas questões. Uma questão chave - quão sofisticados os proponentes de blocos vão se tornar - permanece uma área onde há bastante incerteza. Designs como Orbit SSFsão muito recentes, sugerindo que o espaço de design de designs de slot-and-epoch onde algo como Orbit SSF é a época ainda está bastante inexplorado. Quanto mais opções tivermos, melhor podemos fazer para os utilizadores tanto em L1 como em L2s, e mais podemos simplificar o trabalho dos desenvolvedores L2.

Aviso Legal:

1. Este artigo foi reproduzido a partir de [Vitalik].Encaminhe o Título Original ‘Épocas e slots até o fim: maneiras de dar aos utilizadores Ethereum tempos de confirmação de transação mais rápidos’. Todos os direitos autorais pertencem ao autor original [Vitalik]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa, e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.