Un documento molto importante. Procediamo con questo "obiettivo" alla volta. Iniziamo con i slot veloci e la finalità rapida. Mi aspetto che ridurremo il tempo di slot in modo incrementale, ad esempio, mi piace la formula "sqrt(2) alla volta" (12 -> 8 -> 6 -> 4 -> 3 -> 2, anche se gli ultimi due passaggi sono più speculativi e dipendono da ricerche approfondite). È possibile andare più veloci o più lenti qui; ma il livello alto è che considereremo il tempo di slot come un parametro che aggiustiamo verso il basso quando siamo certi che sia sicuro farlo, simile all'obiettivo del blob. I slot veloci sono separati nel loro proprio percorso in cima alla roadmap e non sembrano realmente collegarsi a nulla. Questo perché il resto della roadmap è abbastanza indipendente dal tempo di slot: dovremmo fare più o meno le stesse cose che il tempo di slot sia di 2 secondi o di 32 secondi. Ci sono però alcune aree di intersezione. Una è il miglioramento p2p. @raulvk ha recentemente lavorato su un layer p2p ottimizzato per Ethereum, che utilizza la codifica di cancellazione per migliorare notevolmente il compromesso tra larghezza di banda e latenza. Parlando in termini generali: nel design attuale, ogni nodo riceve un corpo di blocco completo da diversi peer e può accettarlo e ritrasmetterlo non appena riceve il primo. Se la "larghezza" (numero di peer che ti inviano il blocco) è bassa, allora un peer cattivo può ritardare notevolmente quando ricevi il blocco. Se la larghezza è alta, c'è un sacco di sovraccarico di dati non necessari. Con la codifica di cancellazione, puoi scegliere un setup k-of-n, ad esempio: suddividere ogni blocco in 8 pezzi in modo che con qualsiasi 4 di essi tu possa ricostruire il blocco completo. Questo ti offre molti dei benefici di ridondanza di alta larghezza, senza il sovraccarico. Abbiamo statistiche che mostrano che questa architettura può ridurre notevolmente il tempo di propagazione del blocco al 95° percentile, rendendo slot più brevi praticabili senza compromessi sulla sicurezza (eccetto l'aumento della complessità del protocollo, anche se qui il rapporto guadagno prestazionale a linee di codice è piuttosto favorevole). Un'altra area di intersezione è la struttura di slot più complessa che viene con ePBS, FOCIL e la regola di conferma rapida. Questi hanno benefici importanti, ma riducono il massimo di latenza sicura da slot/3 a slot/5. Ci sono ricerche in corso per cercare di ottimizzare meglio le cose per minimizzare le perdite (nota anche: il tempo di slot è limitato non solo dalla latenza dello slot, ma anche dalla parte a costo fisso della latenza del provatore ZK), ma ci sono alcuni compromessi qui. Un modo che stiamo esplorando per compensare questo è cambiare a un'architettura in cui solo ~256-1024 attester selezionati casualmente firmano ogni slot. Per una funzione di scelta del fork (non finalizzante), questo è totalmente sufficiente. Il numero minore di firme ci consente di rimuovere la fase di aggregazione, accorciando gli slot. La finalità rapida è più complessa (il protocollo finale è IMO più semplice dello stato attuale di Gasper, ma il percorso di cambiamento è complesso). Oggi, la finalità richiede in media 16 minuti (slot di 12s * 32 epoche di slot * 2.5 epoche). L'obiettivo è disaccoppiare slot e finalità, in modo da permetterci di ragionare su entrambi separatamente, e stiamo puntando a utilizzare un algoritmo BFT a finalità a un giro (una variante di Minimmit) per finalizzare. Quindi il tempo di finalità finale potrebbe essere ad esempio di 6-16 secondi. Poiché questo è un insieme di cambiamenti molto invasivo, il piano è di raggruppare il passo più grande in ciascun cambiamento con un cambio della crittografia, in particolare a firme hash basate su post-quantum, e a un hash massimamente STARK-friendly (ci sono tre possibili risposte agli attacchi recenti di Poseidon2: (i) aumentare il numero di giri o introdurre altre contromisure come un layer Monolith, (ii) tornare a Poseidon1, che è ancora più lindy di Poseidon2 e non ha mostrato difetti, (iii) utilizzare BLAKE3 o altri hash "convenzionali" massimamente economici. Tutti sono in fase di ricerca). Inoltre, c'è un piano per introdurre molti di questi cambiamenti pezzo per pezzo, ad esempio, "finalità a 1 epoca" significa che aggiustiamo il consenso attuale per passare dalla finalizzazione in stile FFG alla finalizzazione in stile Minimmit. Una possibile traiettoria del tempo di finalità è: 16 min (oggi) -> 10m40s (slot di 8s) -> 6m24s (finalità a un'epoca) -> 1m12s (epoche di 8 slot, slot di 6s) -> 48s (slot di 4s) -> 16s (minimmit) -> 8s (minimmit con parametri più aggressivi). Una conseguenza interessante dell'approccio incrementale è che c'è un percorso per rendere gli slot resistenti ai quanti molto prima di rendere la finalità resistente ai quanti, quindi potremmo benissimo arrivare rapidamente a un regime in cui, se i computer quantistici appaiono improvvisamente, perdiamo la garanzia di finalità, ma la catena continua a funzionare. Riepilogo: aspettati di vedere diminuzioni progressive sia del tempo di slot che del tempo di finalità, e aspettati di vedere questi cambiamenti intrecciati con una sostituzione componente per componente in stile "nave di Teseo" della struttura degli slot e del consenso di Ethereum con un'alternativa più pulita, semplice, resistente ai quanti, amichevole per i provatori e formalmente verificata end-to-end.