Postęp poczyniony przez @SuccinctLabs i @RiscZero w kierunku dowodzenia w czasie rzeczywistym był imponujący. QT nie jest krytyczny, ale dlatego, że uważam, że te pytania są naprawdę interesujące (i chciałbym, aby RTP uderzyło w Ethereum!). 1. Udowodnienie wszystkich historycznych bloków Ethereum w ciągu 12 sekund nie wystarczy, aby pokryć najgorszy możliwy czas. Jest to ważne, ponieważ możliwe są patologiczne ("prover-killer") bloki, w których koszt udowodnienia >> koszt gazu (koszt udowodnienia jest miarą opóźnienia lub $). Pierwszym krokiem jest udowodnienie wszystkich historycznych bloków w ciągu 12 sekund. Ale to nie wystarczy. Musimy pracować nad zidentyfikowaniem patologicznych przypadków, które jeszcze nie pojawiły się na Ethereum. Nie jestem pewien, jaki jest harmonogram kosztów dla SP1, ale coś takiego jak cały blok pełen extcodehash może być kosztowne pod względem opóźnień. 2. Weryfikacja formalna musi również obejmować kompilator 😱 @argumentxyz miał dobry artykuł na temat częstotliwości, z jaką znajdowane są błędy kompilatora ( tl; dr istnieje specyficzna klasa "błędów optymalizacji", które mogą być potencjalnie wykorzystane w zkVMs w celu stworzenia problemów z dźwiękiem. Te błędy są znajdowane dość często. @drakefjustin twierdzi, że możemy obejść ten problem za pomocą wielu implementacji zkVM. Ale to nie działa, jeśli te zkVM współużytkują ten sam łańcuch narzędzi kompilatora i są podatne na te same błędy. 3. Udowadnianie w domu nie jest potrzebne Myślę, że zgadzam się, że udowadnianie w domu nie jest konieczne. Już teraz polegamy na aktorach pozaprotokołowych, takich jak konstruktorzy, którzy konstruują bloki. Gwarancją, której oczekujemy, jest to, że *ktoś* jest zawsze dostępny, aby wygenerować dowody. Odraczanie RTP dla scenariusza WW3, w którym wszystkie dowody przechodzą w tryb offline, wydaje się przesadą. Być może w tym scenariuszu Ethereum mogłoby domyślnie powrócić do trybu, w którym limit gazu maleje, a bloki są ponownie wykonywane, a nie weryfikowane za pomocą ZKP. 4. 100-krotne przekroczenie limitu gazu może powodować problemy Dowodzenie równoległe zdecydowanie pomaga, ale czas jest tak napięty, że musimy wziąć pod uwagę generowanie świadków (nierównoległe w wielu zkVMs) i rekurencję. Narzut rekurencji powinien skalować się logarytmicznie, ale jeśli limit gazu wzrośnie 100-krotnie, czasy dowodzenia mogą przekroczyć czasy bloków. Bonus - Uważam, że dla Ethereum bardzo ważne jest skrócenie czasu bloku i czasu do jego ostateczności, aby pomóc użytkownikom w dostosowaniu się do L2, mostkach z CEX-ów itp. Zwiększa to wymagania dotyczące opóźnień podczas udowadniania. Byłoby nieoptymalnie, gdybyśmy nie byli w stanie przejść do czasów bloku 1 s, ponieważ dolna granica opóźnienia RTP w najgorszym przypadku wynosi 10 sekund.