När jag utforskade @boundless_xyz eco upptäckte jag ett intressant användningsfall i @RiscZero R0VM:s applikationer: ZK Proof of Exploit - zkPoEx. Bland alla buggar är de mest kritiska de som finns i levande produkter. I krypto, eftersom kritiska sårbarheter omedelbart leder till utnyttjande av pengar, är det monetära värdet av levande buggar mycket högt. Vanligtvis, när sådana buggar hittas, fungerar bug bounty-plattformar som @immunefi eller @HackenProof som mellanhänder för att verifiera äktheten och allvarlighetsgraden av buggen och åtgärda bounty-förhandling. Den här strukturen har ett problem: buggdetaljerna måste avslöjas innan whitehaten får belöning. Ur projektets perspektiv, efter att ha fått felrapporten och granskat den, kan de korrigera den och sedan hävda att den är "utom räckhåll" eller nedgradera dess allvarlighetsgrad. I mycket extrema fall kan mellanhänder se sårbarheten och utnyttja den först. zkPoEx, genom RiscZeros R0VM, gör det möjligt att bevisa förekomsten av en sårbarhet med ZK-bevis utan att avslöja buggdetaljerna. Eftersom det kan bevisa att en bugg som uppfyller vissa villkor existerar, kan buggfinnare förvänta sig mer samarbetsvilliga svar från projekt, som att be om delbetalning i förskott. För att förklara mer detaljerat använder reportern calldata/exploit contract som privata indata och attacktidstillståndet som offentliga indata för att ändra tillståndsvärdena för målkontraktet i R0VM. Efter körningen kan tx-kvittot och beviset som genereras av R0VM Prover verifiera om attacken uppfyllde specifika villkor, till exempel saldoändringar. Jag tycker personligen att den här metoden är ganska användbar för att rapportera live-sårbarheter, men jag har inte sett några fall där buggar har rapporterats med detta tillvägagångssätt ännu. Det verkar bero på att projekten måste ge förutsättningarna i förväg... Om ett sådant system verkligen är svårt att implementera i praktiken skulle jag vilja veta vilka utmaningarna skulle vara.