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

Uma das propriedades importantes de uma boa experiência de 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 deEIP-1559e tempos de bloco estáveis apósa Fusão, as transações enviadas pelos usuários no L1 são confirmadas de forma confiável em 5-20 segundos. Isso é 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 usuário, e existem algumas aplicações que exigem latências da ordem de centenas de milissegundos ou até menos. Este post 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, Ethereum'sGaspero consenso usa uma arquitetura de slot e época. A cada 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 vaga semelhante ao PBFTalgoritmo de consenso, que após duas épocas (12,8 minutos) oferece uma garantia econômica muito forte chamada de finalidade.

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

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

Um diagrama do principal propostodesign de finalidade de slot único_

O principal desafio com o SSF é que, de forma ingênua, parece implicar que cada validador do Ethereum precisaria publicar duas mensagens a cada 12 segundos, o que seria uma carga muito grande para a rede lidar. Existem ideias inteligentespara saber 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, Ethereum tem seguido uma roadmap centrado em rollup, projetando a camada base do Ethereum (o “L1”) em torno de dar 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.

Isso cria um separação de preocupaçõesdentro do ecossistema Ethereum: o Ethereum L1 pode se concentrar em ser resistente à censura, confiável, estável e manter e melhorar um certo núcleo de funcionalidade básica, e os L2s podem se concentrar em alcançar mais diretamente os usuários - ambos por meio de diferentesculturale compensações tecnológicas. Mas se você seguir por esse caminho, uma questão inevitável surge: os L2s querem atender aos 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 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” atrás desses blocos. Eventualmente, os cabeçalhos desses 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 fizessem, seriam apanhados e perderiam 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 esse e outros motivos, 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: 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 (ver aquipara minha explicação de MEV e veja também oBilhetes de execução(linha de propostas). A abordagem baseada na pré-confirmação aproveita essa sofisticação incentivando esses proponentes sofisticados a assumir 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, eles podem ter sua participação reduzida.

Conforme descrito, as pré-confirmações com base 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 olhando aqui?

Suponha que implementemos a finalidade de slot único. Nós usamosÓrbitatécnicas -like para reduzir o número de validadores assinando por slot, mas não muito, para que também possamos avançar no objetivo chave de reduzir o mínimo de 32 ETH para aposta. 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 usuários garantias mais rápidas. O que temos agora? Uma arquitetura de época e slot.

O meme "eles são a mesma imagem" está sendo bastante usado neste momento, então eu vou apenas colocar um diagrama antigo que eu desenhei anos atrás para descrever a arquitetura de slot e época de Gasper e um diagrama de pré-confirmações L2 lado a lado, e espero que isso passe a mensagem.

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

Uma razão simples é o número de nós. Enquanto o antigo linear @VitalikButerin/parametrizando-casper-a-troca-de-tradeoff-de-tempo-de-finalidade-de-descentralizacao-está parecendo mais branda agora devido à agregacão BLS hiper-otimizada e, num futuro próximo, ZK-STARKs, ainda é fundamentalmente verdadeiro que:

1. "Acordo aproximado" requer apenas 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 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) atestação e (iii) agregação de atestação. Se o número de atestadores fosse muito menor, poderíamos reduzir 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 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 reduzir isso para ~2 segundos de forma plausível.

Assim, para mim, parece 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 intimamente entrelaçadas como Gasper, e onde 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 no momento:

1. Ser "baseado", tanto tecnologicamente quanto espiritualmente. Ou seja, eles otimizam para serem condutos de passagem para 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ê poderia pensar nesses rollups como sendo "shards de marca", mas eles também podem ser muito mais ambiciosos do que isso e experimentar bastante com novos designs de máquina virtual e outras melhorias técnicas.
2. Orgulhosamente seja um “servidor com estrutura de blockchain” e tire o melhor proveito disso. Se você começar 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 saída em massa coordenada ou por meio da capacidade de votar para mudar o sequenciador, então você 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 o Ethereum fornecendo interoperabilidade e segurança adicionais. Este é o roadmap atual de fato de muitos projetos L2.

Para algumas aplicações, (por exemplo. ENS, keystores) , alguns pagamentos), um tempo de bloco de 12 segundos é suficiente. Para aquelas 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 retroativamente fazer com que esse acrônimo signifique algo diferente de “single slot”, por exemplo, poderia ser “Finalidade Segura e 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. Pré-confirmações do comitê

Uma pergunta-chave é: até que ponto podemos tornar algo bom na categoria (1)? Em particular, se ficar realmente bom, 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 “slot” de 1 segundo (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 questão-chave - quão sofisticados serão os proponentes de bloco - permanece uma área onde há bastante incerteza. Designs like 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 poderemos fazer para os usuários tanto no L1 quanto no L2, e mais poderemos simplificar o trabalho dos desenvolvedores do L2.

Aviso Legal:

1. Este artigo foi reproduzido de [vitalik].Encaminhe o título original 'Épocas e slots até o fim: maneiras de dar aos usuários Ethereum tempos de confirmação de transações mais rápidos'. Todos os direitos autorais pertencem ao autor original [vitalik*]. Se houver objeções a esta reimpressão, entre em contato com oGate Aprenderequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.