撸毛研究院

#dusk $DUSK @Dusk Menatap dokumen milik Dusk hampir empat puluh menit, aku terus memikirkan satu pertanyaan: pada akhirnya, dua perangkat—Moonlight dan Phoenix—ini akan berakhir seperti apa?

Moonlight memilih jalur akun publik. Saldo, pengirim transfer, penerima, dan jumlahnya semuanya tertulis di rantai; siapa pun bisa melihat. Ini cocok untuk skenario seperti top up bursa atau rekonsiliasi institusi yang menuntut transparansi.

Phoenix sepenuhnya logika yang berbeda: aset berubah menjadi catatan terenkripsi (note) dan disembunyikan di dalam pohon Merkle. Saat kamu membelanjakan sejumlah uang, kamu tidak mengekspos note spesifik yang kamu pakai, melainkan melempar nullifier beserta bukti ZKP. Jaringan dapat memverifikasi bahwa kamu punya saldo dan tidak melakukan double-spend, tetapi tidak bisa melihat jumlah maupun pengirimnya. Saat perlu audit, kamu bisa melakukan disclosure selektif melalui viewing key.

Aku sempat bersinggungan dengan masalah serupa ketika menulis catatan tentang transfer SEPA di awal bulan: rekonsiliasi antar dua sistem bank, kalau statusnya tidak sinkron itu betapa menyebalkannya—aku sampai diganggu sampai tengah malam jam dua.

Kalau blockchain juga mengotak-atik dengan dua buku besar yang terisolasi, mendingan sekalian pakai keuangan tradisional.

Saat itu aku agak kesal dan merasa penjelasan di dokumen kurang jelas tentang masalah ini. Aku membuka bagian arsitektur kontrak modul Rusk—dua paragraf pertama biasa saja, hanya menjelaskan struktur data Moonlight dan Phoenix masing-masing. Sampai aku membaca paragraf keempat: ketika melihat definisi antarmuka Transfer Contract yang memakai tipe enum untuk payload, baru aku paham maksud desainnya.

Transfer Contract adalah gerbang koordinasi. Ia menerima payload dengan format berbeda—ada yang format Moonlight, ada yang format Phoenix. Kontrak tidak peduli kamu datang dari mana; yang penting adalah field apa saja yang dibawa oleh payload, lalu dia merutekannya ke logika verifikasi yang sesuai. Verifikasi Moonlight langsung membaca status akun publik, sedangkan verifikasi Phoenix menjalankan ZK proof. Setelah kedua verifikasi berhasil, hasilnya ditulis ke dalam satu pohon status global yang sama.

Aku baru benar-benar mengerti bagian kuncinya setelah memikirkannya cukup lama: jika dua pohon status digabung menjadi satu, maka ketika kamu mentransfer dana dari akun publik ke privasi note, pada dasarnya itu hanya konversi format payload—tidak perlu jembatan lintas-chain, tidak perlu protokol sinkronisasi yang rumit. Pembaruan status bersifat atomik: semuanya berhasil atau semuanya gagal dan di-rollback.

#dusk $DUSK @Dusk 2026年7 Januari, peluncuran mainnet Dusk. Enam tahun mengasah sebuah Layer 1 khusus untuk privasi pada keuangan yang teregulasi, didukung oleh pembuktian zero-knowledge PLONK. Waktu itu aku lihat postingan, lihat sekilas lalu geser saja.

Yang benar-benar membuatku tidak bisa tenang adalah akhir April. Saat itu aku iseng browsing di Discord Dusk, lalu ada yang membagikan tautan laporan OtterSec. Begitu kubuka, astaga—rasanya merinding.

Laporan itu bilang ada lubang besar pada verifikator dusk-plonk—di persamaan verifikasi final, verifikator secara langsung memakai evaluasi polinomial dari empat polinom pilihan yang diberikan oleh prover, tapi tidak pernah melakukan pembukaan KZG untuk evaluasi-evaluasi tersebut. Bayangin konsepnya apa? Prover bisa mengatur empat nilai itu menjadi angka apa pun yang membuat persamaan lolos, dan verifikator tinggal menerimanya begitu saja. Penyerang bisa memalsukan bukti zero-knowledge secara sewenang-wenang, melewati semua constraint di sirkuit transaksi, lalu langsung mencetak DUSK. Waktu itu seluruh lapisan privasi Dusk melindungi sekitar 60 juta dolar.

Aku setengah percaya setengah ragu, jadi aku coba bongkar sendiri: membaca paper PLONK, lalu mengorek kode sumber Dusk di GitHub. Intinya begini: PLONK memecah sirkuit menjadi serangkaian gerbang (gates). Setiap gerbang punya input kiri, input kanan, dan output. Tiap gerbang menerapkan sebuah constraint, lalu PLONK menggunakan nilai polinom pilihan (misalnya set q_M=1 untuk gate perkalian, set q_L=1 untuk suku penjumlahan) untuk menyatukan semua tipe gerbang ke dalam satu ekspresi. Persamaan verifikasi harus memastikan bahwa nilai polinom pilihan itu cocok dengan komitmen yang tepercaya di kunci verifikator. Nah, dusk-plonk sama sekali tidak melakukan pengecekan ini. Artinya, seperti satpam tidak pernah memeriksa identitasmu—kalau kamu bilang siapa kamu, ya itulah yang dianggap benar.

Dulu aku selalu merasa, teknologi zero-knowledge yang berulang kali dipalu di akademisi, secara matematis pasti aman, lalu secara engineering tinggal ikut aman. Kali ini aku baru sadar: seluruh rantai privasi itu kotak hitam, dan celah logika sama sekali tidak bisa disentuh dari luar. Bukti matematis hanya menjawab “bisa atau tidak bisa membuktikan”, sedangkan “apakah pembuktian itu diverifikasi dengan benar” itu urusan lain—celah di antaranya selebar bisa buat pacuan kuda.

Aku juga baca kembali laporan audit Porter Adams sebelumnya, dan di sana hanya diberi tanda dua masalah berisiko rendah—celah “kurang menulis satu baris pengecekan” seperti ini jelas tidak tercakup.

Respons Dusk tidak terlalu lambat; mereka sudah mengirim perbaikan pada tanggal 14 Februari. Di NPEX, aset nyata bernilai ratusan juta euro sedang berjalan, jadi aku tidak keberatan dengan arah besarnya. Tapi ke depannya, kalau ada yang lagi-lagi membahas “privacy chain” dengan nada meyakinkan, pertanyaan pertama yang pasti kubuat adalah: kode verifikasi kalian, sebenarnya memverifikasi atau tidak?

#dusk $DUSK @Dusk Beberapa hari lalu saya mencoba menjalankan node Dusk. Setelah menginstal node-installer, saat menekan perintah start, tangan saya sempat ragu di tombol Enter. Bukan karena takut salah langkah, tapi karena khawatir kejadian yang sama seperti beberapa kali sebelumnya—log bergulir beberapa baris lalu macet, lalu saya baru sadar dokumen dan kode tidak cocok.

Setelah dijalankan, rusk mulai mengalirkan log. Tahap Validation dan Ratification dieksekusi bergantian. Validation dulu: sekelompok anggota komite memeriksa validitas blok kandidat; lalu Ratification menyusul: kelompok komite lain mengonfirmasi hasil verifikasi dan akhirnya menetapkan blok. Di log, setiap putaran diberi penanda Round dan nomor Iteration, dan jeda antarbloknya stabil. Saya menatap layar lebih dari sepuluh menit—tinggi blok terus naik, tidak pernah berhenti. Bayangan “macet di tengah pengguliran” saat menjalankan testnet-testnet lain beberapa kali sebelumnya akhirnya hilang di sini.

