#dusk $DUSK 翻 DUSK 的 XSC(可扩展安全合约)时,最先让我停下来的不是它能发什么类型的证券,而是它想把合规逻辑写进合约本身,而不是放在链下的法律文件里。$SNDKB
Tokenisasi sekuritas tradisional, apa pun standar token kepatuhannya, pada dasarnya adalah "pencatatan di rantai, penegakan di luar rantai": aturan transfer, daftar putih, klausul penguncian dikendalikan oleh protokol dan dokumen hukum di luar rantai, sedangkan token di rantai hanya menjadi bukti pembukuan. Begitu muncul sengketa, jalur pertanggungjawaban kembali ke sistem hukum tradisional; data di rantai paling-paling hanya bagian dari rangkaian bukti. XSC ingin melakukan yang sebaliknya: aturan ditanam langsung ke dalam lapisan eksekusi kontrak. Transfer itu sendiri membawa validasi kondisi; siapa yang boleh memegang, apakah bisa dipindahtangankan, dan kondisi apa yang akan menyebabkan pembekuan—semuanya diselesaikan di rantai. Secara teori, ini dapat mengurangi keterlambatan penegakan di luar rantai.$SPCXB
Namun ada satu masalah yang mudah terlewat: begitu aturan kepatuhan ditulis ke dalam kontrak, fleksibilitas aturan menjadi risiko inti. Interpretasi regulator bisa berubah, daftar KYC diperbarui, dan kebutuhan kepatuhan lintas negara mungkin menyesuaikan dengan yurisdiksi. Jika pembaruan aturan mengharuskan redeploy atau migrasi aset, biaya operasional dan risiko hukum tidaklah kecil; jika mempertahankan antarmuka yang bisa diupgrade, itu justru berubah menjadi bentuk lain dari backdoor terpusat—siapa yang bisa mengubah aturan, apakah perubahan aturan akan memengaruhi aset yang sudah ada. Ini memiliki struktur kontradiksi yang sama dengan kontroversi "kunci regulator" di buku besar privasi.
Kalau dipikirkan lebih jauh, ketika XSC berkoordinasi dengan Phoenix/Moonlight yang memakai dua buku besar, letak terjadinya validasi kepatuhan sangat penting. Jika validasi dilakukan di lapisan transparan, transfer di lapisan privasi benar-benar mengungkap identitas pihak yang terlibat, sehingga privasi hanya menjadi pernyataan di kertas; jika validasi sepenuhnya dilakukan di lapisan privasi dengan bukti pengetahuan nol, efisiensi dan latensi pun harus dikorbankan. Pilihan ini sejauh ini belum saya lihat penjelasan teknis yang jelas.
Saya merasa XSC yang paling kurang sekarang bukanlah promosi skenario aplikasinya, melainkan sebuah contoh nyata kasus peningkatan aturan: bagaimana ia menangani aset yang sudah ada ketika terjadi perubahan dalam interpretasi regulator. Inilah poin kunci untuk menilai apakah standar ini bisa bertahan untuk aset dunia nyata.
#dusk @Dusk
Tokenisasi sekuritas tradisional, apa pun standar token kepatuhannya, pada dasarnya adalah "pencatatan di rantai, penegakan di luar rantai": aturan transfer, daftar putih, klausul penguncian dikendalikan oleh protokol dan dokumen hukum di luar rantai, sedangkan token di rantai hanya menjadi bukti pembukuan. Begitu muncul sengketa, jalur pertanggungjawaban kembali ke sistem hukum tradisional; data di rantai paling-paling hanya bagian dari rangkaian bukti. XSC ingin melakukan yang sebaliknya: aturan ditanam langsung ke dalam lapisan eksekusi kontrak. Transfer itu sendiri membawa validasi kondisi; siapa yang boleh memegang, apakah bisa dipindahtangankan, dan kondisi apa yang akan menyebabkan pembekuan—semuanya diselesaikan di rantai. Secara teori, ini dapat mengurangi keterlambatan penegakan di luar rantai.$SPCXB
Namun ada satu masalah yang mudah terlewat: begitu aturan kepatuhan ditulis ke dalam kontrak, fleksibilitas aturan menjadi risiko inti. Interpretasi regulator bisa berubah, daftar KYC diperbarui, dan kebutuhan kepatuhan lintas negara mungkin menyesuaikan dengan yurisdiksi. Jika pembaruan aturan mengharuskan redeploy atau migrasi aset, biaya operasional dan risiko hukum tidaklah kecil; jika mempertahankan antarmuka yang bisa diupgrade, itu justru berubah menjadi bentuk lain dari backdoor terpusat—siapa yang bisa mengubah aturan, apakah perubahan aturan akan memengaruhi aset yang sudah ada. Ini memiliki struktur kontradiksi yang sama dengan kontroversi "kunci regulator" di buku besar privasi.
Kalau dipikirkan lebih jauh, ketika XSC berkoordinasi dengan Phoenix/Moonlight yang memakai dua buku besar, letak terjadinya validasi kepatuhan sangat penting. Jika validasi dilakukan di lapisan transparan, transfer di lapisan privasi benar-benar mengungkap identitas pihak yang terlibat, sehingga privasi hanya menjadi pernyataan di kertas; jika validasi sepenuhnya dilakukan di lapisan privasi dengan bukti pengetahuan nol, efisiensi dan latensi pun harus dikorbankan. Pilihan ini sejauh ini belum saya lihat penjelasan teknis yang jelas.
Saya merasa XSC yang paling kurang sekarang bukanlah promosi skenario aplikasinya, melainkan sebuah contoh nyata kasus peningkatan aturan: bagaimana ia menangani aset yang sudah ada ketika terjadi perubahan dalam interpretasi regulator. Inilah poin kunci untuk menilai apakah standar ini bisa bertahan untuk aset dunia nyata.
#dusk @Dusk
XSC规则该链上还是链下管
0%
规则可升级算不算新后门
50%
合规校验放哪层更合理
50%
2 Voting • Voting ditutup