Ingin membuktikan diri bersih tanpa menyerahkan daftar klien? Ada solusinya
Hal paling canggung bagi institusi saat mulai beroperasi adalah ingin membuktikan bahwa mereka bersih, tetapi tidak mau menyerahkan daftar klien. Saat ini, pada dasarnya ada dua cara. Cara pertama adalah menyerahkan alamat dan riwayat transaksi kepada perusahaan analisis on-chain untuk diberi skor. Artinya, semua kartu dibuka di hadapan pihak ketiga. Cara kedua adalah membuat daftar putih Merkle, yang hanya bisa membuktikan bahwa suatu alamat ada dalam kumpulan tersebut, tetapi tidak bisa membuktikan bahwa kumpulan itu sendiri bersih. Saya pernah mencoba cara ketiga lewat jalur data privat SXT: daftar internal dan daftar alamat terlarang yang tersedia untuk publik dimasukkan ke dalam satu tabel, lalu hasil kueri berupa nilai boolean beserta bukti. Pihak luar hanya diberi tahu kesimpulannya, tanpa mengungkap satu pun catatan. Potensi penerapan cara ini lebih besar daripada yang dibayangkan kebanyakan orang. Pembuktian cadangan bisa dilakukan seperti ini, penyaringan sanksi juga bisa, bahkan untuk memastikan apakah nilai aset klien mencapai ambang tertentu pun bisa—semuanya hanya menghasilkan jawaban ya atau tidak. Secara teknis, tantangan sebenarnya adalah ketepatan waktu. Daftar berubah setiap hari, jadi buktinya juga harus dibuat ulang. Kalau tidak, yang dibuktikan adalah bahwa Anda bersih minggu lalu. Saya pernah mengalami masalah ini: saya memakai bukti lama untuk memverifikasi daftar baru, dan kontraknya memberi tahu bahwa semuanya baik-baik saja. Saat itu punggung saya terasa agak merinding. Setelah itu, saya belajar menyertakan hash versi data di dalam bukti. Jika versinya tidak cocok, bukti langsung ditolak. Hambatannya bukan pada kriptografi, melainkan pada daftar itu sendiri. Siapa yang memeliharanya, seberapa sering diperbarui, dan apakah catatan pembaruannya bisa diaudit—semua ini adalah masalah operasional. Kalau banyak kesalahan, semuanya sia-sia. Selain itu, pengakuan hukum terhadap bukti kriptografis masih belum jelas. Petugas kepatuhan lebih suka melihat laporan yang sudah distempel. Dibandingkan dengan pembuktian cadangan Chainlink, cara ini lebih fleksibel karena bisa menjalankan SQL apa pun, bukan sekadar menjumlahkan saldo. Konsekuensinya, Anda harus menanggung sendiri beban rekayasa pembuktiannya. Menurut saya, jalur ini akan lebih dulu dimanfaatkan oleh institusi RWA dan kustodian, karena yang paling mereka butuhkan adalah cara untuk membuktikan diri tanpa membocorkan informasi. Jika ingin mengembangkannya lebih jauh, kita juga perlu menggabungkan bukti rentang dan bukti agregat. Misalnya, membuktikan bahwa total eksposur berada di bawah batas sekaligus memastikan bahwa tidak ada satu pun pihak lawan yang melampaui batas. Belum ada perangkat siap pakai untuk kebutuhan seperti ini, jadi harus merangkainya sendiri. Setelah lapisan ini berjalan lancar, cara institusi memasarkan diri akan berubah: dari «manajemen risiko kami sangat ketat» menjadi «Anda bisa memverifikasinya sendiri».#sxt $SXT @SpaceandTime
Hal paling canggung bagi institusi saat mulai beroperasi adalah ingin membuktikan bahwa mereka bersih, tetapi tidak mau menyerahkan daftar klien. Saat ini, pada dasarnya ada dua cara. Cara pertama adalah menyerahkan alamat dan riwayat transaksi kepada perusahaan analisis on-chain untuk diberi skor. Artinya, semua kartu dibuka di hadapan pihak ketiga. Cara kedua adalah membuat daftar putih Merkle, yang hanya bisa membuktikan bahwa suatu alamat ada dalam kumpulan tersebut, tetapi tidak bisa membuktikan bahwa kumpulan itu sendiri bersih. Saya pernah mencoba cara ketiga lewat jalur data privat SXT: daftar internal dan daftar alamat terlarang yang tersedia untuk publik dimasukkan ke dalam satu tabel, lalu hasil kueri berupa nilai boolean beserta bukti. Pihak luar hanya diberi tahu kesimpulannya, tanpa mengungkap satu pun catatan. Potensi penerapan cara ini lebih besar daripada yang dibayangkan kebanyakan orang. Pembuktian cadangan bisa dilakukan seperti ini, penyaringan sanksi juga bisa, bahkan untuk memastikan apakah nilai aset klien mencapai ambang tertentu pun bisa—semuanya hanya menghasilkan jawaban ya atau tidak. Secara teknis, tantangan sebenarnya adalah ketepatan waktu. Daftar berubah setiap hari, jadi buktinya juga harus dibuat ulang. Kalau tidak, yang dibuktikan adalah bahwa Anda bersih minggu lalu. Saya pernah mengalami masalah ini: saya memakai bukti lama untuk memverifikasi daftar baru, dan kontraknya memberi tahu bahwa semuanya baik-baik saja. Saat itu punggung saya terasa agak merinding. Setelah itu, saya belajar menyertakan hash versi data di dalam bukti. Jika versinya tidak cocok, bukti langsung ditolak. Hambatannya bukan pada kriptografi, melainkan pada daftar itu sendiri. Siapa yang memeliharanya, seberapa sering diperbarui, dan apakah catatan pembaruannya bisa diaudit—semua ini adalah masalah operasional. Kalau banyak kesalahan, semuanya sia-sia. Selain itu, pengakuan hukum terhadap bukti kriptografis masih belum jelas. Petugas kepatuhan lebih suka melihat laporan yang sudah distempel. Dibandingkan dengan pembuktian cadangan Chainlink, cara ini lebih fleksibel karena bisa menjalankan SQL apa pun, bukan sekadar menjumlahkan saldo. Konsekuensinya, Anda harus menanggung sendiri beban rekayasa pembuktiannya. Menurut saya, jalur ini akan lebih dulu dimanfaatkan oleh institusi RWA dan kustodian, karena yang paling mereka butuhkan adalah cara untuk membuktikan diri tanpa membocorkan informasi. Jika ingin mengembangkannya lebih jauh, kita juga perlu menggabungkan bukti rentang dan bukti agregat. Misalnya, membuktikan bahwa total eksposur berada di bawah batas sekaligus memastikan bahwa tidak ada satu pun pihak lawan yang melampaui batas. Belum ada perangkat siap pakai untuk kebutuhan seperti ini, jadi harus merangkainya sendiri. Setelah lapisan ini berjalan lancar, cara institusi memasarkan diri akan berubah: dari «manajemen risiko kami sangat ketat» menjadi «Anda bisa memverifikasinya sendiri».#sxt $SXT @SpaceandTime