Kemudian saya membuka repositori rusk. Ada 8025 commit, pipeline CI menjalankan clippy dan nightly test, dan timnya juga membuat sendiri cargo-dusk-analyzer untuk analisis statis. Di tool deploy dsk-deploy-cli, saya menemukan detail: parameter command line Phoenix dan Moonlight dipisahkan. Untuk dua jalur transaksi yang berbeda dalam satu chain, keduanya dipanggil secara independen. Saya menemukan data gas yang diposting di sebuah issue: transfer Moonlight sekitar 80 ribu gas; dari Moonlight ke Phoenix memerlukan 25,56 juta gas—selisihnya sekitar 300 kali. Inilah biaya komputasi sebenarnya dari pembuktian ZK.

Lalu saya memeriksa layer jaringan. Kadcast adalah implementasi Rust resmi, dan dari 107 repositori semuanya Rust. Repositori plonk juga punya 872 commit yang ditulis sendiri oleh tim—bukan sekadar ambil library jadi lalu dimodifikasi sedikit lalu langsung dipakai.

Setelah itu saya menelusuri latar belakang NPEX. NPEX adalah bursa di Belanda yang diawasi AFM, memegang lisensi MTF, Broker, dan ECSP, serta mengelola aset senilai 300 juta euro. Daftar kandidat Dusk Trade sudah dibuka—mereka memang sedang membangun platform perdagangan RWA.

Dari 2018 sampai sekarang, tujuh tahun—8025 commit, 107 repositori, semuanya Rust. Disiplin rekayasa seperti ini, saya benar-benar salut.

#dusk $DUSK @Dusk
Tadi malam begadang sampai jam tiga sambil membongkar kode Dusk, makin lama makin merinding—bukan karena takut, tapi karena kagum dengan kedalaman teknologinya. Dulu aku mengira $DUSK cuma semacam privasi chain biasa; padahal arsitekturnya sama sekali beda dengan Zcash.

Intinya ada model dua transaksi: Phoenix memakai note-based plus ZK proof, menyembunyikan nominal dan lawan transaksinya; Moonlight memakai jalur akun transparan, untuk kebutuhan audit dan kepatuhan regulator. Dua jalur berjalan paralel—privasi dan kepatuhan tidak saling meniadakan. Tim sistem pembuktian PLONK menulisnya dari nol dengan Rust; GitHub 633 bintang, mereka menambah custom gate dan optimasi hashing untuk POSEIDON. Aku baca sirkuitnya baris demi baris—desainnya memang berisi, bukan cuma template.

Citadel SDK mengerjakan verifikasi KYC level ZKP, dan mereka juga berinvestasi di Outdid yang memakai NFC plus verifikasi identitas dengan zero-knowledge untuk paspor. Lapisan konsensusnya internal: SBA—protokol isolasi Byzantine, dan mekanisme blind bidding untuk menyalurkan hak staking membuat node yang menerbitkan bloknya sendiri tetap anonim. Piecrust VM menjalankan kontrak WASM; versi 2.0 meningkatkan kecepatan hingga 500%. Kadcast membangun lapisan propagasi P2P, 107 repo semuanya diimplementasikan dalam Rust, dengan disiplin engineering yang kuat.

Partner pun sudah memverifikasi: NPEX adalah MTF berlisensi AFM Belanda, dan Quantoz menerbitkan EURQ yang patuh MiCA. Ini benar-benar mengintegrasikan untuk settlement yang sesuai MiFID II, bukan sekadar janji manis.

#dusk $DUSK @Dusk Kemarin saya melihat sebuah pesan: platform NPEX meluncurkan sebuah solusi kustodi berbasis Dusk. Saya kemudian terus menggulir dan makin lama makin terasa menarik. Ini berbeda dari semua solusi kustodi yang ada di pasaran—aset berada di rantai, kunci privat ada di tangan Anda sendiri, dan regulasi pun masih bisa dicek.

Saya belum pernah melihat hal seperti ini sebelumnya.

Bagi yang sudah paham industri kustodi, biasanya hanya ada dua jalur. Pertama: Anda menyerahkan kunci privat ke penyedia kustodi pihak ketiga, sehingga memenuhi kebutuhan regulasi, tetapi secara substansi aset tidak lagi sepenuhnya berada di tangan Anda. Kedua: Anda mengelola kunci privat sendiri—aman memang—tapi ketika regulator menanyakan kepatuhan, Anda tidak bisa membuktikan bahwa Anda benar-benar patuh. Jadi, akhirnya harus memilih salah satu; tidak ada opsi ketiga.

Dusk bersama Cordial yang mendorong skema kustodi zero-trust ini menjalankan jalur ketiga tersebut. Ini bukan kustodi pihak ketiga, melainkan sebuah teknologi wallet self-custody bernama Cordial Treasury. Institusi menerapkan sendiri, mengelola sendiri; kunci privat selalu tetap berada di hardware wallet milik institusi. Ketika NPEX—sebagai bursa yang berizin—menjalankan skema ini, regulator bisa memverifikasi apakah posisi institusi sudah sesuai melalui bukti zero-knowledge. Setelah verifikasi selesai, regulator pergi begitu saja—mereka tidak bisa menyentuh kunci privat.

Anda tidak perlu menyerahkan kunci. Anda juga tidak perlu menampilkan aset Anda ke semua orang. Anda bisa membuktikan Anda memenuhi aturan, tanpa harus membongkar seluruh harta.

Dua simpul rumit yang sudah mengikat selama sepuluh tahun—“self-custody” dan “kepatuhan”—akhirnya untuk pertama kalinya diurai.

Saya sebelumnya selalu merasa bahwa bukti zero-knowledge masih jauh dari penerapan dunia nyata. Saya kira itu urusan kalangan akademik. Kali ini Dusk justru menyelipkannya ke dalam skenario kustodi yang benar-benar nyata, dan dijalankan di sebuah platform yang teregulasi. Bukan sekadar proof of concept atau testnet—ini benar-benar digunakan.

Peristiwa ini membuat saya mengubah pandangan terhadap Dusk. Sebelumnya, saat saya melihat konsensusnya, arsitekturnya, hingga model ekonominya, saya mengira semuanya adalah hal-hal teknis. Tapi skema kustodi ini menunjukkan bahwa mereka sedang menjawab masalah spesifik dan sudah lama—yakni bagaimana “kepercayaan” seharusnya dibangun ulang di blockchain.

Jawaban Dusk adalah: kepercayaan tidak dibangun dengan menyerahkan kendali, melainkan dengan memastikan sesuatu dapat diverifikasi. Anda tidak perlu menyerahkan kunci, tapi Anda tetap bisa membuat orang percaya.

#termmax @TermMax Minggu lalu saat merapikan posisi, secara tidak sengaja saya langsung membuka pasar TermMax di dua chain sekaligus: BNB Chain dan Arbitrum. Untuk aset USDC yang sama, dengan tenor 30 hari yang sama, serta aturan protokol yang sama, selisih APR-nya berbeda cukup jauh—lebih dari sekadar “satu poin” saja. Respons pertama saya adalah, “Apa saya salah lihat?” Saya menyegarkan panel transaksi sampai tiga kali, lalu mengeluarkan 127 catatan transaksi dalam 30 hari terakhir, mengecek nilai slippage satu per satu untuk memastikan bukan masalah cache. Ternyata memang APR-nya tidak sama.

Pada saat itu, yang terpikir di kepala saya: ini tidak mungkin. Protokol dan produk yang sama, tapi kenapa harga di chain yang berbeda bisa menghasilkan angka yang berbeda? Setelah itu saya mulai curiga mungkin ada sesuatu yang saya lewatkan. Saya pergi membaca dokumentasi resmi dan menemukan bahwa TermMax saat ini tersedia di 8 chain: Ethereum, Arbitrum, BNB Chain, Base, Berachain, dan lainnya. Setiap chain memiliki pool dana yang berjalan independen—modul penetapan harga tidak melakukan sinkronisasi data lintas-chain. Market maker dan pengguna yang melakukan aktivitas pinjam di tiap chain membentuk hubungan penawaran-permintaan yang berbeda, sehingga otomatis menghasilkan kurva APR yang benar-benar berbeda. Di bagian ini saya akhirnya lega: bukan karena saya menghitungnya salah—arsitektur inilah memang seperti itu.

