Un documento muy importante. Vamos a analizar esto "objetivo" por "objetivo". Comenzaremos con los slots rápidos y la finalización rápida. Espero que reduzcamos el tiempo de slot de manera incremental, por ejemplo, me gusta la fórmula "sqrt(2) a la vez" (12 -> 8 -> 6 -> 4 -> 3 -> 2, aunque los dos últimos pasos son más especulativos y dependen de una investigación profunda). Es posible ir más rápido o más lento aquí; pero el nivel alto es que veremos el tiempo de slot como un parámetro que ajustamos hacia abajo cuando estamos seguros de que es seguro hacerlo, similar al objetivo de blob. Los slots rápidos están en su propio carril en la parte superior de la hoja de ruta, y realmente no parecen conectarse a nada. Esto se debe a que el resto de la hoja de ruta es bastante independiente del tiempo de slot: tendríamos que hacer más o menos las mismas cosas, ya sea que el tiempo de slot sea de 2 segundos o de 32 segundos. Sin embargo, hay algunas áreas de intersección. Una es las mejoras p2p. @raulvk ha estado trabajando recientemente en una capa p2p optimizada para Ethereum, que utiliza codificación de borrado para mejorar enormemente la frontera de compensación entre ancho de banda y latencia. Hablando en términos generales: en el diseño actual, cada nodo recibe un cuerpo de bloque completo de varios pares, y puede aceptarlo y retransmitirlo tan pronto como recibe el primero. Si el "ancho" (número de pares que te envían el bloque) es bajo, entonces un par malo puede retrasar mucho cuando recibes el bloque. Si el ancho es alto, hay un montón de datos innecesarios. Con la codificación de borrado, puedes elegir una configuración de k-de-n, por ejemplo: dividir cada bloque en 8 piezas de modo que con cualquiera de ellas puedas reconstruir el bloque completo. Esto te da muchos de los beneficios de redundancia de un alto ancho, sin la sobrecarga. Tenemos estadísticas que muestran que esta arquitectura puede reducir enormemente el tiempo de propagación del bloque en el percentil 95, haciendo que los slots más cortos sean viables sin compromisos de seguridad (excepto por el aumento de la complejidad del protocolo, aunque aquí la relación de ganancia de rendimiento a líneas de código es bastante favorable). Otra área de intersección es la estructura de slot más compleja que viene con ePBS, FOCIL y la regla de confirmación rápida. Estas tienen beneficios importantes, pero disminuyen el máximo de latencia segura de slot/3 a slot/5. Hay una investigación en curso para intentar canalizar las cosas mejor para minimizar las pérdidas (también nota: el tiempo de slot está limitado inferiormente no solo por la latencia de slot, sino también por la parte de costo fijo de la latencia del probador ZK), pero hay algunos compromisos aquí. Una forma en que estamos explorando para compensar esto es cambiar a una arquitectura donde solo ~256-1024 atestadores seleccionados aleatoriamente firmen en cada slot. Para una función de elección de bifurcación (no finalizadora), esto es totalmente suficiente. El menor número de firmas nos permite eliminar la fase de agregación, acortando los slots. La finalización rápida es más compleja (el protocolo final es, en mi opinión, más simple que el Gasper actual, pero el camino de cambio es complejo). Hoy, la finalización toma 16 minutos (12s por slot * 32 épocas de slot * 2.5 épocas) en promedio. El objetivo es desacoplar los slots y la finalización, para permitirnos razonar sobre ambos por separado, y estamos buscando usar un algoritmo BFT de finalización de una ronda (una variante de Minimmit) para finalizar. Así que el tiempo de finalización del juego final podría ser, por ejemplo, de 6 a 16 segundos. Debido a que este es un conjunto de cambios muy invasivo, el plan es agrupar el mayor paso en cada cambio con un cambio de la criptografía, notablemente a firmas basadas en hash post-cuánticas, y a un hash maximamente amigable con STARK (hay tres posibles respuestas a los recientes ataques de Poseidon2: (i) aumentar el número de rondas o introducir otras contramedidas como una capa Monolith, (ii) volver a Poseidon1, que es aún más lindy que Poseidon2 y no ha visto fallos, (iii) usar BLAKE3 u otro hash "convencional" maximamente barato. Todos están siendo investigados). Además, hay un plan para introducir muchos de estos cambios pieza por pieza, por ejemplo, "finalización de 1 época" significa que ajustamos el consenso actual para cambiar de la finalización al estilo FFG a la finalización al estilo Minimmit. Una posible trayectoria de tiempo de finalización es: 16 min (hoy) -> 10m40s (slots de 8s) -> 6m24s (finalización de una época) -> 1m12s (épocas de 8 slots, slots de 6s) -> 48s (slots de 4s) -> 16s (minimmit) -> 8s (minimmit con parámetros más agresivos). Una consecuencia interesante del enfoque incremental es que hay un camino para hacer que los slots sean resistentes a los cuánticos mucho antes que hacer que la finalización sea resistente a los cuánticos, por lo que podríamos llegar rápidamente a un régimen donde, si los ordenadores cuánticos aparecen de repente, perdemos la garantía de finalización, pero la cadena sigue funcionando. Resumen: espera ver disminuciones progresivas tanto en el tiempo de slot como en el tiempo de finalización, y espera ver que estos cambios estén entrelazados con un reemplazo componente por componente al estilo "barco de Teseo" de la estructura de slot y consenso de Ethereum por una alternativa más limpia, simple, resistente a los cuánticos, amigable con los probadores y formalmente verificada de extremo a extremo.