Saat menjelajahi @boundless_xyz eco, saya menemukan kasus penggunaan yang menarik dalam aplikasi @RiscZero R0VM: ZK Proof of Exploit - zkPoEx. Di antara semua bug, yang paling kritis adalah yang ada di produk langsung. Dalam kripto, karena kerentanan kritis segera mengarah pada eksploitasi dana, nilai moneter dari bug langsung sangat tinggi. Biasanya, ketika bug tersebut ditemukan, platform bug bounty seperti @immunefi atau @HackenProof bertindak sebagai perantara untuk memverifikasi keaslian dan tingkat keparahan bug dan memulihkan negosiasi hadiah. Struktur ini memiliki satu masalah: detail bug harus diungkapkan sebelum whitehat menerima hadiah. Dari perspektif proyek, setelah menerima laporan bug dan meninjaunya, mereka dapat menambalnya dan kemudian mengklaimnya "di luar cakupan" atau menurunkan tingkat keparahannya. Dalam kasus yang sangat ekstrem, perantara dapat melihat kerentanan dan mengeksploitasinya terlebih dahulu. zkPoEx, melalui R0VM RiscZero, memungkinkan membuktikan keberadaan kerentanan dengan bukti ZK tanpa mengungkapkan detail bug. Karena dapat membuktikan bahwa bug yang memenuhi kondisi tertentu ada, pencari bug dapat mengharapkan respons yang lebih kooperatif dari proyek, seperti meminta pembayaran sebagian di muka. Untuk menjelaskan secara lebih rinci, pelapor menggunakan kontrak calldata/exploit sebagai input pribadi dan status waktu serangan sebagai input publik untuk mengubah nilai status kontrak target dalam R0VM. Setelah eksekusi, tanda terima dan bukti tx yang dihasilkan oleh R0VM Prover dapat memverifikasi apakah serangan memenuhi kondisi tertentu, seperti perubahan saldo. Saya pribadi berpikir metode ini cukup berguna untuk melaporkan kerentanan langsung, tetapi saya belum melihat kasus di mana bug telah dilaporkan menggunakan pendekatan ini. Tampaknya karena proyek perlu menyediakan kondisi terlebih dahulu ... Jika sistem seperti itu memang sulit diterapkan dalam praktiknya, saya ingin tahu apa tantangannya.