De vooruitgang die @SuccinctLabs en @RiscZero hebben geboekt in de richting van real-time bewijzen is super indrukwekkend. QT-en, niet om kritisch te zijn, maar omdat ik denk dat deze vragen echt interessant zijn (en ik zou graag zien dat RTP Ethereum raakt!). 1. Het bewijzen van alle historische Ethereum-blokken binnen 12 seconden is niet voldoende om de worstcase-provertijd te overbruggen. Dit is belangrijk omdat er mogelijke pathologische ("prover-killer") blokkades zijn waarbij het bewijzen van kosten >> gaskosten (het bewijzen van kosten is een maat voor latentie of $). De eerste stap is het bewijzen van alle historische blokken binnen 12s. Maar dit is niet genoeg. We moeten werken aan het identificeren van pathologische gevallen die nog niet op Ethereum zijn verschenen. Ik weet niet zeker wat het kostenschema is voor SP1, maar zoiets als een heel blok vol extcodehash kan duur zijn in latentietermen. 2. Formele verificatie moet ook betrekking hebben op de compiler 😱 @argumentxyz had een goed artikel over de frequentie waarmee compiler bugs worden gevonden ( tl; dr er is een specifieke klasse van "mis-optimalisatie bugs" die mogelijk misbruikt kunnen worden in zkVMs om degelijkheidsproblemen te creëren. Deze bugs worden vrij vaak gevonden. @drakefjustin heeft betoogd dat we dit met veel zkVM-implementaties kunnen omzeilen. Maar dat werkt niet als die zkVM's dezelfde compiler-toolchain delen en kwetsbaar zijn voor dezelfde bugs. 3. Thuis bewijzen is niet nodig Ik denk dat ik het ermee eens ben dat thuis bewijzen niet nodig is. We vertrouwen al op extra-protocolactoren zoals bouwers om blokken te bouwen. De garantie die we willen is dat er altijd *iemand* beschikbaar is om bewijzen te genereren. Het uitstellen van RTP voor het WW3-scenario waarin alle experts offline gaan, lijkt overdreven. Misschien zou Ethereum in dit scenario terug kunnen keren naar een modus waarin de gaslimiet daalt en blokken opnieuw worden uitgevoerd in plaats van geverifieerd met ZKP's. 4. 100x-ing van de gaslimiet kan problemen veroorzaken Geparallelliseerd bewijs helpt zeker, maar de timing is zo krap dat we rekening moeten houden met het genereren van getuigen (niet parallelliseerbaar in veel zkVM's) en recursie. Recursie-overhead moet logaritmisch worden geschaald, maar als de gaslimiet met 100x toeneemt, kunnen de bewijstijden de bloktijden overschrijden. Bonus - Ik zou zeggen dat het echt belangrijk is voor Ethereum om bloktijden en -tijd tot finaliteit te verminderen, om gebruikers te helpen aan boord te gaan naar L2's, te overbruggen van CEX's, enz. Dit verhoogt de latentie-eisen aan bewijzen. Het zou suboptimaal zijn als we niet in staat zijn om naar bloktijden van 1s te gaan, omdat de ondergrens van de RTP-latentie in het slechtste geval 10s is.