Tutkiessani @boundless_xyz ecoa löysin mielenkiintoisen käyttötapauksen @RiscZero R0VM:n sovelluksista: ZK Proof of Exploit - zkPoEx. Kaikista virheistä kriittisimmät ovat ne, joita esiintyy elävissä tuotteissa. Kryptossa, koska kriittiset haavoittuvuudet johtavat välittömästi varojen hyödyntämiseen, elävien bugien rahallinen arvo on erittäin korkea. Tyypillisesti, kun tällaisia bugeja löytyy, bug bounty -alustat, kuten @immunefi tai @HackenProof, toimivat välittäjinä varmistaakseen virheen aitouden ja vakavuuden ja korjatakseen palkkioneuvottelut. Tässä rakenteessa on yksi ongelma: bugin yksityiskohdat on paljastettava ennen kuin valkohattu saa palkkion. Projektin näkökulmasta, saatuaan vikaraportin ja tarkistettuaan sen, he voisivat korjata sen ja sitten väittää, että se on "soveltamisalan ulkopuolella" tai alentaa sen vakavuutta. Hyvin äärimmäisissä tapauksissa välittäjät voivat nähdä haavoittuvuuden ja hyödyntää sitä ensin. zkPoEx, RiscZeron R0VM:n kautta, mahdollistaa haavoittuvuuden olemassaolon todistamisen ZK-todisteella paljastamatta virheen yksityiskohtia. Koska se voi todistaa, että tietyt ehdot täyttävä virhe on olemassa, virheiden etsijät voivat odottaa projekteilta yhteistyökykyisempiä vastauksia, kuten osittaisen maksun pyytämistä etukäteen. Tarkemmin selittääkseen raportoija käyttää calldata/exploit-sopimusta yksityisenä syötteenä ja hyökkäysajan tilaa julkisena syötteenä kohdesopimuksen tila-arvojen muuttamiseen R0VM:ssä. Suorituksen jälkeen R0VM Proverin luoma tx-kuitti ja todistus voivat tarkistaa, täyttikö hyökkäys tietyt ehdot, kuten saldon muutokset. Henkilökohtaisesti olen sitä mieltä, että tämä menetelmä on varsin hyödyllinen reaaliaikaisten haavoittuvuuksien raportoinnissa, mutta en ole vielä nähnyt yhtään tapausta, jossa virheitä olisi raportoitu tällä lähestymistavalla. Se näyttää johtuvan siitä, että hankkeissa on tarjottava edellytykset etukäteen... Jos tällaista järjestelmää on todella vaikea toteuttaa käytännössä, haluaisin tietää, mitä haasteita se on.