*Encaminhe o título original 'Épocas e slots até o fim: maneiras de dar aos usuários do Ethereum tempos de confirmação de transação mais rápidos'

Uma das propriedades importantes de uma boa experiência do usuário em 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-1559 e tempos de bloco estáveis após a Fusão, as transações enviadas pelos utilizadores em 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, existe 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 artigo irá abordar algumas das opções práticas que o Ethereum tem.

Visão geral de ideias e técnicas existentes

Finalidade de slot único

Hoje, Ethereum’sGaspero 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 chance de votar uma vez. Esses votos são então reinterpretados como mensagens de forma vagasemelhante ao PBFTalgoritmo de consenso, que após duas épocas (12,8 min) oferece uma garantia econômica muito difícil chamada finalidade.

Ao longo dos últimos anos, temos ficado 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 é tempo demais e ninguém se importa de esperar tanto tempo.

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

Um diagrama da principal propostadesign de finalidade de um único slot_

O principal desafio com o SSF é que, ingenuamente, parece implicar que cada staker Ethereum precisaria publicar duas mensagens a cada 12 segundos, o que seria muita carga para a cadeia lidar. Existem ideias inteligentespara saber como mitigar isso, incluindo o muito recenteOrbit SSFproposta. No entanto, embora isso melhore significativamente a UX tornando a "finalidade" mais rápida, não muda o fato de que os usuários precisam esperar de 5 a 20 segundos.

Pré-confirmações Rollup

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

Isto cria um separação-de-preocupações dentro do ecossistema Ethereum: o Ethereum L1 pode se concentrar em ser resistente à censura, confiável, estável e manter e melhorar um determinado núcleo de funcionalidade de nível básico, e o L2s pode se concentrar em alcançar mais diretamente os usuários - ambos através de diferentes culturale compensações tecnológicas. Mas se você seguir por esse caminho, uma questão inevitável surge: L2s querem atender usuários 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 as 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 a sua “aposta” por trás desses blocos. Eventualmente, os cabeçalhos destes blocos L2 são publicados no L1.

Os conjuntos de validadores L2 poderiam trapacear: eles poderiam primeiro assinar o bloco B1 e, mais tarde, assinar um bloco B2 conflitante e confirmá-lo na cadeia antes de B1. Mas se o fizerem, serão apanhados e perderão os seus depósitos. Na prática, vimos versões centralizadas disso, mas os rollups demoraram a desenvolver redes de sequenciamento descentralizadas. E você pode argumentar que exigir que todos os L2s façam sequenciamento descentralizado é um negócio injusto: estamos pedindo aos rollups que basicamente façam a maior parte do mesmo trabalho que criar um novo L1 inteiro. Por esta razão e outras, Justin Drake tem promovido uma maneira de dar a todos os L2s (bem como L1) acesso a um mecanismo de pré-confirmação compartilhado em todo o Ethereum: pré-confirmações baseadas.

Pré-confirmações baseadas

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 (veraquipara minha explicação de MEV, e veja também o Bilhetes de execuçãolinha de propostas). A abordagem baseada na pré-confirmação aproveita essa sofisticação, incentivando esses proponentes sofisticados a aceitar a responsabilidade de oferecer pré-confirmações como um serviço.

A ideia básica é criar um protocolo padronizado pelo qual um usuário possa 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 declaração sobre os resultados da execução dessa transação. Se o proponente violar qualquer promessa que faça a qualquer usuário, ele poderá ser penalizado.

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

O que estamos realmente a olhar aqui?

Suponha que implementemos a finalidade de um único slot. Usamos Órbita-like técnicas para reduzir o número de validadores a assinar por slot, mas não demasiado, para que também possamos progredir no objetivo chave de reduzir o mínimo de 32 ETH para staking. Como resultado, talvez o tempo do slot aumente para 16 segundos. Em seguida, usamos pré-confirmações de rollup ou pré-confirmações baseadas para dar aos utilizadores garantias mais rápidas. O que temos agora? Uma arquitetura de época e slot.

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

Há uma profunda razão filosófica 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/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">descentralização / tempo de finalidade / overhead tradeoff está parecendo mais suave agora devido à agregação BLS hiperotimizada e no futuro próximo ZK-STARKs, ainda é fundamentalmente verdade que:

1. Apenas "acordo aproximado" 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 certo tamanho, é necessário gastar mais tempo para reunir assinaturas.

No Ethereum hoje, um intervalo de 12 segundos é dividido em três subintervalos, para (i) publicação e distribuição de blocos, (ii) atestação e (iii) agregação de atestação. Se o número de atestadores fosse muito menor, poderíamos reduzir para dois subintervalos e ter um tempo de intervalo de 8 segundos. Outro fator, e realisticamente maior, é a “qualidade” dos nós. Se também pudéssemos contar com 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 para ~2 segundos.

Assim, 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 criadas iguais, e há valor em explorar mais completamente o espaço de design. Em particular, vale a pena explorar opções que não estão fortemente entrelaçadas como Gasper, e onde, em vez disso, há uma separação mais forte de preocupações entre os dois mecanismos.

O que os L2s devem fazer?

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

1. Ser “baseado”, tanto tecnologicamente como espiritualmente. Ou seja, eles otimizam para serem condutos de passagem para as propriedades técnicas e valores da camada de base do Ethereum (alta descentralização, resistência à censura, etc). Em sua forma mais simples, você poderia pensar nesses rollups como sendo “shards com marca”, mas eles também podem ser muito mais ambiciosos do que isso e experimentar bastante com novos designs de máquinas virtuais e outras melhorias técnicas.
2. Orgulhosamente seja um 'servidor com esqueleto de blockchain' e tire o melhor proveito disso. Se você começar a partir de um servidor e adicionar (i) provas de validade STARK para garantir que o servidor esteja seguindo as regras, (ii) direitos garantidos para o usuário sair ou forçar transações e possivelmente (iii) liberdade de escolha coletiva, seja por meio de uma saída em massa coordenada ou por meio da capacidade de votar para alterar o sequenciador, você já obteve muitos dos benefícios de estar onchain, mantendo a maioria das eficiências de um servidor.
3. A abordagem de compromisso: uma cadeia rápida de cem nós, com o Ethereum fornecendo interoperabilidade e segurança adicionais. Este é o roteiro 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 retcon esse acrônimo para significar algo além de “single slot”, por exemplo, poderia ser “Segurança Velocidade Finalidade”). 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. Comitê de pré-confirmações

Uma questão-chave é, até que ponto podemos fazer algo de 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á, no mínimo porque qualquer coisa “baseada” não funciona para L2s de dados fora da cadeia, 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 essas perguntas. Uma pergunta chave - quão sofisticados os proponentes de blocos vão se tornar - continua sendo uma área onde há bastante incerteza. Designs como Orbit SSFsão muito recentes, o que sugere que o espaço de design de designs de slot e épocas onde algo como Orbit SSF é a época ainda está bastante inexplorado. Quanto mais opções tivermos, melhor poderemos fazer para os usuários tanto na L1 como na L2, e mais poderemos simplificar o trabalho dos desenvolvedores da L2.

Isenção de responsabilidade:

1. Este artigo é reproduzido a partir de [vitalik]. Encaminhe o título original 'Épocas e slots até o fim: maneiras de dar aos usuários do 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 oGate Learnequipa e eles vão tratar disso prontamente.
2. Responsabilidade de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são realizadas pela equipe da Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.