Bardzo ważny dokument. Przejdźmy przez to "cel" po "celu". Zaczniemy od szybkich slotów i szybkiej finalizacji. Oczekuję, że zmniejszymy czas slotu w sposób stopniowy, np. podoba mi się formuła "sqrt(2) na raz" (12 -> 8 -> 6 -> 4 -> 3 -> 2, chociaż ostatnie dwa kroki są bardziej spekulacyjne i zależą od intensywnych badań). Możliwe jest, aby iść szybciej lub wolniej; ale na wysokim poziomie będziemy traktować czas slotu jako parametr, który dostosowujemy w dół, gdy będziemy pewni, że jest to bezpieczne, podobnie jak cel blob. Szybkie sloty są w swojej własnej ścieżce na szczycie mapy drogowej i nie wydają się łączyć z niczym. Dzieje się tak, ponieważ reszta mapy drogowej jest dość niezależna od czasu slotu: musielibyśmy robić mniej więcej to samo, niezależnie od tego, czy czas slotu wynosi 2 sekundy, czy 32 sekundy. Są jednak pewne obszary przecięcia. Jednym z nich są ulepszenia p2p. @raulvk ostatnio pracował nad zoptymalizowaną warstwą p2p dla Ethereum, która wykorzystuje kodowanie erasure, aby znacznie poprawić równowagę między przepustowością a opóźnieniem. Mówiąc ogólnie: w dzisiejszym projekcie każdy węzeł otrzymuje pełne ciało bloku od kilku rówieśników i może je zaakceptować i ponownie rozesłać, gdy tylko otrzyma pierwszy. Jeśli "szerokość" (liczba rówieśników wysyłających ci blok) jest niska, to jeden zły rówieśnik może znacznie opóźnić, kiedy otrzymasz blok. Jeśli szerokość jest wysoka, jest dużo niepotrzebnych danych. Dzięki kodowaniu erasure możesz wybrać konfigurację k-of-n, np.: podzielić każdy blok na 8 części, aby z dowolnymi 4 z nich można było odtworzyć pełny blok. Daje to wiele korzyści z redundancji wysokiej szerokości, bez dodatkowego obciążenia. Mamy statystyki, które pokazują, że ta architektura może znacznie zmniejszyć czas propagacji bloku w 95. percentylu, co czyni krótsze sloty wykonalnymi bez kompromisów w zakresie bezpieczeństwa (z wyjątkiem zwiększonej złożoności protokołu, chociaż tutaj stosunek zysku wydajności do linii kodu jest dość korzystny). Innym obszarem przecięcia jest bardziej złożona struktura slotu, która wiąże się z ePBS, FOCIL i zasadą szybkiej finalizacji. Mają one ważne korzyści, ale zmniejszają maksymalne bezpieczne opóźnienie z slot/3 do slot/5. Trwają badania, aby spróbować lepiej zorganizować rzeczy, aby zminimalizować straty (zauważ również: czas slotu jest ograniczony nie tylko przez opóźnienie slotu, ale także przez stały koszt opóźnienia ZK prover), ale są tu pewne kompromisy. Jednym ze sposobów, które badamy, aby to zrekompensować, jest zmiana architektury, w której tylko ~256-1024 losowo wybranych attesterów podpisuje każdy slot. Dla funkcji wyboru fork (niefinalizującej) jest to całkowicie wystarczające. Mniejsza liczba podpisów pozwala nam usunąć fazę agregacji, skracając sloty. Szybka finalizacja jest bardziej złożona (ostateczny protokół jest IMO prostszy niż obecny Gasper, ale ścieżka zmiany jest złożona). Dziś finalizacja zajmuje średnio 16 minut (12s sloty * 32 epoki slotów * 2,5 epoki). Celem jest oddzielenie slotów i finalizacji, aby umożliwić nam rozważenie obu osobno, a naszym celem jest użycie algorytmu BFT o finalizacji w jednej rundzie (wariant Minimmit) do finalizacji. Tak więc czas finalizacji w końcowej grze może wynosić np. 6-16 sek. Ponieważ jest to bardzo inwazyjny zestaw zmian, plan polega na połączeniu największego kroku w każdej zmianie z przełączeniem kryptografii, w szczególności na podpisy oparte na haszach odpornych na kwanty, oraz na maksymalnie przyjaznym dla STARK haszu (są trzy możliwe odpowiedzi na ostatnie ataki Poseidon2: (i) zwiększenie liczby rund lub wprowadzenie innych środków zaradczych, takich jak warstwa Monolith, (ii) powrót do Poseidon1, który jest jeszcze bardziej lindy niż Poseidon2 i nie miał wad, (iii) użycie BLAKE3 lub innego maksymalnie taniego "konwencjonalnego" hasha. Wszystkie są badane). Dodatkowo planuje się wprowadzenie wielu z tych zmian kawałek po kawałku, np. "finalizacja 1-epokowa" oznacza, że dostosowujemy obecny konsensus, aby zmienić z finalizacji w stylu FFG na finalizację w stylu Minimmit. Jedna możliwa trajektoria czasu finalizacji to: 16 min (dziś) -> 10m40s (8s sloty) -> 6m24s (finalizacja jednego epokowego) -> 1m12s (8-epokowe sloty, 6s sloty) -> 48s (4s sloty) -> 16s (minimmit) -> 8s (minimmit z bardziej agresywnymi parametrami). Jedną interesującą konsekwencją podejścia stopniowego jest to, że istnieje ścieżka do uczynienia slotów odpornymi na kwanty znacznie szybciej niż uczynienie finalizacji odporną na kwanty, więc możemy dość szybko dojść do sytuacji, w której, jeśli komputery kwantowe nagle się pojawią, tracimy gwarancję finalizacji, ale łańcuch nadal działa. Podsumowanie: oczekuj stopniowego zmniejszenia zarówno czasu slotu, jak i czasu finalizacji, i oczekuj, że te zmiany będą splecione z "statkiem Tezeusza" w stylu komponent po komponencie, zastępując strukturę slotów Ethereum i konsensus na czystszy, prostszy, odporny na kwanty, przyjazny dla proverów, formalnie weryfikowany alternatywę.