Ein sehr wichtiges Dokument. Lassen Sie uns dieses "Ziel" Schritt für Schritt durchgehen. Wir beginnen mit schnellen Slots und schneller Finalität. Ich erwarte, dass wir die Slot-Zeit schrittweise reduzieren, z. B. gefällt mir die Formel "sqrt(2) auf einmal" (12 -> 8 -> 6 -> 4 -> 3 -> 2, obwohl die letzten beiden Schritte spekulativer sind und von intensiver Forschung abhängen). Es ist möglich, hier schneller oder langsamer zu werden; aber das hohe Niveau ist, dass wir die Slot-Zeit als Parameter betrachten, den wir nach unten anpassen, wenn wir sicher sind, dass es sicher ist, ähnlich wie beim Blob-Ziel. Schnelle Slots sind in ihrer eigenen Spur ganz oben auf der Roadmap und scheinen sich nicht wirklich mit etwas zu verbinden. Das liegt daran, dass der Rest der Roadmap ziemlich unabhängig von der Slot-Zeit ist: Wir müssten ungefähr die gleichen Dinge tun, egal ob die Slot-Zeit 2 Sekunden oder 32 Sekunden beträgt. Es gibt jedoch einige Schnittstellenbereiche. Eine ist die P2P-Verbesserung. @raulvk hat kürzlich an einer optimierten P2P-Schicht für Ethereum gearbeitet, die Erasure-Coding verwendet, um den Bandbreiten-/Latenzausgleich erheblich zu verbessern. Grob gesagt: Im heutigen Design erhält jeder Knoten einen vollständigen Blockkörper von mehreren Peers und kann ihn akzeptieren und sofort weiterverbreiten, sobald er den ersten erhält. Wenn die "Breite" (Anzahl der Peers, die Ihnen den Block senden) niedrig ist, kann ein schlechter Peer erheblich verzögern, wann Sie den Block erhalten. Wenn die Breite hoch ist, gibt es viel unnötigen Datenüberhead. Mit Erasure-Coding können Sie ein k-of-n-Setup wählen, z. B.: jeden Block in 8 Teile aufteilen, sodass Sie mit beliebigen 4 davon den vollständigen Block rekonstruieren können. Dies gibt Ihnen viele der Redundanzvorteile einer hohen Breite, ohne den Overhead. Wir haben Statistiken, die zeigen, dass diese Architektur die 95. Perzentil-Blockverbreitungszeit erheblich reduzieren kann, wodurch kürzere Slots ohne Sicherheitskompromisse (außer einer erhöhten Protokollkomplexität, obwohl hier das Verhältnis von Leistungsgewinn zu Codezeilen ziemlich günstig ist) möglich werden. Ein weiterer Schnittstellenbereich ist die komplexere Slot-Struktur, die mit ePBS, FOCIL und der schnellen Bestätigungsregel einhergeht. Diese haben wichtige Vorteile, verringern jedoch die maximale sichere Latenz von Slot/3 auf Slot/5. Es gibt laufende Forschungen, um die Dinge besser zu pipelinen, um Verluste zu minimieren (beachten Sie auch: die Slot-Zeit ist nicht nur durch die Slot-Latenz nach unten begrenzt, sondern auch durch den festen Kostenanteil der ZK-Prover-Latenz), aber es gibt hier einige Kompromisse. Eine Möglichkeit, die wir erkunden, um dies auszugleichen, besteht darin, zu einer Architektur zu wechseln, bei der nur ~256-1024 zufällig ausgewählte Attester in jedem Slot unterschreiben. Für eine Fork-Choice (nicht-finalisierende) Funktion ist dies völlig ausreichend. Die kleinere Anzahl von Unterschriften ermöglicht es uns, die Aggregationsphase zu entfernen, wodurch die Slots verkürzt werden. Schnelle Finalität ist komplexer (das endgültige Protokoll ist IMO einfacher als der Status quo Gasper, aber der Änderungsweg ist komplex). Heute dauert die Finalität im Durchschnitt 16 Minuten (12s Slots * 32 Slot-Epochen * 2,5 Epochen). Das Ziel ist es, Slots und Finalität zu entkoppeln, sodass wir über beide separat nachdenken können, und wir zielen darauf ab, einen Ein-Runden-Finalitäts-BFT-Algorithmus (eine Minimmit-Variante) zu verwenden, um zu finalisieren. Die Endspiel-Finalitätszeit könnte also z. B. 6-16 Sekunden betragen. Da dies eine sehr invasive Reihe von Änderungen ist, besteht der Plan darin, den größten Schritt in jeder Änderung mit einem Wechsel der Kryptographie zu bündeln, insbesondere zu post-quanten-sicheren, hash-basierten Signaturen und zu einem maximal STARK-freundlichen Hash (es gibt drei mögliche Reaktionen auf die jüngsten Poseidon2-Angriffe: (i) die Rundenzahl erhöhen oder andere Gegenmaßnahmen wie eine Monolith-Schicht einführen, (ii) zu Poseidon1 zurückkehren, das noch lindy ist als Poseidon2 und keine Mängel aufweist, (iii) BLAKE3 oder andere maximal kostengünstige "konventionelle" Hashes verwenden. Alle werden erforscht). Darüber hinaus gibt es einen Plan, viele dieser Änderungen Stück für Stück einzuführen, z. B. bedeutet "1-Epochen-Finalität", dass wir den aktuellen Konsens anpassen, um von der FFG-Stil-Finalisierung zur Minimmit-Stil-Finalisierung zu wechseln. Ein möglicher Verlauf der Finalitätszeit ist: 16 min (heute) -> 10m40s (8s Slots) -> 6m24s (eine-Epochen-Finalität) -> 1m12s (8-Slot-Epochen, 6s Slots) -> 48s (4s Slots) -> 16s (minimmit) -> 8s (minimmit mit aggressiveren Parametern) Eine interessante Folge des inkrementellen Ansatzes ist, dass es einen Weg gibt, die Slots viel früher quantenresistent zu machen als die Finalität quantenresistent zu machen, sodass wir möglicherweise recht schnell in ein Regime gelangen, in dem, wenn Quantencomputer plötzlich auftauchen, wir die Finalitätsgarantie verlieren, aber die Kette weiterläuft. Zusammenfassung: Erwarten Sie progressive Verringerungen sowohl der Slot-Zeit als auch der Finalitätszeit und erwarten Sie, dass diese Änderungen mit einem "Schiff von Theseus"-Stil komponentenweise Ersetzung der Slot-Struktur und des Konsenses von Ethereum mit einer saubereren, einfacheren, quantenresistenten, proverfreundlichen, end-to-end formal verifizierten Alternative verwoben sind.