Um documento muito importante. Vamos percorrer este "objetivo" um de cada vez. Começaremos com slots rápidos e finalidade rápida. Espero que possamos reduzir o tempo de slot de forma incremental, por exemplo, gosto da fórmula "sqrt(2) de cada vez" (12 -> 8 -> 6 -> 4 -> 3 -> 2, embora os dois últimos passos sejam mais especulativos e dependam de uma pesquisa intensa). É possível ir mais rápido ou mais devagar aqui; mas a ideia geral é que veremos o tempo de slot como um parâmetro que ajustamos para baixo quando estamos confiantes de que é seguro fazê-lo, semelhante ao alvo de blob. Os slots rápidos estão em sua própria via no topo do roteiro e não parecem realmente se conectar a nada. Isso se deve ao fato de que o resto do roteiro é bastante independente do tempo de slot: precisaríamos fazer mais ou menos as mesmas coisas, quer o tempo de slot seja 2 segundos ou 32 segundos. No entanto, há algumas áreas de interseção. Uma delas são as melhorias p2p. @raulvk tem trabalhado recentemente em uma camada p2p otimizada para Ethereum, que utiliza codificação de apagamento para melhorar muito a fronteira de troca de largura de banda/latência. De forma geral: no design atual, cada nó recebe um corpo de bloco completo de vários pares e pode 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á um grande overhead de dados desnecessários. Com a codificação de apagamento, você pode escolher uma configuração k-of-n, por exemplo: dividir cada bloco em 8 partes para que, com qualquer 4 delas, você possa reconstruir o bloco completo. Isso lhe dá muitos dos benefícios de redundância de alta largura, sem o overhead. 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 compromissos de segurança (exceto o aumento da 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. Estas 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 as coisas melhor para minimizar perdas (note também: o tempo de slot é limitado inferiormente não apenas pela latência do slot, mas também pela parte de custo fixo da latência do provador ZK), mas há alguns compromissos aqui. Uma maneira que estamos explorando para compensar isso é mudar para uma arquitetura onde apenas ~256-1024 atestadores selecionados aleatoriamente assinam em cada slot. Para uma função de escolha de fork (não finalizadora), isso é totalmente suficiente. O menor número de assinaturas nos permite remover a fase de agregação, encurtando os slots. A finalidade rápida é mais complexa (o protocolo final é IMO mais simples do que o Gasper atual, mas o caminho de mudança é complexo). Hoje, a finalidade leva em média 16 minutos (12s slots * 32 épocas de slot * 2,5 épocas). O objetivo é desacoplar slots e finalidade, permitindo-nos raciocinar sobre ambos separadamente, e estamos visando usar um algoritmo BFT de finalidade de uma rodada (uma variante Minimmit) para finalizar. Assim, o tempo de finalidade do jogo final pode ser, por exemplo, de 6 a 16 segundos. Como este é um conjunto de mudanças muito invasivas, o plano é agrupar o maior passo em cada mudança com uma troca da criptografia, notavelmente para assinaturas baseadas em hash pós-quânticas, e para um hash maximamente amigável ao STARK (há 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 do que Poseidon2 e não apresentou falhas, (iii) usar BLAKE3 ou outro hash "convencional" maximamente barato. Todos estão sendo pesquisados). Além disso, há um plano para introduzir muitas dessas mudanças peça por peça, por exemplo, "finalidade de 1-época" significa que ajustamos o consenso atual para mudar de finalização no estilo FFG para finalização no estilo Minimmit. Uma possível trajetória de tempo de finalidade é: 16 min (hoje) -> 10m40s (slots de 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 há um caminho para tornar os slots resistentes a quânticos muito mais cedo do que tornar a finalidade resistente a quânticos, então podemos rapidamente chegar a um regime onde, se computadores quânticos aparecerem de repente, perdemos a garantia de finalidade, mas a cadeia continua funcionando. Resumo: espere ver diminuições progressivas tanto no tempo de slot quanto no tempo de finalidade, e espere ver essas mudanças entrelaçadas com uma substituição componente por componente no estilo "navio de Teseu" da estrutura de slot e consenso do Ethereum por uma alternativa mais limpa, simples, resistente a quânticos, amigável ao provador e formalmente verificada de ponta a ponta.