Die Fortschritte, die @SuccinctLabs und @RiscZero in Richtung Echtzeit-Nachweis gemacht haben, sind sehr beeindruckend. QT-ing nicht um kritisch zu sein, sondern weil ich diese Fragen wirklich interessant finde (und ich würde gerne sehen, dass RTP Ethereum trifft!). 1. Der Nachweis aller historischen Ethereum-Blöcke innerhalb von 12 Sekunden reicht nicht aus, um die Zeit des Worst-Case-Beweises abzudecken. Dies ist wichtig, da es mögliche pathologische ("Prover-Killer") Blöcke gibt, bei denen der Nachweis der Kosten die Gaskosten >> (der Nachweis der Kosten ist ein Maß für die Latenz oder $). Der erste Schritt besteht darin, alle historischen Blöcke innerhalb von 12s zu beweisen. Aber das reicht nicht aus. Wir müssen daran arbeiten, pathologische Fälle zu identifizieren, die noch nicht auf Ethereum aufgetaucht sind. Ich bin mir nicht sicher, wie der Kostenplan für SP1 aussieht, aber so etwas wie ein ganzer Block voller Extcodehash könnte in Bezug auf die Latenz teuer sein. 2. Die formale Verifizierung muss auch den Compiler 😱 abdecken @argumentxyz hatte einen guten Artikel über die Häufigkeit, mit der Compilerfehler gefunden werden ( tl; DR Es gibt eine bestimmte Klasse von "Fehloptimierungsfehlern", die in zkVMs möglicherweise ausgenutzt werden können, um Probleme mit der Solidität zu verursachen. Diese Fehler werden ziemlich häufig gefunden. @drakefjustin hat argumentiert, dass wir dies mit vielen zkVM-Implementierungen umgehen können. Das funktioniert jedoch nicht, wenn diese zkVMs dieselbe Compiler-Toolchain verwenden und anfällig für dieselben Fehler sind. 3. Eine Prüfung zu Hause ist nicht erforderlich Ich denke, ich stimme zu, dass es nicht notwendig ist, sich zu Hause zu beweisen. Wir verlassen uns bereits auf außerprotokollarische Akteure wie Builder, um Blöcke zu erstellen. Die Garantie, die wir wollen, ist, dass *jemand* immer verfügbar ist, um Beweise zu generieren. Die Verschiebung des RTP für das Szenario des 3. Weltkriegs, in dem alle Prüfer offline gehen, scheint übertrieben. Vielleicht könnte Ethereum in diesem Szenario in einen Modus zurückkehren, in dem das Gaslimit sinkt und die Blöcke erneut ausgeführt werden, anstatt mit ZKPs verifiziert zu werden. 4. Das 100-fache des Gaslimits könnte zu Problemen führen Parallelisiertes Beweisen hilft definitiv, aber das Timing ist so eng, dass wir die Zeugengenerierung (in vielen zkVMs nicht parallelisierbar) und die Rekursion berücksichtigen müssen. Der Rekursions-Overhead sollte logarithmisch skaliert werden, aber wenn das Gaslimit um das 100-fache steigt, könnten die Beweiszeiten die Blockzeiten überschreiten. Bonus - Ich würde behaupten, dass es für Ethereum wirklich wichtig ist, die Blockzeiten und die Zeit bis zur Finalität zu reduzieren, um den Benutzern beim Einstieg in L2s, der Brücke von CEXs usw. zu helfen. Dies erhöht die Latenzanforderungen beim Proofing. Es wäre suboptimal, wenn wir nicht in der Lage wären, zu 1s-Blockzeiten zu wechseln, da die Untergrenze für die RTP-Latenz im schlimmsten Fall bei 10s liegt.