Een zeer belangrijk document. Laten we dit stap voor stap doorlopen, "doel" voor "doel". We beginnen met snelle slots en snelle finaliteit. Ik verwacht dat we de slottijd geleidelijk zullen verkorten, bijvoorbeeld: ik hou van de formule "sqrt(2) per keer" (12 -> 8 -> 6 -> 4 -> 3 -> 2, hoewel de laatste twee stappen meer speculatief zijn en afhankelijk van uitgebreid onderzoek). Het is mogelijk om hier sneller of langzamer te gaan; maar het hoge niveau is dat we de slottijd beschouwen als een parameter die we verlagen wanneer we zeker weten dat het veilig is, vergelijkbaar met het blobdoel. Snelle slots bevinden zich in hun eigen lane bovenaan de roadmap en lijken niet echt met iets verbonden te zijn. Dit komt omdat de rest van de roadmap vrij onafhankelijk is van de slottijd: we zouden ongeveer dezelfde dingen moeten doen, ongeacht of de slottijd 2 seconden of 32 seconden is. Er zijn echter een paar intersectiegebieden. Een daarvan is p2p-verbeteringen. @raulvk heeft onlangs gewerkt aan een geoptimaliseerde p2p-laag voor Ethereum, die gebruik maakt van erasure coding om de bandbreedte/latenstijd trade-off aanzienlijk te verbeteren. Grofweg gezegd: in het ontwerp van vandaag ontvangt elke node een volledige bloklichaam van verschillende peers en kan het deze accepteren en opnieuw uitzenden zodra het de eerste ontvangt. Als de "breedte" (aantal peers dat je het blok stuurt) laag is, kan één slechte peer de tijd vertragen wanneer je het blok ontvangt. Als de breedte hoog is, is er veel onnodige data overhead. Met erasure coding kun je een k-of-n setup kiezen, bijvoorbeeld: split elk blok in 8 stukken zodat je met elk van de 4 ervan het volledige blok kunt reconstrueren. Dit geeft je veel van de redundantievoordelen van hoge breedte, zonder de overhead. We hebben statistieken die aantonen dat deze architectuur de 95e percentiel blokpropagatie tijd aanzienlijk kan verminderen, waardoor kortere slots haalbaar zijn zonder beveiligingscompromissen (behalve verhoogde protocolcomplexiteit, hoewel hier de prestatiewinst ten opzichte van het aantal regels code behoorlijk gunstig is). Een ander intersectiegebied is de complexere slotstructuur die komt met ePBS, FOCIL en de snelle bevestigingsregel. Deze hebben belangrijke voordelen, maar ze verlagen de veilige latentie maximum van slot/3 naar slot/5. Er is lopend onderzoek om te proberen dingen beter te pipelinen om verliezen te minimaliseren (let ook op: de slottijd is niet alleen ondergrens door slotlatentie, maar ook door het vaste kostenonderdeel van ZK prover latentie), maar er zijn hier enkele trade-offs. Een manier waarop we verkennen om dit te compenseren is door over te schakelen naar een architectuur waarbij slechts ~256-1024 willekeurig geselecteerde attesters op elke slot ondertekenen. Voor een fork choice (niet-finaliserende) functie is dit totaal voldoende. Het kleinere aantal handtekeningen stelt ons in staat om de aggregatiefase te verwijderen, waardoor de slots korter worden. Snelle finaliteit is complexer (het uiteindelijke protocol is IMO eenvoudiger dan de huidige Gasper, maar het wijzigingspad is complex). Vandaag de dag duurt finaliteit gemiddeld 16 minuten (12s slots * 32 slot epochs * 2.5 epochs). Het doel is om slots en finaliteit los te koppelen, zodat we over beide afzonderlijk kunnen redeneren, en we zijn van plan om een one-round-finality BFT-algoritme (een Minimmit-variant) te gebruiken om te finaliseren. Dus de eindgame finaliteitstijd zou bijvoorbeeld 6-16 seconden kunnen zijn. Omdat dit een zeer ingrijpende set veranderingen is, is het plan om de grootste stap in elke verandering te bundelen met een wijziging van de cryptografie, met name naar post-kwantum hash-gebaseerde handtekeningen, en naar een maximaal STARK-vriendelijk hash (er zijn drie mogelijke reacties op de recente Poseidon2-aanvallen: (i) verhoog het aantal rondes of introduceer andere tegenmaatregelen zoals een Monolith-laag, (ii) ga terug naar Poseidon1, dat nog meer lindy is dan Poseidon2 en geen gebreken heeft gezien, (iii) gebruik BLAKE3 of andere maximaal goedkope "conventionele" hash. Alle worden onderzocht). Bovendien is er een plan om veel van deze veranderingen stuk voor stuk in te voeren, bijvoorbeeld: "1-epoch finaliteit" betekent dat we de huidige consensus aanpassen om van FFG-stijl finalisatie naar Minimmit-stijl finalisatie te veranderen. Een mogelijke finaliteitstijdtraject is: 16 min (vandaag) -> 10m40s (8s slots) -> 6m24s (one-epoch finaliteit) -> 1m12s (8-slot epochs, 6s slots) -> 48s (4s slots) -> 16s (minimmit) -> 8s (minimmit met agressievere parameters). Een interessant gevolg van de incrementele aanpak is dat er een pad is om de slots veel eerder kwantum-resistent te maken dan de finaliteit kwantum-resistent te maken, dus we kunnen vrij snel in een regime komen waarin, als kwantumcomputers plotseling verschijnen, we de finaliteitsgarantie verliezen, maar de keten blijft doorgaan. Samenvatting: verwacht progressieve afnames van zowel slottijd als finaliteitstijd, en verwacht dat deze veranderingen verweven zullen zijn met een "schip van Theseus"-stijl component-voor-component vervanging van Ethereum's slotstructuur en consensus met een schoner, eenvoudiger, kwantum-resistent, prover-vriendelijk, end-to-end formeel geverifieerd alternatief.