Tapi muncul masalah baru: apakah ini bisa dijadikan strategi? Saya pernah terpeleset oleh “fake arbitrage” lintas-chain—yang terlihat ada selisih menguntungkan, tapi begitu dieksekusi langsung dimakan habis slippage. Kali ini saya sengaja mengecek ulang alamat kontrak pool dana di dua chain, memastikan keduanya adalah pool terisolasi yang benar-benar independen, tanpa shared liquidity. Jadi tidak ada mekanisme tersembunyi seperti “kelihatannya beda satu poin, lalu saat lintas-chain selisihnya langsung tergerus.”

Hari itu saya langsung transfer 3.000 U untuk uji coba, tanpa mondar-mandir pakai cross-chain bridge. Saya memakai agregator LI.FI: dari BNB Chain langsung ke Arbitrum. Setelah dana masuk, saya cek sekilas—biaya gas terpotong kira-kira beberapa U, lalu sisanya seluruhnya ditaruh ke pasar dengan APR tinggi di sana. Tidak pakai leverage, tidak menyentuh kontrak apa pun—murni logika paling sederhana: simpan di chain yang harganya lebih rendah, pinjam di chain yang harganya lebih tinggi. Setelah satu putaran selesai, hasilnya menambah sekitar mendekati satu poin persentase APR secara ekstra. Tidak besar, tapi stabil. Tidak ada tambahan risiko kontrak pintar, murni mengambil peluang dari ketidaksesuaian penawaran-permintaan dana di dua chain.

Kebanyakan orang tidak menyadari mispricing yang muncul dari independent funding pool seperti ini. Ini bukan bug—melainkan cerminan langsung dari hubungan penawaran dan permintaan nyata yang berbeda di tiap chain.

#dusk $DUSK @Dusk Saat tengah malam tidak bisa tidur, membaca buku putih, lalu sampai ke halaman tentang verifikator KYC—saya benar-benar blank. Bukan karena isinya membuat saya terpesona, tapi karena tiba-tiba saya memikirkan satu hal: berani nggak ya saya menaruh uang di sebuah chain yang benar-benar anonim? Pikir sepuluh detik, jawabannya: tidak berani. Lalu saya sadar, institusi yang mengelola ratusan miliar dolar itu, kemungkinan besar juga sama seperti saya: tidak berani.

Tiba-tiba terbayang skenario: kalau saya benar-benar menaruh uang di chain anonim, keesokan harinya pool-nya dikuras habis, lalu saya berteriak ke alamat dompet itu, “kembalikan uang saya”. Kalau pihak sana bahkan bisa membalas, “saya anonim”, ya saya anggap dia lumayan sopan. Setelah itu bagaimana? Tidak ada kelanjutannya. Di perbankan tradisional, uang Anda berkurang sedikit saja Anda bisa telepon, bisa datang ke kantor dan mengamuk, bisa menggugat. Di chain, yang bisa Anda lakukan cuma menatap browser penjelajah blockchain sambil bengong ke alamat itu.

Dusk meminta verifikator untuk identitasnya nyata. Kelihatannya seperti kemunduran dari desentralisasi, tapi kalau dipikir-pikir dari kacamata institusi, mereka sebenarnya tidak menginginkan anonimitas bebas—mereka ingin, kalau terjadi masalah, ada manusia yang bisa dicari.

Kemudian saya paham: Dusk tidak murni anonim dan tidak juga sepenuhnya terbuka. Yang mereka butuhkan adalah “sikap antara”—Anda bisa membuktikan siapa Anda, tapi tidak perlu menempelkan KTP di wajah. Sistem identitas Citadel dipadukan dengan proof tanpa pengetahuan (zero-knowledge proof) melakukan hal ini; rasanya seperti masuk klub kelas atas: satpam di pintu tahu siapa Anda, tapi para tamu di dalam tidak perlu saling mengorek urusan pribadi.

Dengan dukungan kerangka regulasi seperti MiCA dan MiFID II, rencananya ternyata lebih kompleks dari yang semula saya bayangkan—dan juga jauh lebih realistis.

Pada 7 Januari 2026, mainnet resmi diluncurkan. Masa pengembangan enam tahun akhirnya benar-benar terealisasi. DuskEVM juga sudah berjalan sinkron. Developer Solidity bisa langsung membangun di atasnya, dan komponen inti seperti DEX serta bridge lintas-chain juga sudah selesai di-upgrade. Jaringan mensyaratkan lebih dari sepertiga penyetor (staker) mematuhi aturan; yang bertindak sembarangan atau offline dalam waktu lama akan langsung dikenai penalti dengan pemotongan/penahanan stake. Waktu blok 10 detik—untuk aset tokenisasi, kecepatan ini cukup.

Dulu saat saya membaca buku putih, bab tentang mekanisme verifikator saya lewati begitu saja, merasa itu tidak ada hubungannya dengan saya. Tapi halaman Dusk ini saya bolak-balik baca berkali-kali. Bukan karena tulisannya sangat bagus, melainkan karena membuat saya paham satu hal: menilai apakah sebuah proyek itu bagus atau tidak, bukan dari seberapa lantang slogan mereka, melainkan dari apakah mereka berani menyelesaikan lebih dulu urusan “tidak berani” yang dipikirkan pengguna.

#termmax @TermMax buku putih Bagian 6 punya satu detail: membandingkan pencocokan fixed-rate (suku bunga tetap) dan floating-rate AMM, untuk membuktikan “lebih stabil”. Namun kalau diteliti lebih dalam, keamanan pembayaran kembali pada pool berdurasi tunggal dan efisiensi likuidasi terikat erat.

Kita bisa lihat bahwa LTV mencapai ambang batas akan dipicu otomatis oleh Chainlink, dengan jendela waktu 2 jam untuk pembukaan. Siapa pun yang ikut likuidasi akan mendapat bonus 5%. Setelah sebagian likuidasi, aset jaminan yang tersisa akan dikembalikan ke peminjam; hanya ketika dalam jendela 2 jam tersebut belum dilakukan likuidasi sepenuhnya, barulah dipicu penyelesaian fisik—pemegang FT memperoleh aset jaminan secara proporsional. Masalahnya ada pada 2 jam itu—dalam kondisi ekstrem, harga bisa kembali jatuh menembus lapisan berikutnya. Jika likuidator memilih menunggu, piutang macet akhirnya ditanggung oleh seluruh pengguna di pool. Buku putih menyebut “physical settlement” sebagai jaminan, tapi pada dasarnya itu membayar dengan imbal hasil lenders untuk menukar aset jaminan, jadi bukan tanpa kerugian.

Seperti jendela diskon untuk barang segar menjelang kedaluwarsa selama 2 jam: saat kondisi normal aman, tapi saat terjadi penurunan tajam, bisa jadi tidak cukup atau malah terbuang. TermMax justru mengunci dilema ini: jendela terlalu pendek membuat likuidasi tidak tuntas, terlalu panjang membuat akumulasi piutang macet—tidak ada yang benar-benar sempurna.

Buku putih mengatakan otoritas dibatasi pada parameter seperti kurva suku bunga dan fee rate, sementara likuidasi ditentukan oleh oracle dan eksekutor. Tapi parameter adalah kepentingan—denda likuidasi 10%, dengan 5% untuk likuidator dan 5% masuk ke treasury cadangan protokol. Penggunaan treasury ditentukan oleh tata kelola TMX, dan inilah titik yang perlu diperhatikan. Kabar baiknya, protokol menerapkan mekanisme penyeimbang: perubahan parameter kunci harus melalui masa penundaan timelock (paling cepat 1 hari, paling lama 30 hari), selama itu pengawas bisa meninjau dan membatalkan. Namun ketika suara terkonsentrasi, arah tata kelola tetap bisa condong ke pihak pemegang besar—mekanisme penyeimbang hanya bisa menunda, tidak bisa membalik.

