Pada awal bulan ini, Fireblocks mengumumkan restrukturisasi mekanisme pemrosesan transaksi. Intinya adalah meniadakan urutan nonce terdesentralisasi dan memasang pemutus sirkuit (circuit breaker) untuk mencegah head-of-line blocking: jika antrean nonce tunggal tersendat di bagian awal, seluruh transaksi akun ikut tertahan. Ini membuat saya kembali membaca ulang whitepaper @Dusk , bagian 4.1. Moonlight lebih mirip satu rangkaian akuntansi penyelesaian per transaksi secara berurutan: nonce bukanlah nomor transaksi yang bisa diparalelkan, melainkan urutan penyelesaian yang wajib diproses secara paksa dan berurutan. Penilaian kuncinya adalah: DUSK di sini sekaligus berperan sebagai aset/objek transfer, uang muka kontrak, dan unit penetapan harga bahan bakar—struktur risiko-manfaatnya secara alami tidak simetris.
Field transaksi Moonlight memuat value, nonce, deposit, gas_limit, gas_price, dan signature. Whitepaper mensyaratkan nonce harus persis sama dengan nilai saat ini ditambah satu; jika tidak, transaksi ditolak untuk masuk ke buku. Jika diterjemahkan ke dalam bahasa ketentuan finansial, ini adalah antrean penyelesaian satu jalur: setiap transaksi yang menggantung akan membekukan seluruh instruksi berikutnya, sehingga tercipta kondisi head-blocking secara faktual. value adalah jumlah transfer, deposit adalah uang muka opsional yang dikirim ke kontrak, sedangkan gas_limit×gas_price mengonversi biaya bahan bakar menjadi penetapan harga dengan angka $DUSK —ketiganya berasal dari sumber yang sama, sementara saldo akun sekaligus menanggung tiga jenis eksposur: pembayaran, eksekusi, dan tarif. Ketentuan pengembalian dana (refund) juga menarik untuk dicermati: saat eksekusi kontrak melakukan rollback, jumlah dikembalikan ke jalur semula, sementara gas yang tidak terpakai tidak ikut dikembalikan; pada praktiknya ini merupakan serangkaian ketentuan penyelesaian bersyarat yang bergantung pada kemampuan mesin virtual untuk melakukan rollback eksekusi dengan benar.
Ada paradoks pada penamaan: model akun yang sepenuhnya transparan justru disebut “moonlight”—cahaya bulan memang tidak terang, namun harus menanggung rekonsiliasi per transaksi yang paling ketat. Jika antrean serial tersendat oleh satu transaksi buruk atau lonjakan biaya/fee yang ekstrem, kemampuan penyelesaian akun ikut lumpuh; saat arus dana baru masuk turun hingga menembus ambang pemeliharaan, atau ketika alamat besar terkonsentrasi keluar, ujungnya kemungkinan besar adalah peristiwa kredit dari produk terstruktur. Bedanya hanya: kredit disahkan oleh algoritma, sementara algoritma tidak memikul kewajiban untuk melakukan pembayaran.
#dusk
Dalam praktiknya, saya tidak menetapkan posisi dengan arah (directional). Saya hanya menyisakan anggaran risiko. Eksposur tunggal saya jaga agar berada di bawah batas kerugian yang masih dapat ditoleransi; bila terjadi perubahan apa pun pada antrean nonce atau aturan refund, saya akan keluar terlebih dahulu, tanpa menunggu narasi berbalik. Indikator on-chain yang perlu dipantau sehari-hari tidak terlalu banyak: tren total nilai terkunci (total locked), perubahan kepemilikan alamat besar, serta catatan perubahan hak akses administrator kontrak. Untuk proyek ini, saya tidak mengambil sikap; yang bisa saya berikan hanyalah angka tingkat pengembalian yang diharapkan setelah disesuaikan dengan risiko. Selebihnya, biarlah pilihan bergantung pada preferensi risiko masing-masing.
Field transaksi Moonlight memuat value, nonce, deposit, gas_limit, gas_price, dan signature. Whitepaper mensyaratkan nonce harus persis sama dengan nilai saat ini ditambah satu; jika tidak, transaksi ditolak untuk masuk ke buku. Jika diterjemahkan ke dalam bahasa ketentuan finansial, ini adalah antrean penyelesaian satu jalur: setiap transaksi yang menggantung akan membekukan seluruh instruksi berikutnya, sehingga tercipta kondisi head-blocking secara faktual. value adalah jumlah transfer, deposit adalah uang muka opsional yang dikirim ke kontrak, sedangkan gas_limit×gas_price mengonversi biaya bahan bakar menjadi penetapan harga dengan angka $DUSK —ketiganya berasal dari sumber yang sama, sementara saldo akun sekaligus menanggung tiga jenis eksposur: pembayaran, eksekusi, dan tarif. Ketentuan pengembalian dana (refund) juga menarik untuk dicermati: saat eksekusi kontrak melakukan rollback, jumlah dikembalikan ke jalur semula, sementara gas yang tidak terpakai tidak ikut dikembalikan; pada praktiknya ini merupakan serangkaian ketentuan penyelesaian bersyarat yang bergantung pada kemampuan mesin virtual untuk melakukan rollback eksekusi dengan benar.
Ada paradoks pada penamaan: model akun yang sepenuhnya transparan justru disebut “moonlight”—cahaya bulan memang tidak terang, namun harus menanggung rekonsiliasi per transaksi yang paling ketat. Jika antrean serial tersendat oleh satu transaksi buruk atau lonjakan biaya/fee yang ekstrem, kemampuan penyelesaian akun ikut lumpuh; saat arus dana baru masuk turun hingga menembus ambang pemeliharaan, atau ketika alamat besar terkonsentrasi keluar, ujungnya kemungkinan besar adalah peristiwa kredit dari produk terstruktur. Bedanya hanya: kredit disahkan oleh algoritma, sementara algoritma tidak memikul kewajiban untuk melakukan pembayaran.
#dusk
Dalam praktiknya, saya tidak menetapkan posisi dengan arah (directional). Saya hanya menyisakan anggaran risiko. Eksposur tunggal saya jaga agar berada di bawah batas kerugian yang masih dapat ditoleransi; bila terjadi perubahan apa pun pada antrean nonce atau aturan refund, saya akan keluar terlebih dahulu, tanpa menunggu narasi berbalik. Indikator on-chain yang perlu dipantau sehari-hari tidak terlalu banyak: tren total nilai terkunci (total locked), perubahan kepemilikan alamat besar, serta catatan perubahan hak akses administrator kontrak. Untuk proyek ini, saya tidak mengambil sikap; yang bisa saya berikan hanyalah angka tingkat pengembalian yang diharapkan setelah disesuaikan dengan risiko. Selebihnya, biarlah pilihan bergantung pada preferensi risiko masing-masing.
