Un document foarte important. Hai să parcurgem acest "obiectiv" pe rând. Vom începe cu sloturi rapide și finalitate rapidă. Mă aștept să reducem timpul de slot într-un mod incremental, de exemplu. Îmi place formula "sqrt(2) pe rând" (12 -> 8 -> 6 -> 4 -> 3 -> 2, deși ultimii doi pași sunt mai speculativi și depind de cercetări ample). Este posibil să mergi mai repede sau mai încet aici; Dar, la nivel general, vom vedea timpul de slot ca pe un parametru pe care îl ajustăm în jos când suntem siguri că este sigur, similar cu ținta de blob. Sloturile rapide sunt pe o bandă separată în partea de sus a hărții și nu par să se conecteze cu nimic. Acest lucru se datorează faptului că restul planului este destul de independent de timpul de interval: ar trebui să facem cam aceleași lucruri, indiferent dacă timpul de slot este de 2 secunde sau de 32 de secunde Totuși, există câteva zone de intersecție. Unul este îmbunătățirea p2p. @raulvk a lucrat recent la un strat p2p optimizat pentru Ethereum, care folosește codare de ștergere pentru a îmbunătăți semnificativ frontiera compromisului lățime de bandă și latență. Pe scurt: în designul actual, fiecare nod primește un corp de bloc complet de la mai mulți colegi și poate accepta și retransmite acest nod imediat ce primește primul. Dacă "lățimea" (numărul de peer-uri care îți trimit blocul) este mică, atunci un peer defect poate întârzia mult când primești blocul. Dacă lățimea este mare, există multă suprasolicitare inutilă a datelor. Cu codarea de ștergere, poți alege o configurație k-of-n, de exemplu: împarte fiecare bloc în 8 bucăți astfel încât, cu oricare dintre 4, poți reconstrui blocul întreg. Acest lucru îți oferă multe dintre beneficiile de redundanță ale lățimii mari, fără costuri suplimentare. Avem statistici care arată că această arhitectură poate reduce semnificativ timpul de propagare a blocurilor în percentila 95, făcând sloturile mai scurte viabile fără compromisuri de securitate (cu excepția complexității crescute a protocolului, deși aici raportul câștig performanță-linii de cod este destul de favorabil) O altă zonă de intersecție este structura mai complexă a fantei, care vine cu ePBS, FOCIL și regula de confirmare rapidă. Acestea au beneficii importante, dar reduc latența maximă sigură de la slot/3 la slot/5. Există cercetări în curs pentru a încerca să gestionăm mai bine lucrurile în pipeline pentru a minimiza pierderile (de asemenea, rețineți: timpul de slot este limitat mai jos nu doar de latența slotului, ci și de partea cu cost fix a latenței proverului ZK), dar există unele compromisuri aici. O modalitate pe care o explorăm pentru a compensa acest lucru este să trecem la o arhitectură în care doar ~256-1024 atestatori selectați aleatoriu semnează pe fiecare slot. Pentru o funcție de alegere a fork-ului (nefinalizantă), acest lucru este perfect suficient. Numărul mai mic de semnături ne permite să eliminăm faza de agregare, scurtând astfel sloturile. Finalitatea rapidă este mai complexă (protocolul final este, după părerea mea, mai simplu decât Gasper în status quo, dar calea schimbării este complexă). Astăzi, finalitatea durează în medie 16 minute (12 sloturi * 32 epoci slot * 2,5 epoci). Scopul este să decuplăm sloturile de finalitate, așa că permiteți-ne să discutăm ambele separat, iar noi ne propunem să folosim un algoritm BFT cu finalitate într-o rundă (o variantă Minimmit) pentru finalizare. Deci momentul finalului de final ar putea fi, de exemplu, 6-16 secunde. Deoarece acesta este un set foarte invaziv de schimbări, planul este să se combine cel mai mare pas din fiecare schimbare cu o comutare a criptografiei, în special către semnături bazate pe hash post-cuantic, și către un hash maxim prietenos cu STARK-ul (există trei posibile răspunsuri la atacurile recente Poseidon2: (i) creșterea numărului de runde sau introducerea altor contramăsuri precum un strat Monolit, (ii) să se întoarcă la Poseidon1, care este chiar mai lindy decât Poseidon2 și nu a avut defecte, (iii) să folosească BLAKE3 sau alt hash "convențional" maxim ieftin. Toate sunt în curs de cercetare). În plus, există un plan de a introduce multe dintre aceste schimbări pas cu pas, de exemplu. "Finalitatea unei 1 epoci" înseamnă că ajustăm consensul actual pentru a trece de la finalizarea în stil FFG la finalizarea în stil Minimmit. O posibilă traiectorie a timpului de finalitate este: 16 min (astăzi) -> 10m40s (sloturi 8s) -> 6m24s (finalitate de o epocă) -> 1m12s (epoci cu 8 sloturi, sloturi 6s) -> 48s (sloturi 4s) -> 16s (minimmit) -> 8s (minimmit cu parametri mai agresivi) O consecință interesantă a abordării incrementale este că există o cale de a face sloturile rezistente la cuantică mult mai devreme decât să facem finalitatea rezistentă la cuanticitate, așa că am putea ajunge destul de repede la un regim în care, dacă calculatoarele cuantice apar brusc, pierdem garanția de finalitate, dar lanțul continuă să meargă mai departe. Rezumat: așteptați-vă la scăderi progresive atât ale timpului de slot, cât și ale timpului de finalitate, și așteptați-vă ca aceste schimbări să fie împletite cu o înlocuire componentă cu componentă în stil "ship of Theseus" a structurii sloturi Ethereum și consens cu o alternativă mai curată, mai simplă, cuantică, prietenoasă cu prover-ul, verificată formal de la un capăt la altul.