O progresso feito por @SuccinctLabs e @RiscZero em direção à prova em tempo real tem sido super impressionante. QT-ing não para ser crítico, mas porque eu acho que essas perguntas são realmente interessantes (e eu gostaria de ver RTP bater Ethereum!). 1. Provar todos os blocos históricos do Ethereum dentro de 12s não é suficiente para cobrir o pior tempo de provação. Isso é importante porque existem possíveis blocos patológicos ("prover-killer") onde o custo de comprovação >> o custo do gás (provar o custo é uma medida de latência ou $). O primeiro passo é provar todos os blocos históricos dentro de 12s. Mas isso não é suficiente. Precisamos trabalhar para identificar casos patológicos que ainda não apareceram no Ethereum. Não tenho certeza de qual é o cronograma de custos para o SP1, mas algo como um bloco inteiro cheio de extcodehash pode ser caro em termos de latência. 2. A verificação formal também precisa abranger o compilador 😱 @argumentxyz tive um bom artigo sobre a frequência com que os bugs do compilador são encontrados ( tl; dr há uma classe específica de "bugs de otimização incorreta" que podem ser potencialmente explorados em zkVMs para criar problemas de solidez. Esses bugs são encontrados com bastante frequência. @drakefjustin argumentou que podemos contornar isso com muitas implementações zkVM. Mas isso não funciona se esses zkVMs compartilharem a mesma cadeia de ferramentas do compilador e forem vulneráveis aos mesmos bugs. 3. Não é necessária prova em casa Acho que concordo que a prova em casa não é necessária. Já contamos com atores extra-protocolo, como construtores, para construir blocos. A garantia que queremos é que *alguém* esteja sempre disponível para gerar provas. Adiar a RTP para o cenário da 3ª Guerra Mundial, em que todos os provadores ficam offline, parece um exagero. Talvez neste cenário, o Ethereum poderia retornar a um modo em que o limite de gás diminui e os blocos são reexecutados, em vez de verificados com ZKPs. 4. 100x-ing o limite de gás pode criar problemas A prova paralelizada definitivamente ajuda, mas o tempo é tão apertado que precisamos considerar a geração de testemunhas (não paralelizável em muitos zkVMs) e a recursão. A sobrecarga de recursão deve ser dimensionada logaritmicamente, mas se o limite de gás aumentar em 100x, os tempos de prova podem exceder os tempos de bloco. Bônus - Eu diria que é realmente importante para o Ethereum reduzir os tempos de bloqueio e o tempo até a finalização, a fim de ajudar os usuários a integrar L2s, ponte de CEXs, etc. Isso aumenta as exigências de latência na prova. Seria subótimo se não formos capazes de passar para tempos de bloco 1s porque o limite inferior na latência RTP do pior caso é 10s.