Mens jeg utforsket @boundless_xyz øko, oppdaget jeg et interessant brukstilfelle i @RiscZero R0VMs applikasjoner: ZK Proof of Exploit - zkPoEx. Blant alle feil er de mest kritiske de som finnes i levende produkter. I krypto, siden kritiske sårbarheter umiddelbart fører til fondsutnyttelse, er den monetære verdien av levende feil svært høy. Vanligvis, når slike feil blir funnet, fungerer bug bounty-plattformer som @immunefi eller @HackenProof som mellomledd for å verifisere ektheten og alvorlighetsgraden av feilen og utbedre dusørforhandlinger. Denne strukturen har ett problem: feildetaljene må avsløres før hvithatten mottar dusør. Fra prosjektets perspektiv, etter å ha mottatt feilrapporten og gjennomgått den, kan de lappe den og deretter hevde at den er "utenfor omfanget" eller nedgradere alvorlighetsgraden. I svært ekstreme tilfeller kan mellommenn se sårbarheten og utnytte den først. zkPoEx, gjennom RiscZeros R0VM, gjør det mulig å bevise eksistensen av en sårbarhet med ZK-bevis uten å avsløre feildetaljene. Siden det kan bevise at det eksisterer en feil som tilfredsstiller visse betingelser, kan feilfinnere forvente mer samarbeidssvar fra prosjekter, for eksempel å be om delbetaling på forhånd. For å forklare mer detaljert, bruker reporteren calldata/exploit-kontrakten som private inndata og angrepstidstilstanden som offentlig inndata for å endre tilstandsverdiene til målkontrakten i R0VM. Etter utførelse kan tx-kvitteringen og beviset generert av R0VM Prover bekrefte om angrepet oppfylte spesifikke betingelser, for eksempel saldoendringer. Jeg personlig synes denne metoden er ganske nyttig for å rapportere sårbarheter i sanntid, men jeg har ikke sett noen tilfeller der feil har blitt rapportert ved hjelp av denne tilnærmingen ennå. Det ser ut til å være fordi prosjekter må gi betingelsene på forhånd ... Hvis et slikt system virkelig er vanskelig å implementere i praksis, vil jeg gjerne vite hva utfordringene vil være.