Досліджуючи @boundless_xyz еко, я виявив цікавий варіант використання в додатках @RiscZero R0VM: ZK Proof of Exploit - zkPoEx. Серед усіх багів найкритичнішими є ті, які є в live-продуктах. У криптовалюті, оскільки критичні вразливості відразу призводять до експлойту фонду, грошова вартість живих багів дуже висока. Зазвичай, коли такі помилки знаходяться, платформи винагороди за виявлення помилок, такі як @immunefi або @HackenProof, виступають посередниками для перевірки автентичності та серйозності помилки та усунення переговорів про винагороду. Ця структура має одну проблему: деталі бага мають бути розкриті до того, як білий капелюх отримає винагороду. З точки зору проєкту, після отримання звіту про помилку та його розгляду, вони можуть виправити його, а потім заявити, що він «виходить за рамки» або знизити його серйозність. У дуже екстремальних випадках посередники могли побачити вразливість і скористатися нею першими. zkPoEx за допомогою R0VM від RiscZero дозволяє довести існування вразливості за допомогою ZK-доказу, не розкриваючи деталей помилки. Оскільки це може довести, що баг, який задовольняє певним умовам, існує, шукачі помилок можуть очікувати більш спільних відповідей від проєктів, таких як запит часткової оплати наперед. Щоб пояснити детальніше, доповідач використовує контракт calldata/exploit як приватний вхід і стан часу атаки як публічний вхід для зміни значень стану цільового контракту в межах R0VM. Після виконання квитанція tx і доказ, згенерований R0VM Prover, можуть перевірити, чи відповідала атака конкретним умовам, таким як зміни балансу. Особисто я вважаю, що цей метод досить корисний для повідомлення про живі вразливості, але я ще не бачив жодного випадку, коли повідомлялося про баги за допомогою цього підходу. Схоже, тому, що проектам потрібно заздалегідь забезпечити умови... Якщо таку систему дійсно складно впровадити на практиці, я хотів би знати, які будуть виклики.