Ao explorar @boundless_xyz eco, descobri um caso de uso interessante nos aplicativos do @RiscZero R0VM: ZK Proof of Exploit - zkPoEx. Entre todos os bugs, os mais críticos são aqueles que existem em produtos ativos. Em criptomoedas, como vulnerabilidades críticas levam imediatamente à exploração de fundos, o valor monetário dos bugs ativos é muito alto. Normalmente, quando esses bugs são encontrados, plataformas de recompensas por bugs, como @immunefi ou @HackenProof, atuam como intermediárias para verificar a autenticidade e a gravidade do bug e corrigir a negociação de recompensas. Essa estrutura tem um problema: os detalhes do bug devem ser divulgados antes que o whitehat receba recompensa. Do ponto de vista do projeto, depois de receber o relatório de bug e revisá-lo, eles podem corrigi-lo e alegar que está "fora do escopo" ou rebaixar sua gravidade. Em casos muito extremos, os intermediários podem ver a vulnerabilidade e explorá-la primeiro. O zkPoEx, por meio do R0VM da RiscZero, permite comprovar a existência de uma vulnerabilidade com prova ZK sem revelar os detalhes do bug. Como pode provar que existe um bug que satisfaz certas condições, os localizadores de bugs podem esperar respostas mais cooperativas dos projetos, como pedir pagamento parcial adiantado. Para explicar com mais detalhes, o relator usa calldata/exploit contract como entrada privada e o estado de tempo de ataque como entrada pública para alterar os valores de estado do contrato de destino em R0VM. Após a execução, o recibo tx e a prova gerada pelo R0VM Prover podem verificar se o ataque atendeu a condições específicas, como alterações de balanceamento. Pessoalmente, acho que esse método é bastante útil para relatar vulnerabilidades ao vivo, mas ainda não vi nenhum caso em que bugs tenham sido relatados usando essa abordagem. Parece ser porque os projetos precisam fornecer as condições com antecedência... Se tal sistema for realmente difícil de implementar na prática, gostaria de saber quais seriam os desafios.