El progreso realizado por @SuccinctLabs y @RiscZero hacia la prueba en tiempo real ha sido muy impresionante. QT-ing no es por ser crítico, sino porque creo que estas preguntas son realmente interesantes (¡y me gustaría ver que el RTP llegue a Ethereum!). 1. Demostrar todos los bloques históricos de Ethereum en un plazo de 12 segundos no es suficiente para cubrir el peor de los casos. Esto es importante porque hay posibles bloques patológicos ("prover-killer") en los que probar el costo >> el costo del gas (probar el costo es una medida de latencia o $). El primer paso es probar todos los bloques históricos dentro de los 12 segundos. Pero esto no es suficiente. Tenemos que trabajar para identificar los casos patológicos que aún no han aparecido en Ethereum. No estoy seguro de cuál es el programa de costos para SP1, pero algo como un bloque completo lleno de extcodehash podría ser costoso en términos de latencia. 2. La verificación formal también debe cubrir al compilador 😱 @argumentxyz un buen artículo sobre la frecuencia con la que se encuentran errores del compilador ( tl; dr: hay una clase específica de "errores de optimización incorrecta" que podrían ser potencialmente explotables en zkVM para crear problemas de solidez. Estos errores se encuentran con bastante frecuencia. @drakefjustin ha argumentado que podemos sortear esto con muchas implementaciones de zkVM. Pero eso no funciona si esas zkVM comparten la misma cadena de herramientas del compilador y son vulnerables a los mismos errores. 3. No es necesario probar en casa Creo que estoy de acuerdo en que no es necesario probarlo en casa. Ya dependemos de actores fuera del protocolo, como los constructores, para construir bloques. La garantía que queremos es que *alguien* esté siempre disponible para generar pruebas. Aplazar el RTP para el escenario de la 3ª Guerra Mundial, en el que todos los probadores se desconectan, parece una exageración. Tal vez en este escenario, Ethereum podría volver a un modo en el que el límite de gas disminuya y los bloques se vuelvan a ejecutar en lugar de verificarse con ZKP. 4. Multiplicar por 100 el límite de gas podría crear problemas La demostración paralelizada definitivamente ayuda, pero el tiempo es tan ajustado que debemos considerar la generación de testigos (no paralelizable en muchas zkVM) y la recursividad. La sobrecarga de recursividad debe escalar logarítmicamente, pero si el límite de gas aumenta 100x, los tiempos de prueba podrían superar los tiempos de bloque. Bono: yo diría que es realmente importante para Ethereum reducir los tiempos de bloque y el tiempo hasta la finalización, para ayudar a los usuarios a incorporarse a L2, hacer puentes desde CEX, etc. Esto aumenta las demandas de latencia en la demostración. Sería subóptimo si no podemos pasar a tiempos de bloque de 1 s porque el límite inferior de la latencia de RTP en el peor de los casos es de 10 s.