Ett mycket viktigt dokument. Låt oss gå igenom detta ett "mål" i taget. Vi börjar med snabba slots och snabb slutgiltighet. Jag förväntar mig att vi kommer att minska slottiden gradvis, t.ex. Jag gillar formeln "sqrt(2) åt gången" (12 -> 8 -> 6 -> 4 > 3 -> 2, även om de två sista stegen är mer spekulativa och bygger på omfattande forskning). Det är möjligt att gå snabbare eller långsammare här; Men den övergripande nivån är att vi ser slottiden som en parameter som vi justerar ner när vi är säkra på att det är säkert, liknande blob-målet. Snabba slots ligger i sin egen riktning högst upp på kartan och verkar egentligen inte koppla till något. Detta beror på att resten av färdplanen är ganska oberoende av slottiden: vi skulle behöva göra ungefär samma saker, oavsett om slottiden är 2 sekunder eller 32 sekunder Det finns dock några korsningsområden. En är förbättringar av p2p. @raulvk har nyligen arbetat på ett optimerat p2p-lager för Ethereum, som använder raderingskodning för att avsevärt förbättra gränsen mellan bandbredd och latens. Grovt uttryckt: i dagens design får varje nod en full blockkropp från flera motgångare och kan ta emot och återutsända den så snart den får den första. Om "bredden" (antalet peers som skickar blocket till dig) är låg, kan en dålig peer fördröja när du får blocket avsevärt. Om bredden är hög blir det mycket onödig dataöverhead. Med erasure-kodning kan du välja en k-of-n-uppsättning, t.ex.: dela varje block i 8 delar så att du med vilka 4 som helst kan återskapa hela blocket. Detta ger dig mycket av redundansfördelarna med hög bredd, utan överhuvud. Vi har statistik som visar att denna arkitektur kan minska blockpropagationstiden i 95:e percentilen avsevärt, vilket gör kortare platser gångbara utan säkerhetskompromisser (förutom ökad protokollkomplexitet, även om prestandavinst i förhållande till kodrader här är ganska fördelaktigt) Ett annat skärningsområde är den mer komplexa slotstrukturen som kommer med ePBS, FOCIL och regeln för snabb bekräftelse. Dessa har viktiga fördelar, men de minskar den säkra latensens max från slot/3 till slot/5. Det pågår forskning för att försöka pipeline saker bättre och minimera förluster (notera också: slottiden är lägre begränsad inte bara av slotlatens, utan också av den fasta kostnaden i ZK:s proverlatens), men det finns vissa kompromisser här. Ett sätt vi undersöker för att kompensera för detta är att ändra till en arkitektur där endast ~256-1024 slumpmässigt utvalda attesters signerar på varje plats. För en fork choice (icke-finaliserande) funktion är detta helt tillräckligt. Det mindre antalet signaturer gör att vi kan ta bort aggregeringsfasen, vilket förkortar platserna. Snabb slutfasthet är mer komplex (det ultimata protokollet är enligt mig enklare än status quo Gasper, men förändringsvägen är komplex). Idag tar finaliteten i genomsnitt 16 minuter (12 sekunder * 32 platser epoker * 2,5 epoker). Målet är att koppla loss slots och finalitet, så att vi kan resonera om båda separat, och vi siktar på att använda en BFT-algoritm med en rundas final (en Minimmit-variant) för att slutföra det. Så sluttidsavslutning kan vara till exempel. 6-16 sek. Eftersom detta är en mycket invasiv uppsättning förändringar är planen att paketera det största steget i varje förändring med en växling av kryptografin, särskilt till signaturer baserade på kvanthash, och till en maximalt STARK-vänlig hash (det finns tre möjliga svar på de senaste Poseidon2-attackerna: (i) öka antalet rundor eller införa andra motåtgärder såsom ett monolitlager, (ii) gå tillbaka till Poseidon1, som är ännu mer lindy än Poseidon2 och inte har några brister, (iii) använda BLAKE3 eller annan maximalt billig "konventionell" hash. Alla undersöks. Dessutom finns det en plan att införa många av dessa förändringar steg för steg, t.ex. "1-epoch-finalitet" betyder att vi justerar den nuvarande konsensusen för att ändra från FFG-liknande slutföring till Minimmit-liknande avslutning. En möjlig sluttidsbana är: 16 min (idag) -> 10m40s (8s slots) -> 6m24s (en-epoks finalitet) -> 1m12s (8-slots epoker, 6s slots) -> 48s (4s slots) -> 16s (minimit) -> 8s (minimmit med mer aggressiva parametrar) En intressant konsekvens av det inkrementella tillvägagångssättet är att det finns en väg för att göra platserna kvantresistenta mycket tidigare än att göra finaliteten kvantresistenta, så vi kan mycket väl snabbt komma till ett system där, om kvantdatorer plötsligt dyker upp, förlorar vi slutresultatgarantin, men kedjan fortsätter att fortsätta. Sammanfattning: förvänta dig successiva minskningar av både slottid och sluttid, och förvänta dig att dessa förändringar kommer att vara sammanflätade med en "ship of Theseus"-liknande komponent-för-komponent-ersättning av Ethereums slotstruktur och konsensus med ett renare, enklare, kvantresistent, provvänligt och end-to-end formellt verifierat alternativ.