Kalau kamu bertanya pendapat saya, intinya jangan terpancing oleh “rumus” matematika dari fixed-rate. Setiap pengaturan parameter adalah pembagian kepentingan. Jika kepingan (collateral) tersebar, mekanismenya bisa mendekati tanpa risiko; kalau kepingan terkonsentrasi, itu adalah kolam dana terselubung yang tergild.
DYOR, perhatikan siapa yang menetapkan parameter dan bagaimana cara mengubahnya. Jendela likuidasi dibuat untuk memberi jaminan lebih stabil bagi pengguna, atau untuk memberi ruang operasi bagi pemegang besar? Lihat komentar.

#dusk $DUSK Minggu ini saya meninjau ulang materi milik @Dusk . Awalnya saya ingin lebih dulu membaca narasi privasinya, tapi ternyata bagian yang paling lama saya telusuri justru batas-batas pengungkapannya.

Dulu saya selalu merasa inti dari perjanjian privasi adalah “menyembunyikan”. Selama enkripsi, anonimitas, dan pembuktian cukup kuat, sistem bisa berjalan. Tapi setelah melihat lebih dalam, saya menemukan masalah yang lebih realistis bukanlah “bisa atau tidak menyembunyikan”, melainkan: pada kondisi apa informasi itu wajib dilihat.

Dusk menempatkan privasi dan kepatuhan dalam satu paket; pada dasarnya, itu mengejar pengungkapan yang dapat dikendalikan. Keuntungannya jelas: institusi tidak perlu mengorbankan efisiensi on-chain demi kepatuhan, dan pengembang juga tidak harus memasukkan semua logika ke dalam satu struktur terpadu yang berat. Namun biayanya mulai terlihat juga: informasi mana yang bisa dipertahankan, mana yang harus diungkapkan, diungkapkan kepada siapa, dan sejauh apa tingkat butirannya—semua itu tidak bisa langsung diselesaikan hanya dengan frasa “teknologi privasi”. Yang benar-benar sulit bukanlah enkripsinya, melainkan siapa yang memegang kendali atas hak untuk mengungkap.

Kekakuan titik senyap ini sebenarnya mirip sekali dengan skenario yang paling umum di dunia kripto. Banyak proyek suka membicarakan “perlindungan privasi”, tapi ketika benar-benar diterapkan, yang pertama muncul biasanya bukan masalah teknis, melainkan masalah kontrol. Siapa yang menentukan kapan informasi dibuka, dialah yang mendapatkan hak penafsiran baru; siapa yang menguasai pengecualian, dialah yang berpotensi menjadi titik pusat yang baru. Secara permukaan ini tampak ramah kepatuhan, tetapi jika dilihat lebih dalam, itu juga bisa menarik kembali “privasi tanpa sentralisasi” ke dalam struktur berbasis persetujuan.

Saya tidak menyangkal bahwa desain seperti ini memiliki nilai. Pada fase cold start, pasti ada yang harus menulis draf aturan lebih dulu, sama seperti saat rumah baru selesai dibangun, Anda perlu menentukan sistem akses pintu dan hak pengunjung sejak awal. Tapi di kripto ada terlalu banyak proyek yang mengemas “pengungkapan yang dapat dikendalikan” sebagai jawaban universal; pada akhirnya yang terjadi hanya menambahkan lapisan otorisasi yang lebih kompleks. Yang paling layak dicermati dari Dusk sekarang bukan apakah ia bisa menjelaskan privasi dengan bagus, melainkan apakah ia akan menjadikan hak pengungkapan sebagai pusat yang baru.

Arsitektur teknis bisa diaudit, tetapi pembagian kekuasaan di balik batas-batas pengungkapan jauh lebih sulit diaudit. DYOR: privasi bisa dienkripsi, tetapi batasnya tidak akan hilang dengan sendirinya. Menurut Anda, pengungkapan yang dapat dikendalikan—pada akhirnya—akan berubah menjadi pintu masuk sentralisasi yang baru?

#dusk $DUSK @Dusk 这几年看链上协议出问题，我养成了一个习惯：不太关心黑客有没有暴力破解，反而先看掌握网络共识安全的核心组件，到底靠什么机制把验证者死死按住了。见过太多节点作恶，根子不是算法被攻破，是共识设计从一开始就默认“验证者会老实听话”，这个默认只要失效一次，罚没机制就会沦为空谈。

最近拆解 Dusk 的 SA 共识与 Slashing 设计时，让我停下来的正是这一层。@Dusk

Dusk 的 Succinct Attestation（SA）共识采用委员会型 PoS 模型，通过确定性抽签算法选出出块者和投票委员会。它把恶意行为和过失行为分开处理，对应 Hard Slashing 和 Soft Slashing 两套机制。Soft Slashing 针对节点未出块这类非恶意过失——第一次警告，之后每次连续违规扣除 N×10% 的质押权益并从共识中移除 N 个 epoch，但罚没的 DUSK 不销毁，只是从活跃质押中移除，节点仍可提取。Hard Slashing 则针对明确恶意行为：生成无效区块扣 10% 质押并销毁，双重投票或双倍出块扣 20% 并销毁。这套设计让 Dusk 具备可追责性，但验证者一旦作恶代价极重。

我也不会把它捧上天。架构再精妙，如果验证者为了降低运维成本而集中托管节点，或者长期在线率低于 95% 触发 Soft Slashing 累积扣减，协议精心构建的安全边界就会面临真正考验。未来若为了省事把验证节点集中在少数几个实体手里，所谓的“去中心化”就只剩心理安慰。

在我看来 $DUSK 的价值最终看有多少验证者愿意为了安全牺牲便利。以后合规资产上链会越来越多，我更在意的不是收益率有多高，是谁能证明在巨大的利益诱惑面前，这套让作恶者付出真金白银代价的机制依然能被严格执行。

