Progresul făcut de @SuccinctLabs și @RiscZero în ceea ce privește demonstrarea în timp real a fost foarte impresionant. QT-ing nu pentru a fi critic, ci pentru că cred că aceste întrebări sunt cu adevărat interesante (și mi-ar plăcea să văd RTP pe Ethereum!). 1. Dovedirea tuturor blocurilor Ethereum istorice în decurs de 12 secunde nu este suficientă pentru a acoperi timpul de probă în cel mai rău caz. Acest lucru este important deoarece există posibile blocaje patologice ("prover-killer") în care se dovedește costul >> costul gazului (dovada costului este o măsură a latenței sau $). Primul pas este dovedirea tuturor blocurilor istorice în 12 secunde. Dar acest lucru nu este suficient. Trebuie să lucrăm pentru a identifica cazurile patologice care nu au apărut încă pe Ethereum. Nu sunt sigur care este programul de costuri pentru SP1, dar ceva de genul unui bloc întreg plin de extcodehash ar putea fi costisitor în termeni de latență. 2. Verificarea formală trebuie să acopere și compilatorul 😱 @argumentxyz avut un articol bun despre frecvența cu care sunt găsite bug-urile compilatorului ( tl; dr există o clasă specifică de "bug-uri de optimizare greșită" care ar putea fi exploatate în zkVM-uri pentru a crea probleme de soliditate. Aceste insecte se găsesc destul de frecvent. @drakefjustin a susținut că putem ocoli acest lucru cu multe implementări zkVM. Dar asta nu funcționează dacă acele zkVM-uri împărtășesc același lanț de instrumente de compilare și sunt vulnerabile la aceleași erori. 3. Nu este necesară dovada la domiciliu Cred că sunt de acord că dovedirea acasă nu este necesară. Ne bazăm deja pe actori extra-protocol, cum ar fi constructorii, pentru a construi blocuri. Garanția pe care ne-o dorim este că *cineva* este întotdeauna disponibil pentru a genera dovezi. Amânarea RTP-ului pentru scenariul WW3 în care toți provers-urile intră offline pare exagerată. Poate că în acest scenariu, Ethereum ar putea reveni implicit la un mod în care limita de gaz scade și blocurile sunt reexecutate mai degrabă verificate cu ZKP-uri. 4. Limita de gaz de 100 de ori mai mare ar putea crea probleme Demonstrarea paralelă ajută cu siguranță, dar sincronizarea este atât de strânsă încât trebuie să luăm în considerare generarea de martori (care nu poate fi paralelizată în multe zkVM-uri) și recursivitatea. Supraîncărcarea de recursivitate ar trebui să se scaleze logaritmic, dar dacă limita de gaz crește de 100x, timpii de verificare ar putea depăși timpii de blocare. Bonus - Aș spune că este foarte important pentru Ethereum să reducă timpii de blocare și timpul până la finalizare, pentru a ajuta utilizatorii să se integreze la L2, să facă punte de la CEX etc. Acest lucru crește cerințele de latență la dovedire. Ar fi suboptim dacă nu am putea trece la blocuri de 1 s, deoarece limita inferioară a latenței RTP în cel mai rău caz este de 10 secunde.