Les progrès réalisés par @SuccinctLabs et @RiscZero vers la preuve en temps réel ont été très impressionnants. QT-ing non pas pour être critique mais parce que je pense que ces questions sont vraiment intéressantes (et j’aimerais voir RTP arriver sur Ethereum !). 1. Prouver tous les blocs Ethereum historiques dans les 12 secondes n’est pas suffisant pour couvrir le pire des temps. C’est important car il existe des blocs pathologiques possibles où le coût de preuve >> coût de gaz (prouver le coût est une mesure de la latence ou $). La première étape consiste à prouver tous les blocs historiques dans les 12 secondes. Mais cela ne suffit pas. Nous devons travailler à identifier les cas pathologiques qui ne sont pas encore apparus sur Ethereum. Je ne sais pas quel est le barème des coûts pour SP1, mais quelque chose comme un bloc entier rempli d’extcodehash pourrait être coûteux en termes de latence. 2. La vérification formelle doit également couvrir le compilateur 😱 @argumentxyz avions un bon article sur la fréquence à laquelle les bogues du compilateur sont trouvés ( tl ; dr il existe une classe spécifique de « bogues de mauvaise optimisation » qui pourraient potentiellement être exploitables dans les zkVM pour créer des problèmes de solidité. Ces insectes sont trouvés assez fréquemment. @drakefjustin a soutenu que nous pouvons contourner ce problème avec de nombreuses implémentations de zkVM. Mais cela ne fonctionne pas si ces zkVM partagent la même chaîne d’outils de compilateur et sont vulnérables aux mêmes bogues. 3. Il n’est pas nécessaire de faire ses preuves à domicile Je pense que je suis d’accord que la preuve à domicile n’est pas nécessaire. Nous nous appuyons déjà sur des acteurs extra-protocolaires comme les constructeurs pour construire des blocs. La garantie que nous voulons, c’est que *quelqu’un* soit toujours disponible pour générer des preuves. Reporter RTP pour le scénario de la Troisième Guerre mondiale, où tous les prouveurs se déconnectent, semble exagéré. Peut-être que dans ce scénario, Ethereum pourrait revenir par défaut à un mode où la limite de gaz diminue et où les blocs sont réexécutés plutôt que vérifiés avec des ZKP. 4. 100x-ing la limite de gaz pourrait créer des problèmes La preuve parallélisée aide certainement, mais le timing est si serré que nous devons prendre en compte la génération de témoins (non parallélisable dans de nombreuses zkVM) et la récursivité. La surcharge de récursivité doit évoluer de manière logarithmique, mais si la limite de gaz augmente de 100x, les temps d’étalonnage peuvent dépasser les temps de blocage. Bonus - Je dirais qu’il est vraiment important pour Ethereum de réduire les temps de bloc et le temps jusqu’à la finalité, afin d’aider les utilisateurs à s’intégrer aux L2, à faire le pont entre les CEX, etc. Cela augmente les exigences de latence lors de la démonstration. Il serait sous-optimal si nous ne pouvions pas passer à des temps de bloc de 1 s, car la limite inférieure de la latence RTP dans le pire des cas est de 10 s.