#termmax @TermMax Saat menelusuri log interaksi on-chain TermMax Mainnet V2, yang pertama kali membuat saya berhenti bukanlah data kenaikan TVL menembus angka satu miliar—melainkan cara mereka memisahkan “pengumpulan dana” dan “perhitungan bunga saat jatuh tempo” menjadi dua domain izin yang sepenuhnya independen.
Aset yang masuk terlebih dahulu ditempatkan di Public Deposit Pool: akun penampung yang hanya mendukung deposit dan penarikan, tidak bisa langsung menghasilkan posisi berbunga. Jika ingin berpartisipasi dalam strategi pendapatan tetap, pengguna harus secara manual memindahkan jumlah tertentu ke Term Segment yang sesuai dengan tanggal jatuh temponya. Langkah ini otomatis memicu verifikasi validasi time-lock di chain, tanpa ada celah/backdoor untuk dilewati. Dana seluruhnya tetap berada di kolam statis yang terisolasi; izin untuk perhitungan bunga dibuka lewat “pintu eksekusi” yang terpisah.
Saya sering melihat logika otorisasi seperti ini di sistem kustodian fixed income sekuritas. Saat sebelumnya membantu teman mengerjakan outsourcing sistem manajemen aset, bagian “isolasi dana” saja sudah mengubah kebutuhan sampai tiga versi. Untuk institusi yang mengelola dana bernominal besar, penyaluran dana dan kliring bunga produk tidak pernah menggunakan kunci (key) yang sama. Namun mayoritas protokol pinjam-meminjam di on-chain mengasumsikan alamat wallet sama dengan seluruh izin operasi. Bulan lalu di grup ada rekan yang kunci privatnya bocor; USDC separuh posisinya langsung dipindahkan tanpa bisa dia追回 (bahkan tempat untuk banding pun tidak ada). Di dokumen TermMax, TBAC time-based access control yang mereka cantumkan memakai pendekatan isolasi seperti ini—dan sangat berbeda dari sistem izin global yang seragam ala Aave. Bahkan multisig tata kelola pun tidak diberi izin untuk mengubah parameter jatuh tempo Term Segment; setiap langkah operasi hanya diberi izin minimal yang memang seharusnya.
Mengikuti garis ini ke arsitektur primitive “fixed-to-maturity”, logikanya benar-benar konsisten. Lapisan produk di level atas membuka interface untuk memperluas ragam permainan dengan berbagai instrumen pendapatan terstruktur; sementara lapisan kliring di bagian bawah sepenuhnya berpatokan pada modul Term Auction (lelang Belanda) untuk eksekusi on-chain final. Dana yang profesional tidak perlu mengorbankan isolasi aset demi stabilitas imbal hasil, dan semua status saat jatuh tempo bisa diverifikasi oleh semua node.
Menurut saya, yang benar-benar diselesaikan TermMax untuk dana bernominal besar bukanlah imbal hasil tahunan yang “lebih tinggi”, melainkan seperangkat aturan batas waktu yang bisa sepenuhnya dipercaya.
Tentu saja, jika pada kondisi pasar ekstrem banyak posisi jatuh tempo secara serentak, apakah sistem sanggup menahan tekanan kliring terpusat masih perlu diamati. Namun gagasan desain ini membuat saya merasa, agar fixed income on-chain bisa menampung volume dana yang lebih besar, ini tidak sesederhana “bersaing di yield saja”.

#termmax @TermMax Selesai membaca dokumentasi teknis TermMax V2, dan yang paling menusuk bagi saya sebenarnya adalah kalimat yang saya lihat saat mengelap layar semalam—sambil duduk di sofa menunggu, saya mengunyah dokumen, setengah gelas es cola tumpah ke keyboard. Begitu saya mengelap layar, barulah saya menyadari penjelasan itu yang cukup mudah terlewat: TermMax sendiri bukan produk pinjaman, melainkan sebuah primitive aset jatuh tempo tetap; produk yield yang sebenarnya dan alat-alat terstruktur adalah yang dipasang/ditambahkan dari luar.

Saat itu saya mengelap noda cola sambil menatap layar, sempat bengong setengah menit. Setelah saya lanjut baca ke bawah, barulah saya paham: begitu sebuah kontrak pinjaman dengan jangka waktu tetap dibuat, waktu jatuh tempo, ambang likuidasi, dan jenis mata uang untuk settlement langsung “dikunci” di atas rantai (on-chain), bukan disimpan dulu lalu kemudian parameter diubah secara dinamis. Intinya, kontrak ini sejak lahir sudah tahu kapan dia jatuh tempo, bagaimana cara dilikuidasi, dan memakai settlement pakai apa—berbeda total dengan model pinjaman perpetual seperti Aave atau Compound yang biasanya “deposit dulu, lalu suku bunga bisa berubah kapan saja, garis likuidasi bisa disesuaikan kapan saja”. Bayangan tahun lalu saat saya menyetor ETH di Aave dan tiba-tiba terkena jarum (disengat) likuidasi sampai terseret keluar separuh posisi langsung muncul lagi. Pengguna sama sekali tidak perlu khawatir tiba-tiba disuntik likuidasi di tengah jalan atau suku bunga anjlok.

Data industri mengatakan sekarang di DeFi, lebih dari 90% aktivitas pinjaman menggunakan skema perpetual dengan suku bunga mengambang, sedangkan porsi fixed income kurang dari 10%. Setelah melihat desain ini, saya kira saya mengerti kenapa fixed income dulu susah sekali diwujudkan—bukan karena pengguna tidak butuh, tapi karena primitive dasarnya belum dibuat dengan benar.

Coba ikuti produk terstruktur fixed income berjenis bertingkat yang baru diluncurkannya, akan makin jelas. Contohnya: USDC disimpan ke TermMax dalam kontrak periode tetap 90 hari. Statusnya kemudian berubah di sisi protokol strukturasi eksternal menjadi semacam sertifikat/pasar berlapis untuk imbal hasil: prioritasnya mengambil fixed interest, sedangkan lapisan subordinat (junior) menanggung/memakan excess return. Saat jatuh tempo, pokok plus bunga otomatis diselesaikan—tanpa perlu redeem manual dari pengguna. Kalau aset jaminan di bawah jatuh melampaui garis likuidasi, kontrak akan otomatis memicu likuidasi lelang ala Belanda (Dutch auction). Sepanjang proses tidak ada pemungutan suara tata kelola (governance) dan tidak butuh campur tangan manusia. Agar likuidasinya bisa semulus itu, dasarnya adalah time-lock native + modul lelang on-chain yang menuliskan logika likuidasi langsung ke lapisan kontrak. Dibanding model tradisional pinjaman yang bergantung pada pihak ketiga untuk menjadi “likuidator” yang kebut duluan, ini jauh lebih stabil, dengan biaya Gas 60% lebih rendah. Cara kerjanya juga beda total: bukan seperti pinjaman on-demand yang terus mengirim harga (real-time) dan melakukan likuidasi real-time—ini benar-benar jalur yang berbeda.

Gagasan “biarkan produk dipegang/diteruskan oleh pihak lain untuk membangun” inilah—dan pendekatan desain seperti inilah—alasan mendasar mengapa ia bisa terus melahirkan variasi produk baru tanpa harus setiap kali menciptakan roda dari nol.

#dusk $DUSK @Dusk Pertama kali saya melihat Dusk menyebut Selective Disclosure (pengungkapan selektif), saya sebenarnya tidak terlalu memikirkannya. Saat itu, pemahaman saya sangat sederhana: bukankah protokol privasi itu berarti menyembunyikan informasi transaksi? Melindungi jumlah, alamat, dan relasi transaksi agar orang lain tidak bisa melihatnya—tidakkah itu sudah memenuhi perlindungan privasi?

Sampai beberapa hari lalu, ketika saya merapikan catatan whitepaper Dusk, saya menyatukan model transaksi Phoenix dengan skenario aset yang tunduk pada kepatuhan. Saat saya membaca bagian Selective Disclosure, saya berhenti sejenak. Karena saya menyadari ada masalah yang sebelumnya saya abaikan: jika Phoenix sudah menyembunyikan status transaksi, maka bagaimana institusi, auditor, dan regulator—secara tepat—memastikan bahwa transaksi ini mematuhi aturan?

Pertanyaan ini membuat saya memahami ulang rancangan Dusk. Semula saya pikir inti privasi adalah “agar orang lain tidak melihat”. Namun setelah meneliti, saya baru sadar bahwa yang benar-benar dibutuhkan institusi bukanlah menyembunyikan sepenuhnya, melainkan mengendalikan kapan, kepada siapa, dan dengan cara apa informasi diverifikasi.

Phoenix memecahkan privasi transaksi itu sendiri. Melalui shielded notes dan zero-knowledge proofs, jaringan dapat memverifikasi validitas transaksi tanpa harus mempublikasikan saldo lengkap, relasi transaksi, dan status aset. Namun untuk aset yang teregulasi seperti sekuritas, reksa dana, dan sejenisnya, hanya menyembunyikan informasi tidaklah cukup; pasar keuangan membutuhkan audit, perlu memastikan aturan dijalankan, dan juga memerlukan bukti pada kondisi tertentu.

Di sinilah Selective Disclosure memiliki maknanya. Ini bukanlah upaya untuk merusak privasi, melainkan membangun “jalur verifikasi” di atas privasi: secara default melindungi data transaksi, dan ketika pihak yang berwenang perlu memeriksa, hanya informasi yang diperlukan yang diungkap—bukan seluruh riwayat transaksi.

