Při zkoumání @boundless_xyz eco, objevil jsem zajímavý případ použití v aplikacích @RiscZero R0VM: ZK Proof of Exploit - zkPoEx. Ze všech chyb jsou nejkritičtější ty, které existují v živých produktech. Vzhledem k tomu, že kritické zranitelnosti v kryptoměnách okamžitě vedou ke zneužití fondu, je peněžní hodnota živých chyb velmi vysoká. Když jsou takové chyby nalezeny, platformy odměn za chybu, jako jsou @immunefi nebo @HackenProof, obvykle fungují jako prostředníci pro ověření pravosti a závažnosti chyby a nápravu vyjednávání o odměnách. Tato struktura má jeden problém: podrobnosti o chybě musí být zveřejněny předtím, než whitehat obdrží odměnu. Z pohledu projektu by po obdržení hlášení o chybě a jeho přezkoumání mohli provést opravu a poté tvrdit, že je "mimo rozsah" nebo snížit její závažnost. Ve velmi extrémních případech by zprostředkovatelé mohli zranitelnost vidět a zneužít ji jako první. zkPoEx prostřednictvím R0VM společnosti RiscZero umožňuje prokázat existenci zranitelnosti pomocí důkazu ZK bez odhalení podrobností o chybě. Vzhledem k tomu, že může prokázat, že chyba splňující určité podmínky existuje, mohou vyhledávači chyb očekávat od projektů kooperativnější reakce, jako je například požadavek na částečnou platbu předem. Abychom to vysvětlili podrobněji, reportér používá calldata/exploit kontrakt jako soukromý vstup a stav attack-time jako veřejný vstup ke změně stavových hodnot cílového kontraktu v rámci R0VM. Po spuštění může tx účtenka a důkaz vygenerovaný R0VM Prover ověřit, zda útok splňoval konkrétní podmínky, jako jsou změny zůstatku. Osobně si myslím, že tato metoda je docela užitečná pro hlášení živých zranitelností, ale zatím jsem neviděl žádné případy, kdy by byly chyby hlášeny pomocí tohoto přístupu. Zdá se, že je to proto, že projekty musí zajistit podmínky předem... Pokud by byl takový systém skutečně obtížné implementovat v praxi, rád bych věděl, jaké by byly výzvy.