I progressi compiuti da @SuccinctLabs e @RiscZero verso la dimostrazione in tempo reale sono stati davvero impressionanti. Il QT non è per essere critico, ma perché penso che queste domande siano davvero interessanti (e mi piacerebbe vedere l'RTP colpire Ethereum!). 1. Dimostrare tutti i blocchi storici di Ethereum entro 12 secondi non è sufficiente per coprire il tempo di prova peggiore. Questo è importante perché ci sono possibili blocchi patologici ("prover-killer") in cui il costo di prova >> il costo del gas (il costo di prova è una misura della latenza o $). Il primo passo è dimostrare tutti i blocchi storici entro 12s. Ma questo non basta. Bisogna lavorare per identificare i casi patologici che non si sono ancora manifestati su Ethereum. Non sono sicuro di quale sia il programma dei costi per SP1, ma qualcosa come un intero blocco pieno di extcodehash potrebbe essere costoso in termini di latenza. 2. La verifica formale deve riguardare anche il compilatore 😱 @argumentxyz pubblicato un buon articolo sulla frequenza con cui vengono rilevati i bug del compilatore ( tl; Esiste una classe specifica di "bug di ottimizzazione errata" che potrebbero potenzialmente essere sfruttabili nelle zkVM per creare problemi di solidità. Questi bug vengono rilevati abbastanza frequentemente. @drakefjustin ha sostenuto che possiamo aggirare questo problema con molte implementazioni di zkVM. Ma questo non funziona se quelle zkVM condividono la stessa toolchain del compilatore e sono vulnerabili agli stessi bug. 3. La lievitazione a casa non è necessaria Penso di essere d'accordo sul fatto che la lievitazione a casa non sia necessaria. Ci affidiamo già ad attori extra-protocollo come i costruttori per costruire blocchi. La garanzia che vogliamo è che *qualcuno* sia sempre disponibile a generare bozze. Posticipare l'RTP per lo scenario WW3 in cui tutti i dimostratori vanno offline sembra eccessivo. Forse in questo scenario, Ethereum potrebbe tornare a una modalità in cui il limite del gas diminuisce e i blocchi vengono rieseguiti piuttosto che verificati con ZKP. 4. Aumentare di 100 volte il limite di gas potrebbe creare problemi La dimostrazione parallelizzata è sicuramente utile, ma i tempi sono così stretti che è necessario considerare la generazione di testimoni (non parallelizzabile in molte zkVM) e la ricorsione. Il sovraccarico di ricorsione dovrebbe scalare logaritmicamente, ma se il limite del gas aumenta di 100 volte, i tempi di dimostrazione potrebbero superare i tempi di blocco. Bonus - Direi che è davvero importante per Ethereum ridurre i tempi di blocco e il tempo di finalizzazione, al fine di aiutare gli utenti a salire a bordo di L2, bridge da CEX, ecc. Ciò aumenta le richieste di latenza durante la dimostrazione. Sarebbe non ottimale se non fossimo in grado di passare a tempi di blocco di 1 secondo perché il limite inferiore sulla latenza RTP nel peggiore dei casi è di 10 secondi.