Setelah menyambungkan dua mekanisme ini, barulah saya mengerti bahwa Phoenix dan Selective Disclosure bukanlah dua modul yang terpisah. Yang pertama menjawab “bagaimana menyembunyikan sekaligus membuktikan transaksi itu benar”, sedangkan yang kedua menjawab “setelah disembunyikan, bagaimana memenuhi aturan keuangan di dunia nyata”. Masalah masa lalu pada blockchain yang transparan adalah kurangnya privasi, sedangkan masalah pada keuangan tradisional adalah informasi yang bisa dikendalikan tetapi bergantung pada verifikasi terpusat.

Yang berubah bukan sekadar cara menyembunyikan informasi, melainkan batas kepercayaan dalam keuangan on-chain. Ke depan, ketika RWA benar-benar masuk ke on-chain, tantangannya tidak hanya soal penerbitan Token, melainkan bagaimana membuat aset sekaligus memenuhi privasi, kepatuhan, dan eksekusi otomatis.

#termmax @TermMax Minggu lalu saya lagi scrolling papan peringkat pendapatan hasil di chain, dan secara tidak sengaja melihat TermMax. Saat itu TVL-nya baru menyentuh sekitar 71 juta. Saya sempat menelusuri kurva suku bunga pinjamannya sampai sepuluh menit—logika produknya terasa cukup rapi, tapi karena ini proyek baru, saya tetap berpikir, "tunggu dua minggu lagi, lihat datanya dulu sampai lebih stabil, baru masuk." Lalu dengan santai saya simpan alamat kontraknya ke dompet observasi saya, dan langsung balik lagi ke urusan lain.

Minggu lalu juga, saat saya melihat dasbor data on-chain, TVL-nya sempat melonjak sampai 90 juta. Saya menatap alamat kosong di dompet observasi selama lima menit. Jari saya bahkan sudah menyentuh tombol konfirmasi transfer, tapi akhirnya saya urungkan. Saya merasa, "naik secepat ini pasti ada koreksi, tunggu saja supaya bisa dapat posisi yang lebih nyaman." Saya juga menghibur diri sendiri—bagaimanapun tidak ketinggalan momen sepenuhnya, masuk dua hari kemudian juga tidak rugi.

Tadi malam saya baca pengumuman resmi dan melihat TVL-nya secara resmi menembus 100 juta. Saya duduk, lalu menelusuri seluruh data on-chain-nya. Saat saya membuka halaman arsitektur produknya, saya benar-benar masuk ke detail—FT dibeli dengan harga diskon, lalu saat jatuh tempo ditebus kembali sesuai nilai nominal. GT mengemas aset jaminan dan utang menjadi posisi yang terpisah. Dulu kalau saya melihat protokol fixed interest, yang paling saya takutkan adalah dana menganggur: begitu memasang order, saat menunggu match, uangnya malah nyangkut dan tidak jalan. TermMax justru langsung menyambungkannya ke Morpho di lapisan bawah—saat memasang order, ia otomatis menjalankan floating yield. Begitu match berhasil, fixed interest-nya berjalan mulus. Logika ini lebih matang daripada yang saya bayangkan, tapi semakin matang, semakin saya menyesal—kenapa dulu tidak langsung saya ambil? Baru setahun diluncurkan, sudah iterasi sampai versi V2 di mainnet, sudah dideploy 10 chain EVM, dan jumlah pengguna langsung menembus 1,1 juta. Ini sama sekali bukan data menggelembung karena insentif mining jangka pendek—ini benar-benar banyak pengguna yang memakai produk pinjamannya secara intens.

Sebelumnya kalau saya trading altcoin sampai floating loss puluhan ribu, saya tidak sepedih ini. Rugi karena saya sendiri yang salah menginjak jebakan, ya sudah, keluar bisa balik lagi. Tapi penyesalan seperti ini beda total. Anda jelas sudah melihatnya sejak awal, dua kali bahkan berdiri di depan pintu mobil tapi tidak melangkah masuk, lalu melihatnya tumbuh dari "proyek baru yang punya potensi" jadi pemain utama di sebuah track. Setiap langkah pertumbuhan Anda lihat sendiri, tapi semuanya terlewat hanya karena ragu.

Sekarang saya masih menatap alamat kosong di dompet observasi, seperti orang bengong. Apakah ada pemain lama yang mau ngomong terus terang? Sekarang masih sempat naik ke $TMX, belum terlambat, bukan? @TermMax

#dusk $DUSK Dalam beberapa tahun terakhir, melihat banyak proyek “privacy chain” tumbang, aku perlahan membentuk kebiasaan: tidak terlalu peduli apakah algoritma kriptografinya sudah berhasil dipecahkan atau belum. Yang lebih dulu kulihat adalah apakah orang yang menyimpan backdoor sesuai kepatuhan itu benar-benar terikat oleh batasan. Aku sudah melihat terlalu banyak proyek privasi “meledak”; akar masalahnya bukan karena bukti pengetahuan nol (zero-knowledge proof) berhasil diserang. Intinya adalah desain perizinan sejak awal sudah secara default mengasumsikan bahwa “pihak proyek tidak akan sembarangan menyentuh data pengguna”. Asumsi itu hanya perlu sekali terbukti salah, maka aset pengguna dan data transaksi akan terbuka begitu saja—tinggal waktu.
Membongkar alur eksekusi ZkKYC versi mainnet RC dari @dusk_foundation justru yang membuatku berhenti. Bukan sekadar menambahkan satu blok kepatuhan ke privacy chain, melainkan mengubah langsung pertanyaan “siapa yang bisa melihat data saya” menjadi aturan baku yang bisa diverifikasi oleh sirkuit zero-knowledge. Sebelum pengguna mengaktifkan izin audit, aturan tersebut lebih dulu melewati verifikasi sirkuit dari modul native Citadel; kredensial identitas disimpan sendiri di lokal, status transaksi dienkripsi dengan komitmen Pedersen, dan seluruh logika verifikasi diumumkan secara terbuka di seluruh rantai. Bahkan pihak proyek pun tidak bisa mengakali sirkuit untuk langsung mengambil data pengguna. Bukti zero-knowledge memastikan proses verifikasi izin itu sendiri tidak dapat dimanipulasi; jika belum berada dalam batas otorisasi yang ditetapkan pengguna, permintaan audit apa pun tidak akan bisa mengambil data terang (plaintext).
#dusk idenya mirip seperti saat kamu mengajukan bukti kepemilikan aset ke bank: petugas tidak bisa langsung membalik seluruh mutasi rekeningmu, hanya bisa menerbitkan bukti sesuai jumlah dan tujuan yang kamu ajukan—informasi tambahan apa pun tidak bisa didapat.
Di atas rantai, sebelumnya selalu kurang “gerbang” verifikasi privasi dan kepemilikan hak ini. Yang ingin ditambahkan Dusk bukan seberapa kuat anonimitasnya, melainkan memberi batas yang terkontrol pengguna untuk penggunaan privasi.
Aku pun tidak akan mengangkatnya ke langit. Jika pengguna kehilangan kredensial KYC lokal, mereka tidak bisa lagi membuka bukti audit kepatuhan; jika sirkuit zero-knowledge punya bug logika, validasi izin tetap akan bocor. Yang benar-benar ingin diverifikasi bukan apakah narasinya terdengar indah, melainkan apakah kendala privasi ini benar-benar tahan ketika aset RWA dijalankan.
Ke depan, aset kepatuhan di atas rantai akan makin banyak. Yang lebih aku pedulikan bukan apakah ia bisa melakukan transaksi anonim, melainkan siapa yang bisa membuktikan bahwa privasimu hanya bisa kamu kendalikan sendiri @Dusk

