“Bukti cadangan” menjadi populer karena pasar belajar pelajaran berat: solvabilitas bukanlah sebuah vibe. Jika sebuah protokol menerbitkan token yang terhubung dengan BTC, satu-satunya kepercayaan yang tahan lama adalah kemampuan bagi siapa pun untuk memverifikasi – kapan saja – bahwa aset ada, kewajiban sepenuhnya dihitung, dan celah antara keduanya bukanlah sebuah cerita.
Untuk @Lorenzo Protocol , pertanyaan nyata bukanlah apakah pohon cadangan itu modis, tetapi apakah itu menutup celah verifikasi yang nyata. Jika setiap cadangan dan setiap kewajiban sudah terlihat dan dapat dihitung langsung di rantai, pohon terpisah bisa menjadi redundan. Tetapi jika bagian berarti dari cadangan, bukti penyelesaian, atau akuntansi kewajiban berada di luar keadaan transparan dari satu rantai, struktur bukti yang didedikasikan bisa menjadi primitif keamanan yang serius.
Pohon cadangan pada dasarnya adalah komitmen publik: “Inilah set aset yang kami klaim kembali sistem.” Pengguna kemudian dapat memverifikasi inklusi item tertentu dan memantau apakah set tersebut berubah dengan cara yang mencurigakan. Pendekatan klasik menggunakan pohon hash sehingga protokol dapat menerbitkan satu akar kompak sambil tetap memungkinkan verifikasi entri individu.
Bagian yang banyak tim abaikan adalah setengah lainnya: kewajiban. Bukti cadangan tanpa bukti kewajiban seperti menerbitkan foto brankas bank tanpa buku besar setoran. Sebuah protokol bisa ter-over-kolateral di atas kertas sementara masih menyembunyikan kewajiban dalam pembungkus, penebusan yang tertunda, representasi lintas-rantai, atau IOU internal yang tidak pernah muncul di angka pasokan yang sederhana.
Jadi versi terkuat bukanlah “bukti-cadangan,” tetapi “bukti-solvabilitas”: aset dan kewajiban yang dikomitmenkan dalam bentuk yang dapat diverifikasi pengguna. Dalam desain mirip Lorenzo, kewajiban tidak selalu hanya pasokan token tunggal. Mereka dapat mencakup beberapa representasi BTC, penarikan yang tertunda, klaim konversi, dan keadaan apa pun yang menciptakan hak untuk menebus BTC yang mendasarinya.
Tempat di mana pohon yang didedikasikan membantu paling banyak adalah ketika backing tidak dapat diamati dengan mudah di satu tempat. Jika cadangan disimpan dalam serangkaian UTXO Bitcoin, dompet multisig, skrip terkunci waktu, atau struktur kustodi lainnya, pasar menginginkan pandangan yang konsisten dan dapat diperiksa mesin dari seluruh set backing. Komitmen yang dipublikasikan memudahkan untuk mendeteksi cadangan yang hilang, pengacakan mendadak, atau pelaporan yang tidak konsisten dari waktu ke waktu.
Ini juga membantu ketika kewajiban terfragmentasi di seluruh kontrak atau bahkan rantai. Pengguna mungkin melihat token “mereka”, tetapi sistem mungkin memiliki klaim paralel di tempat lain yang bersaing untuk backing yang sama. Pohon kewajiban memaksa protokol untuk berkomitmen pada set kewajiban yang terkoordinasi pada titik waktu tertentu, yang mengurangi ruang untuk akuntansi selektif.
Namun, pohon bukanlah sihir – nilainya tergantung pada aturan. Protokol harus mendefinisikan dengan tepat apa yang dihitung sebagai item cadangan dan apa yang dihitung sebagai item kewajiban, termasuk kasus tepi seperti penarikan yang tertunda, biaya, dan buffer internal. Jika definisi longgar, pohon menjadi cermin yang dipoles yang mencerminkan apa pun yang diinginkan manajemen.
Kelengkapan adalah bagian yang tersulit. Seorang pengguna dapat memverifikasi inklusi saldo mereka, tetapi mereka tidak dapat dengan mudah membuktikan bahwa semua kewajiban termasuk dan tidak ada yang terlewat. Inilah mengapa desain terbaik menggabungkan pohon dengan invariants on-chain yang ketat (batasan pencetakan, logika bakar-untuk-menebus, dan konversi yang terjaga) sehingga “kewajiban yang terlewat” menjadi sulit untuk dibuat tanpa melanggar aturan yang dapat diamati.
Privasi juga penting. Menerbitkan setiap saldo akun dalam teks biasa tidak selalu dapat diterima. Kompromi pragmatis adalah membiarkan bukti inklusi tingkat pengguna sambil menyembunyikan jumlah melalui komitmen atau teknik zero-knowledge, sehingga pasar tetap dapat memverifikasi total dan keanggotaan individu tanpa mengungkapkan posisi semua orang.
Waktu adalah pilihan desain kunci lainnya. Jika akar diperbarui terlalu jarang, itu menjadi snapshot pemasaran daripada kontrol risiko. Jika diperbarui terlalu sering tanpa perlindungan yang kuat, itu dapat dimanipulasi dengan hiasan jendela yang berumur pendek. Ritme tingkat bank dapat diprediksi, cukup sering untuk diperhatikan, dan dipasangkan dengan peringatan ketika perubahan melebihi ambang batas yang telah ditentukan.
Dalam #LorenzoProtocolBANK kasus, saya akan merumuskan keputusan seperti ini: jika janji “1:1” protokol bergantung pada komponen apa pun yang tidak sepenuhnya dan terus menerus dapat diverifikasi hanya dari keadaan on-chain, maka ya – pohon bukti-solvabilitas internal layak dibangun. Ini menjadi antarmuka yang distandarisasi untuk pemantau pihak ketiga, meja risiko, dan pemegang biasa untuk memvalidasi backing dan kewajiban tanpa meminta kepercayaan.
Tetapi saya juga akan ketat tentang ruang lingkup. Pohon tidak boleh menggantikan perlindungan inti seperti jalur penebusan deterministik, kebijakan finalitas peristiwa, transparansi peran, dan batasan peningkatan. Pohon adalah lapisan visibilitas; protokol masih membutuhkan lapisan penegakan yang mencegah kebangkrutan terjadi sejak awal.
Kesimpulan saya sederhana: Lorenzo tidak membutuhkan pohon cadangan karena terdengar bertanggung jawab; ia membutuhkan satu jika itu secara material mengurangi kepercayaan yang tidak dapat diverifikasi. Dan jika ia membangun satu, ia harus berkomitmen pada aset dan kewajiban, menerbitkan definisi yang jelas, mendukung verifikasi pengguna, melindungi privasi, dan mengaitkan semuanya pada invariants on-chain – sehingga “1:1” tetap menjadi properti yang dapat diperiksa pasar, bukan janji yang harus diyakini.
@Lorenzo Protocol #LorenzoProtocol #lorenzoprotocol $BANK
