O progresso feito pela @SuccinctLabs e @RiscZero em direção à prova em tempo real foi super impressionante. QT-ing não para ser crítico, mas porque acho que essas questões são realmente interessantes (e gostaria de ver o RTP atingir o Ethereum!). 1. Provar todos os blocos históricos do Ethereum em 12s não é suficiente para cobrir o pior caso de provação. Isso é importante porque existem possíveis bloqueios patológicos ("provador-assassino") em que a comprovação de custo >> o custo do gás (comprovar 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 cobrir o compilador 😱 @argumentxyz tinha 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 poderiam ser potencialmente exploráveis 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 de 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 comprovação 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 o RTP para o cenário da 3ª Guerra Mundial, onde todos os provadores ficam offline, parece um exagero. Talvez, nesse cenário, o Ethereum possa voltar a um modo em que o limite de gás diminua e os blocos sejam reexecutados em vez de verificados com ZKPs. 4. 100x 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 bloco e o tempo de finalização, a fim de ajudar os usuários a integrar L2s, fazer a ponte de CEXs, etc. Isso aumenta as demandas de latência na prova. Seria abaixo do ideal se não pudéssemos passar para tempos de bloco de 1s porque o limite inferior na latência RTP do pior caso é 10s.