#dusk $DUSK Kemarin pukul dua dini hari, saya nyaris tertidur di meja kerja rumah sewaan, membolak-balik whitepaper @Dusk . Sudut meja baru terbuka setengah jam, es soda sudah habis semua, dan tetesan air yang mengembun di dinding gelas menetes ke alas mouse, membentuk noda cincin kecil berwarna lebih gelap.

Dusk mengusung Privacy Layer1 yang menyasar skenario keuangan. Mekanisme konsensus Succinct Attestation karya mandirinya—kalau dibilang jujur, ini memang khusus untuk mengobati masalah lama yang sudah berkali-kali saya injak: para pemilik dana besar di rantai PoS mendominasi produksi blok, sumber acak mudah dimanipulasi, dan konfirmasi blok lambat. Klaimnya: finalitas deterministik dalam 3 detik, tahan serangan 51%, dan tidak akan membuat beberapa pemegang koin besar memegang kendali hak pembuatan blok.

Kedengarannya memang tidak ada salahnya.

Desentralisasi, keamanan, performa tinggi—tiga poin masalah yang sudah bertahun-tahun diperdebatkan industri. Katanya dia bisa semuanya? Tapi begitu saya membalik bagian pembangkitan seed untuk pemilihan acak, penulisannya sangat samar. Mereka hanya menulis, “dibangkitkan berdasarkan agregasi hash blok pendahulu.” Saya geser mouse ke samping, menatap layar dua detik tanpa gerak. Kalau performa acak pada undian node produksi blok bisa ditebak lebih dulu oleh segelintir node besar, bahkan disiasati lewat konspirasi, maka “randomness yang adil untuk memilih validator” itu jelas cuma kedok. Atribut desentralisasi node inti untuk privacy langsung dipotong setengah. Pertanyaan apakah seed acak ini bisa dimanipulasi atau dipalsukan melalui konspirasi—itu sudah dipahami oleh siapa pun yang berkutat di distributed consensus. Jauh lebih sulit daripada sekadar mempercepat kecepatan produksi blok. Kalau desain sumber acaknya ada celah, klaim performa tinggi dan ketahanan terhadap serangan jadi saling bertentangan, dan tidak bisa benar-benar diwujudkan. @Dusk

Di sini ada konflik inti: sebuah protokol yang katanya ingin melayani penyelesaian aset level institusi. Kalau logika verifikasi dari undian acak tidak dijelaskan sepenuhnya, maka kredibilitas konsensus SA pada dasarnya tetap perlu diuji lewat data dari operasi jangka panjang di mainnet, bukan sekadar klaim tertulis di whitepaper.

Nilai jangka panjang $DUSK , dalam beberapa hal, benar-benar bergantung pada apakah mekanisme konsensus ini bisa berjalan dengan nyata.

Saat kamu meneliti sebuah proyek, bagian mana dari whitepaper yang paling bikin kamu takut karena ditulis samar? Diskusikan di kolom komentar.

#dusk $DUSK Tadi malam saya membuka ulang situs resmi Dusk, dan seluruh bilah navigasinya sudah berubah.

Semua pintu masuk lama yang sudah saya telusuri hampir setahun hilang bersih. Saya bolak-balik antara dua bagian, "teknologi stack" dan "pengembang", empat atau lima kali sebelum akhirnya menemukan dokumentasi node. Sejujurnya, saya agak kesal—tetapi setelah mengikuti situs baru itu dari protokol dasar sampai ke atas, dan membaca tiga pembaruan inti, saya justru merasa lega malam itu tidak sia-sia.

Pertama, soal DuskEVM—ini yang paling ingin saya kritik sekaligus paling mengejutkan.

Sebelumnya saya selalu merasa virtual machine Rusk benar-benar unggul dalam privasi, tetapi pengembangan kontrak asli Rust terlalu sulit. Hasilnya, kali ini DuskEVM langsung menutup semua keluhan saya sebelumnya—ini bukan jembatan lintas chain, melainkan sebuah penerjemah bytecode bawaan. Artinya apa? Saya cukup memasukkan kontrak Solidity lama saya, lalu sistem otomatis mengubahnya menjadi kode eksekusi privat yang sesuai dengan batasan sirkuit PLONK, tanpa saya perlu repot mengurus lapisan bawah ZK sama sekali.

Pengoperasiannya di lapangan bahkan lebih langsung. Tadi malam saya terhubung ke testnet, lalu mencoba kontrak Swap yang saya punya sebelumnya. Dari kompilasi sampai deployment, hanya butuh 12 menit. Dibanding dulu saat harus bergulat dengan Rust untuk menulis kontrak asli, efisiensinya jauh sekali. Penerjemah ini adalah poin yang paling ingin saya rekomendasikan hari ini.

Dusk Trade adalah hal kedua yang membuat saya kaget.

Sistem ini berbasis arsitektur Phoenix zkUTXO—saya butuh waktu lama untuk benar-benar paham, tapi sederhananya, setiap transaksi adalah bukti terenkripsi yang berdiri sendiri, dan hanya pemegang kunci yang bisa melihat isinya. Tidak ada Mempool publik, jadi bot sandwich sama sekali tidak bisa mendahului transaksi. Di saat yang sama, sistem ini juga memiliki antarmuka kunci tampilan terarah; saat institusi market maker perlu menjalani audit MiCA Uni Eropa, mereka bisa memberikan otorisasi terarah untuk melihat riwayat transaksi. Kali ini, kepatuhan dan privasi tidak perlu dipilih salah satu.

Alur kerja pasar yang patuh langsung memasukkan KYC dan periode lock-up ke dalam bukti ZK. Saat transaksi ditulis ke chain, kepatuhan diverifikasi otomatis, sehingga pemeriksaan manual bisa dihilangkan.

Dulu orang selalu bilang privasi dan kepatuhan hanya bisa pilih satu. Setelah Dusk meluncurkan sistem ini, pilihan itu tidak ada lagi.

Satu-satunya pertanyaan adalah—bagi mereka yang dulu menyerah membangun aplikasi on-chain karena terlalu sulit, kapan kalian berniat kembali?@Dusk

#dusk $DUSK Beberapa waktu lalu, saat ada insentif untuk testnet Dusk, pada tahap setoran saya diminta verifikasi sumber dana dan malah ditolak. Saat itu saya sebenarnya sudah siap—bahkan saya sudah menyiapkan catatan transaksi alamat selama setengah tahun. Sebelumnya, saat main Zcash, untuk bukti kepatuhan yang sejenis saja saya harus berurusan sampai 20 menit hanya untuk upload screenshot. Gasnya juga menghabiskan hampir 0,1 koin, dan yang lebih parah, saya jadi membocorkan seluruh saldo alamat saya ke pihak verifikator. Setiap kali berhadapan dengan permintaan seperti ini, saya selalu pusing. Hasilnya, di dompet Dusk, saya hanya klik tiga kali—dalam dua menit verifikasi sudah lolos. Verifikator bahkan tidak tahu sisa berapa koin testnet di alamat saya.

Pemahaman saya tentang Dusk sebelumnya hanya sebatas “blockchain publik untuk privasi”. Saya bahkan menganggapnya seperti chain anon lainnya: kalau untuk privasi berarti mengorbankan auditabilitas. Saya sempat menghabiskan hampir dua jam menelusuri kode sumber Rust dari model transaksi Phoenix, sampai mata terasa perih, baru benar-benar paham bahwa desainnya benar-benar menyasar titik sakit yang nyata.

