Podczas eksploracji @boundless_xyz eco odkryłem interesujący przypadek użycia w aplikacjach @RiscZero R0VM: ZK Proof of Exploit - zkPoEx. Wśród wszystkich błędów, najważniejsze są te, które występują w produktach na żywo. W kryptowalutach, ponieważ krytyczne luki bezpieczeństwa natychmiast prowadzą do wykorzystania funduszy, wartość monetarna żywych błędów jest bardzo wysoka. Zazwyczaj, gdy takie błędy są znajdowane, platformy nagród za błędy, takie jak @immunefi lub @HackenProof, działają jako pośrednicy w weryfikacji autentyczności i powagi błędu oraz w negocjacjach dotyczących nagrody. Ta struktura ma jeden problem: szczegóły błędu muszą być ujawnione, zanim biała kapelusz otrzyma nagrodę. Z perspektywy projektu, po otrzymaniu raportu o błędzie i jego przeglądzie, mogą go załatać, a następnie twierdzić, że jest "poza zakresem" lub obniżyć jego powagę. W bardzo ekstremalnych przypadkach pośrednicy mogą zobaczyć lukę i wykorzystać ją jako pierwsi. zkPoEx, poprzez RiscZero's R0VM, pozwala na udowodnienie istnienia luki za pomocą ZK proof bez ujawniania szczegółów błędu. Ponieważ może udowodnić, że istnieje błąd spełniający określone warunki, osoby znajdujące błędy mogą oczekiwać bardziej współpracujących odpowiedzi od projektów, takich jak prośba o częściową płatność z góry. Aby wyjaśnić to bardziej szczegółowo, reporter używa calldata/kontraktu exploit jako prywatnego wejścia i stanu w czasie ataku jako publicznego wejścia, aby zmienić wartości stanu docelowego kontraktu w R0VM. Po wykonaniu, potwierdzenie transakcji i dowód wygenerowany przez R0VM Prover mogą zweryfikować, czy atak spełniał określone warunki, takie jak zmiany salda. Osobiście uważam, że ta metoda jest dość przydatna do zgłaszania żywych luk, ale nie widziałem jeszcze przypadków, w których błędy byłyby zgłaszane przy użyciu tego podejścia. Wydaje się, że to dlatego, że projekty muszą wcześniej określić warunki... Jeśli taki system jest rzeczywiście trudny do wdrożenia w praktyce, chciałbym wiedzieć, jakie byłyby wyzwania.