Pokrok dosažený @SuccinctLabs a @RiscZero směrem k dokazování v reálném čase byl velmi působivý. QT-ing nechci být kritický, ale protože si myslím, že tyto otázky jsou opravdu zajímavé (a rád bych viděl, jak se RTP dostane na Ethereum!). 1. Prokázání všech historických bloků Etherea do 12 s nestačí k pokrytí nejhoršího možného času proveru. To je důležité, protože existují možné patologické ("prover-killer") bloky, kde prokazování nákladů >> náklady na plyn (prokazování nákladů je měřítkem latence nebo $). Prvním krokem je prokázání všech historických bloků do 12s. To však nestačí. Musíme pracovat na identifikaci patologických případů, které se na Ethereu ještě neobjevily. Nejsem si jistý, jaký je plán nákladů na SP1, ale něco jako celý blok plný extcodehash by mohlo být drahé z hlediska latence. 2. Formální ověření musí také pokrýt kompilátor 😱 Měl @argumentxyz dobrý článek o frekvenci, s jakou jsou nalézány chyby kompilátoru ( tl; dr existuje specifická třída "chybných optimalizačních chyb", které by mohly být potenciálně zneužitelné v zkVMs k vytváření problémů se spolehlivostí. Tyto chyby se vyskytují poměrně často. @drakefjustin tvrdí, že to můžeme obejít mnoha implementacemi zkVM. To však nefunguje, pokud tyto zkVMs sdílejí stejnou sadu nástrojů kompilátoru a jsou zranitelné vůči stejným chybám. 3. Domácí prokazování není potřeba Myslím, že souhlasím s tím, že domácí dokazování není nutné. Při konstrukci bloků se již spoléháme na mimoprotokolové aktéry, jako jsou buildery. Záruka, kterou chceme, je, že *někdo* je vždy k dispozici pro generování důkazů. Odkládání RTP pro scénář 3. světové války, kdy všichni dokazovatelé přejdou do režimu offline, se zdá být přehnané. Možná by se v tomto scénáři Ethereum mohlo vrátit zpět do režimu, kdy se limit plynu snižuje a bloky se znovu provádějí, spíše se ověřují pomocí ZKP. 4. 100x překročení limitu plynu by mohlo způsobit problémy Paralelizované dokazování rozhodně pomáhá, ale načasování je tak těsné, že musíme uvažovat o generování witness (v mnoha zkVMs není paralelizovatelné) a rekurzi. Rekurze by se měla škálovat logaritmicky, ale pokud se limit plynu zvýší 100x, dokazovací časy by mohly překročit časy bloků. Bonus – Tvrdím, že je opravdu důležité, aby Ethereum zkrátilo dobu bloku a dobu do konečnosti, aby pomohlo uživatelům připojit se k L2s, přemostění z CEX atd. To zvyšuje nároky na latenci při dokazování. Bylo by suboptimální, pokud bychom nebyli schopni přejít na 1s blokové časy, protože spodní mez pro nejhorší případ latence RTP je 10s.