Dusk tidak membuat saklar hitam-putih “sepenuhnya terbuka/sepenuhnya anonim”. Sebaliknya, di lapisan pembuktian zk-SNARKs mereka merancang kredensial terenkripsi yang bisa diverifikasi (VEP), dan dengan algoritma Plookup ukuran satu body bukti bisa dipadatkan hingga di bawah 1KB. Rantai privasi ZK lainnya untuk bukti sejenis minimal perlu membuat bukti lebih dari 10KB, verifikasinya pun menunggu belasan detik. Verifikasi di on-chain Dusk hanya butuh 2 milidetik: kalau Anda ingin membuktikan dana berasal dari bursa yang sah, Anda cukup membuat bukti yang terarah untuk satu transaksi setoran tersebut. Anda tidak perlu mengekspos alamat lengkap, total kepemilikan, atau catatan transaksi lainnya. Bahkan tidak perlu memberi tahu pihak tersebut alamat penerimaan Anda.

Waktu itu, biaya untuk menghasilkan bukti hanya 0,0003 DUSK—lebih murah daripada transfer biasa—dan verifikator bisa langsung memanggil kontrak di-chain untuk memverifikasi keaslian. Langkah unggah screenshot pun tidak diperlukan lagi. Kalau lihat di explorer, transaksi ini hanya berisi hash bukti; sama sekali tidak ada data plaintext yang terlihat.

Sebelumnya, semua chain privasi buntu di “kalau mau privasi tidak bisa patuh, kalau patuh privasi hilang”—jalan buntu itu. Desain Dusk mengembalikan kendali privasi sepenuhnya ke pengguna: saat ingin menyembunyikan transaksi, tidak ada plaintext yang bisa dicek di-chain. Saat ingin membuat bukti kepatuhan, Anda hanya memberikan informasi minimum yang benar-benar diperlukan ke pihak verifikator. Tidak ada privasi berlebih yang perlu dibocorkan.
Pernah nggak kalian mengalami momen canggung karena harus melakukan verifikasi on-chain sampai terpaksa mengekspos seluruh saldo? @Dusk

#dusk $DUSK rekan lama melemparkan dua rekaman suara berdurasi 60 detik larut malam, nadanya sesak seperti dulu saat berteriak menyuruhku gas menghadapi dog tanah: Mainnet Dusk sudah tayang, node staking bisa jalan, jalur privasi kedatangan kepala tambang.

Kupikir mirip seperti dulu dengan Sui dan Aptos—tinggal pasang biner saja. Ternyata tiga malam begadang baru benar-benar paham.

Hari pertama langsung mentok. ./dusk-node dijalankan, pembuatan bukti ZK sampai 87% pasti crash, terminal cuma melontarkan satu kalimat: "witness construction failed". Memori dari 4G melonjak ke 12G, kipasnya suaranya mirip mesin isap minyak warung bakso di bawah apartemen. Menginstal ulang program lima kali, men-download ulang snapshot tiga kali, semuanya sia-sia. Akhirnya kubuka contoh di GitHub, ada komentar satu baris yang ukurannya nyaris luput: "key expects BigInt, string will break witness construction." Setelah mengubah cara mengirim parameter, restart—8 detik sudah jadi buktinya.

Tenang dulu, baru kupahami isinya dari kode sumber. Skema privasi Dusk bukan menyelubungi EVM dengan lapisan tipis, melainkan Rusk—mesin virtual privasi native—langsung menanamkan komponen kriptografi seperti sirkuit bukti ZK PLONK, hash Poseidon, dan tanda tangan BLS. Saat developer menulis kontrak, tidak perlu mengurus logika enkripsi manual; setelah dikompilasi, jadinya bytecode WASM yang ramah zero-knowledge. Kode kontrak otomatis diubah menjadi constraint circuit; banyak transaksi bisa di-aggregate secara rekursif menjadi satu bukti batch. Node cukup memverifikasi hash buktinya—alamat dan jumlah sama sekali tidak dipublikasikan di-chain, tapi kepatuhan tiap transaksi tetap bisa diverifikasi secara matematis.

Lapisan konsensusnya adalah SBA (Isolating Byzantine Agreement). Validator minimal harus mengunci 1000 keping $DUSK ; setiap ronde membuat blok, selain mengemas transaksi, juga harus menyertakan bukti ZK bahwa tindakan membuat blok tersebut legal. Dusk punya dua jenis penalti: penalti lunak tidak menargetkan penundaan blok—akan memindahkan sementara dari konsensus dan menurunkan jumlah staking efektif; penalti keras tidak menargetkan kejahatan—membuat blok tidak valid kena denda 10%, dual-sign atau dua blok kena denda 20%, lalu langsung dihancurkan. Dari sisi perangkat keras, rekomendasi resmi: mulai dari CPU 4 core dan RAM 8GB.

Jalan tiga minggu, imbalannya tidak seheboh klaim para akun promosi. Tapi malam saat berhasil jalan, suara kipas di casing jadi senyap. Ke belakang melihat tiga hari itu berharga—bukan soal untung berapa, melainkan benar-benar mengunyah dari nol pondasi sebuah chain baru. @Dusk

#baby $BABY Kenyataan malam sebelumnya, saya melakukan satu hal: menguji skrip staking Babylon dengan UTXO yang dipatok di testnet saya sendiri.

Saya ingin melihat bagaimana tepatnya ketiga cara keluar itu berjalan.

Pertama, saya coba yang paling sederhana—setelah masa staking berakhir, hanya dengan tanda tangan saya sendiri untuk membuka kunci UTXO tersebut, lalu disiarkan ke testnet Bitcoin. Node lolos, transaksi terkemas. Tidak perlu ada persetujuan dari Finality Provider, tidak perlu Babylon chain online—tanda tangan saya sendiri sudah cukup. Waktu itu saya pikir, inilah rasa aman yang paling dasar: selama jaringan Bitcoin masih berjalan, staker bisa mengambil kembali uang mereka.

Lalu saya coba cara kedua: simulasi kalau saya tidak ingin menunggu full masa staking, dan ingin keluar lebih cepat. Kali ini butuh tanda tangan saya sendiri, ditambah tanda tangan dari komite Covenant. Di sisi saya urus tanda tangannya mudah, sedangkan untuk pihak komite, saya mensimulasikan alur tanda tangan mereka. Setelah disiarkan, validasi node lolos, dan UTXO berhasil dibuka. Saya paham sekarang: komite hanya bertugas memverifikasi bahwa permintaan keluar lebih cepat ini sesuai aturan, tidak mengambil alih aset, dan tidak punya kendali.

Saat mencoba yang ketiga, saya sempat buntu. Jalur slashing butuh tiga kunci: tanda tangan saya sendiri, tanda tangan EOTS Finality Provider, dan tanda tangan komite Covenant. Waktu itu saya berpikir: kenapa slashing masih harus melibatkan tanda tangan saya? Bukankah itu membuat saya ikut berpartisipasi dalam menghukum diri sendiri?

Kemudian saya baru tahu alasannya setelah membaca laporan audit. Tanda tangan komite Covenant ternyata adalah tanda tangan adaptor—setelah dienkripsi, ia mengarah ke Finality Provider. Saya sudah menandatangani jalur slashing sebelumnya, tetapi tanda tangan ini dalam kondisi normal bersifat “terkunci”. Baru akan ter-dekripsi dan aktif jika FP menggunakan angka acak yang sama untuk menandatangani dua blok berbeda pada ketinggian (height) yang sama, sehingga kunci privat terekspos.

Artinya, saya tidak perlu percaya siapa pun agar tidak berbuat jahat. Kalau FP berbuat jahat → ekspos kunci privat secara matematis → tanda tangan adaptor otomatis ter-dekripsi → jalur slashing terbuka. Saya tidak perlu administrator memutuskan “haruskah dihukum atau tidak”, dan tidak perlu persetujuan apa pun dari siapa pun.

Saya sudah menguji ketiga cara keluar. Jalur mana yang dipilih tidak ditentukan oleh omongan orang—semuanya tergantung apakah kondisi yang ditetapkan dalam skrip terpenuhi.

@BabylonLabs_io