Encaminhe o Título Original 'Épocas e slots até o fim: formas de oferecer 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 de blockchain são os tempos de confirmação de transação rápidos. 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 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 requerem latências da ordem de centenas de milissegundos ou até menos. Este post irá abordar algumas das opções práticas que o Ethereum possui.

Visão geral de ideias e técnicas existentes

Finalidade de slot único

Hoje, o Ethereum Gaspero 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 min), 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 min) fornece uma garantia econômica muito forte chamada finalidade.

Nos últimos dois anos, ficamos 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-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 essa arquitetura por um mecanismo muito mais semelhante aconsenso 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 que a cadeia continue funcionando e se recupere se mais de 1/3 dos validadores ficarem offline."

Um diagrama dos principais propostosdesign de finalidade de um único slot_

O principal desafio com SSF é que ingenuamente, parece implicar que cada validador do Ethereum precisaria publicar duas mensagens a cada 12 segundos, o que seria uma carga enorme para a rede lidar. Há ideias inteligentescomo 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 de 5 a 20 segundos.

Preconfirmaçõ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 de suporte disponibilidade de dados e outras funcionalidades que podem então ser usadas por protocolos de camada 2 como rollups (mas também validiums e plasmas) que pode fornecer aos usuários o mesmo nível de segurança do 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 base de funcionalidades, e os L2s podem focar mais diretamente em alcançar os usuários - ambos por meio de diferentescultural e compensações tecnológicas. Mas se você seguir por esse caminho, um problema inevitável surge: os L2s querem atender usuários que querem 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 blocos, talvez uma vez a cada poucas centenas de milissegundos, e colocariam sua 'aposta' por trás desses blocos. Eventualmente, cabeçalhos desses blocos L2 são publicados no L1.

Conjuntos de validadores L2 poderiam trapacear: primeiro poderiam assinar o bloco B1 e, em seguida, assinar posteriormente um bloco conflitante B2 e comprometê-lo na cadeia antes de B1. Mas se fizerem isso, seriam pegos e perderiam seus depósitos. Na prática, vimos versões centralizadas disso, mas as rollups têm sido lentas para desenvolver redes de sequenciamento descentralizadas. E pode-se argumentar que exigir que todos os L2 façam o sequenciamento descentralizado é um acordo injusto: estamos pedindo às rollups para basicamente fazerem a maior parte do trabalho de criar um novo L1 inteiro. Por esse motivo e outros, 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 toda a Ethereum.pré-confirmações com base.

Com base 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 (veraquipara a minha explicação de MEV e veja também obilhetes de execuçãolinha de propostas). A abordagem de pré-confirmação baseada 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 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, poderá ser penalizado.

Conforme descrito, as pré-confirmações baseadas fornecem garantias para 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 olhando aqui?

Suponha que implementamos finalidade de slot único. Nós usamos Órbitatécnicas semelhantes para reduzir o número de validadores que assinam por slot, mas não muito, para que também possamos progredir no objetivo chave de reduzir o mínimo de 32 ETH de stake. Como resultado, talvez o tempo do slot aumente para 16 seg. 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 de “eles são a mesma imagem” está sendo bastante usado neste momento, então vou apenas colocar um diagrama antigo que desenhei anos atrás para descrever a arquitetura de slot e época de Gasper e um diagrama de 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 chegar a um acordo de “finalidade econômica” maximamente fortalecido sobre isso.

Um simples motivo é o número de nós. Enquanto o velho linear @VitalikButerin/parametrizando-casper-a-descentralizacao-finalidade-tempo-tradeoff-3f2011672735">a compensação de descentralização / tempo de finalidade / overhead 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" 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, você precisa 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 bloco, (ii) atestação e (iii) agregação de atestação. Se a contagem de atestadores fosse muito menor, poderíamos reduzir para dois subintervalos e ter um 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 finalização), 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 estão intimamente entrelaçadas como o 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 as L2s adotarem no momento:

1. Seja “baseado”, tanto tecnologicamente quanto espiritualmente. Ou seja, eles otimizam para serem condutos de passagem para as propriedades técnicas e valores da camada base do Ethereum (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áquinas virtuais e outras melhorias técnicas.
2. Orgulhosamente ser um "servidor com andaimes blockchain", e tirar o melhor proveito dele. Se você começar a partir de um servidor e, em seguida, adicionar (i) provas de validade STARK para garantir que o servidor está 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 através da capacidade de votar para mudar o sequenciador, então você já ganhou muitos dos benefícios de estar onchain, mantendo a maior parte 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 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 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 o SSF do Ethereum (talvez possamos recriar esse acrônimo para significar algo diferente de "slot único", 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. Comitê de pré-confirmações

Uma questão chave é, quão bom podemos fazer algo na categoria (1)? Em particular, se ele se tornar 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 fora da cadeia, como plasmas e validiums. Mas se uma arquitetura de slot e época nativa do Ethereum pode 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 os proponentes de bloco vão se tornar - 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 e época onde algo como Orbit SSF é a época ainda é bastante inexplorado. Quanto mais opções tivermos, melhor poderemos fazer para os usuários tanto na L1 quanto na L2, e mais podemos simplificar o trabalho dos desenvolvedores da L2.

Aviso Legal：

1. Este artigo foi republicado de [Vitalik]. Encaminhar 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 este reenvio, por favor entre em contato com o Aprender Gateequipe e eles lidarão com isso prontamente.
2. Isenção 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. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.