Um documento muito importante. Vamos analisar esse "objetivo" de cada vez. Vamos começar com slots rápidos e finalização rápida. Espero que reduzamos o tempo de slot de forma incremental, por exemplo, Gosto da fórmula "sqrt(2) por vez" (12 -> 8 -> 6 -> 4 -> 3 -> 2, embora os dois últimos passos sejam mais especulativos e dependam de pesquisas pesadas). É possível ir mais rápido ou mais devagar aqui; Mas, em geral, vemos o tempo de slot como um parâmetro que ajustamos para baixo quando temos certeza de que é seguro, semelhante ao alvo de blob. Os slots rápidos estão em sua faixa no topo do roadmap e não parecem realmente se conectar a nada. Isso porque o restante do roadmap é bastante independente do tempo de slot: precisaríamos fazer mais ou menos as mesmas coisas, seja de 2 segundos ou 32 segundos Mas há algumas áreas de interseção. Uma delas são melhorias no p2p. @raulvk tem trabalhado recentemente em uma camada p2p otimizada para Ethereum, que utiliza codificação de apagamento para melhorar muito a fronteira entre largura de banda e latência. De forma geral: no design atual, cada nó recebe um corpo de bloco completo de vários pares, e é capaz de aceitá-lo e retransmiti-lo assim que recebe o primeiro. Se a "largura" (número de pares enviando o bloco) for baixa, então um par ruim pode atrasar muito quando você recebe o bloco. Se a largura for alta, há muito sobrecarga desnecessária de dados. Com a codificação de apagamento, você pode escolher uma configuração de k-of-n, por exemplo: dividir cada bloco em 8 partes para que, com quaisquer 4 delas, você possa reconstruir o bloco inteiro. Isso oferece muitos dos benefícios de redundância de alta largura, sem a sobrecarga. Temos estatísticas que mostram que essa arquitetura pode reduzir muito o tempo de propagação do bloco no percentil 95, tornando slots mais curtos viáveis sem concessões de segurança (exceto pela maior complexidade do protocolo, embora aqui a relação ganho de desempenho para linhas de código seja bastante favorável) Outra área de interseção é a estrutura de slot mais complexa que vem com ePBS, FOCIL e a regra de confirmação rápida. Esses têm benefícios importantes, mas diminuem o máximo de latência segura de slot/3 para slot/5. Há pesquisas em andamento para tentar canalizar melhor as coisas para minimizar as perdas (também note que o tempo de slot é limitado não só pela latência do slot, mas também pela parte de custo fixo da latência do provador ZK), mas há alguns tradeoffs aqui. Uma forma que estamos explorando para compensar isso é mudar para uma arquitetura onde apenas ~256-1024 atestados selecionados aleatoriamente assinam em cada slot. Para uma função de escolha de fork (não finalizante), isso é totalmente suficiente. O menor número de assinaturas nos permite remover a fase de agregação, encurtando os espaços. A finalização rápida é mais complexa (o protocolo final é, na minha opinião, mais simples que o status quo Gasper, mas o caminho de mudança é complexo). Hoje, a finalidade leva em média 16 minutos (12s slots * 32 épocas slot * 2,5 épocas). O objetivo é desacoplar os slots e a finalização, então permita-nos raciocinar sobre ambos separadamente, e nosso objetivo é usar um algoritmo BFT de finalização de uma rodada (uma variante do Minimmit) para finalizar. Então, o tempo de finalização final pode ser, por exemplo, 6-16 seg. Como este é um conjunto de mudanças muito invasivo, o plano é agrupar o maior passo de cada mudança com uma mudança da criptografia, notadamente para assinaturas baseadas em hash pós-quântico, e para um hash máximo compatível com STARK (existem três possíveis respostas aos recentes ataques Poseidon2: (i) aumentar a contagem de rodadas ou introduzir outras contramedidas, como uma camada Monolith, (ii) voltar para Poseidon1, que é ainda mais lindy que Poseidon2 e não teve falhas, (iii) usar BLAKE3 ou outro hash "convencional" ao máximo barato. Todos estão sendo pesquisados). Além disso, há um plano para introduzir muitas dessas mudanças aos poucos, por exemplo, "Finalização de 1 época" significa que ajustamos o consenso atual para mudar de finalização no estilo FFG para finalização no estilo Minimmit. Uma trajetória possível de tempo de finalização é: 16 min (hoje) -> 10m40s (slots 8s) -> 6m24s (finalidade de uma época) -> 1m12s (épocas de 8 slots, slots de 6s) -> 48s (slots de 4s) -> 16s (minimmit) -> 8s (minimmit com parâmetros mais agressivos) Uma consequência interessante da abordagem incremental é que existe um caminho para tornar os slots resistentes ao quântico muito antes do que tornar a finalidade resistente ao quântico, então podemos muito bem rapidamente chegar a um regime em que, se computadores quânticos aparecerem de repente, percamos a garantia de finalidade, mas a cadeia continua avançando. Resumo: espere ver diminuições progressivas tanto do tempo de slot quanto do tempo de finalização, e espere que essas mudanças estejam entrelaçadas com uma substituição componente a componente no estilo "ship of Theseus" da estrutura de slot do Ethereum e do consenso por uma alternativa mais limpa, simples, resistente ao quântico, amigável ao provedor e formalmente verificada de ponta a ponta.