Sebuah transaksi CBDC dapat dikonfirmasi sebagai sah tanpa ada yang tahu jumlahnya selain orang dalam.
Itu adalah jenis sistem yang @SignOfficial sedang diuji dengan penerapan yang diizinkan berdasarkan Hyperledger Fabric.
Kedengarannya masuk akal. Tapi ini juga saat segalanya mulai menjadi rumit.
Tidak perlu menyembunyikan semuanya. Hanya yang perlu diungkapkan saja.
Secara teoritis, CBDC selalu terjebak di antara dua kutub. Di satu sisi adalah transparan seperti RTGS, di mana bank melihat segalanya. Di sisi lain adalah privasi seperti uang tunai, di mana tidak ada yang melihat selain orang dalam. Sebagian besar sistem memilih titik di tengah.
Tanda tangan dilakukan dengan cara lain. Mereka dipisahkan menjadi banyak ruang.
wCBDC untuk antar bank. rCBDC untuk pengguna. Satu lapisan khusus untuk regulator. Setiap namespace memiliki kebijakan endorsement sendiri; setiap transaksi harus dikonfirmasi sesuai dengan aturan yang berbeda.
Privasi tidak lagi menjadi atribut yang melekat pada transaksi. Itu adalah konsekuensi dari transaksi tersebut berada di ruang mana. Jika di wholesale, tingkat transparansi mendekati RTGS. Jika di retail, informasi hanya muncul untuk pengirim, penerima, dan otoritas pengatur yang ditunjuk.
Tidak ada pengaturan umum. Pendekatan ini memungkinkan setiap jenis transaksi memiliki tingkat privasi yang berbeda sejak arsitektur.
Lapisan kedua adalah cara penanganan transaksi. Sistem menggunakan Hyperledger Fabric Token SDK dengan model UTXO. Setiap transaksi mengkonsumsi output lama dan menciptakan output baru. Dipadukan dengan zero-knowledge proofs (ZKP), sistem hanya membuktikan apa yang diperlukan, tidak mengungkapkan seluruh data.
Sebuah contoh: sebuah transaksi ritel dapat membuktikan bahwa ia tidak melebihi batas 10.000 USD tanpa mengungkapkan jumlah yang tepat, atau membuktikan bahwa penerima termasuk dalam kelompok yang memenuhi syarat tanpa mengungkapkan seluruh identitas. Verifikasi tetap berlangsung, tetapi data tidak sepenuhnya dibuka.
Implementasi permissioned seperti ini menargetkan throughput ~100.000 transaksi per detik, sesuai dengan lingkungan antar bank atau implementasi nasional. Pada skala itu, upaya untuk 'menyembunyikan semuanya dan mendekripsi saat diperlukan' hampir tidak mungkin. Pengungkapan selektif menjadi wajib.
Namun risiko mulai muncul. Privasi menurut namespace mengajukan pertanyaan: siapa yang memutuskan Anda termasuk namespace mana. Jika sebuah transaksi diklasifikasikan salah, tingkat privasi juga salah. Jika kebijakan endorsement menyimpang, hak konfirmasi juga menyimpang. Ini bukan kesalahan kriptografi, tetapi kesalahan tata kelola.
Lapisan lain yang lebih dalam: regulator tidak lagi berada di luar. Mereka diberikan akses di tingkat arsitektur, yang diperlukan untuk kepatuhan, audit, dan kebijakan moneter. Namun, asumsi bahwa akses selalu digunakan untuk tujuan yang benar adalah risiko nyata.
Sistem ini berfungsi ketika tiga hal seimbang: pemisahan namespace cukup jelas, kebijakan cukup ketat, akses dikendalikan dengan benar. Ini mulai memiliki masalah ketika salah satu dari tiga hal menyimpang: namespace tercampur, kebijakan longgar, akses diperluas di luar yang diharapkan.
Privasi dalam Protokol Tanda Tangan bukanlah saklar on/off. Itu adalah hasil dari cara sistem mendefinisikan: siapa Anda, Anda sedang bertransaksi di mana, dan mengikuti aturan mana. Tidak semua transaksi bersifat privat, tidak semua transaksi bersifat transparan. Setiap transaksi dilahirkan dengan tingkat privasi yang telah ditentukan sebelumnya.
Ini berfungsi jika arsitektur menjaga batas antara lapisan.
Ini gagal jika batas tersebut dilanggar.
Itu juga merupakan alasan mengapa saya terus memantau bagaimana desain seperti ini diimplementasikan dalam praktik, di mana kesalahan tidak berasal dari kode, tetapi dari cara orang mendefinisikan dan mengoperasikan sistem.
$SIGN #SignDigitalSovereignInfra
