#dusk $DUSK
Detail teknis dari mesin virtual Dusk ini—semakin dibedah, makin pusing kepala.
Awalnya aku heran: status seperti kepemilikan (holding) dan izin yang ada di dalam kontrak itu disimpan di mana? Setelah membolak-balik cukup lama, barulah paham—ia memasukkan seluruh status kontrak ke dalam satu blok memori yang berurutan. Setiap kali ada perubahan, yang dilakukan adalah menulis ulang satu blok memori itu sepenuhnya. Ini benar-benar bukan model EVM yang biasa kita kenal. Kalau EVM, yang diubah cuma tempat tertentu; seperti mengedit dokumen, cukup mengubah satu baris. Tapi di sini, meskipun cuma mengubah satu angka, satu halaman memori pun harus ditumbangkan lalu ditulis ulang semuanya.
Sudah mahal sumber dayanya begitu, ia juga menumpuk desain double ledger. Satu ledger publik untuk dilihat regulator, sedangkan ledger privat berjalan di XSC. Begitu transaksi diproses: status publik diubah sekali, status privat harus digenerasi ulang sekali—lalu dua duplikat memori itu sama-sama harus ditulis kembali. Bagian Hedger juga harus menjalankan pembuktian zero-knowledge lagi, node ikut menghitung ulang. Intinya, biayanya bukan sekadar 1+1 yang dijumlahkan, tapi dikalikan.
Untuk tokenisasi sekuritas, holding, whitelist, dan aturan lockup—status seperti itu pada dasarnya hanya bertambah, bukan berkurang. Kalau kamu menerapkan kontrak XSC yang agak kompleks, meskipun cuma mengubah satu saldo, seluruh halaman memori tetap harus ditulis ulang secara penuh.
Pasti ada yang bilang, “Lah gimana? Kan statusnya jalan di lapisan atas, di level bawah DuskDS cuma simpan pembuktian.” Kedengarannya masuk akal, tapi kalau dipikir lebih dalam… tidak sesederhana itu! Node pengarsipan tidak menyimpan snapshot memori historis? Kalau begitu untuk audit yang perlu dicek sejarah status, mau dicek apa? Cek udara? Kalau memang disimpan, lalu apa bedanya dengan full node? Jadi, masalah status yang makin menumpuk dipindahkan saja dari lapisan eksekusi ke lapisan pengarsipan.
Kejadian ini terus dibahas oleh pihak resmi, muter-muter, tapi tak ada satu jawaban yang benar-benar menjawab secara positif.
Sekarang yang paling aku perhatikan adalah kondisi on-chain dari kontrak sekuritas NPEX yang sebenarnya. Kalau dalam setengah tahun ukuran status untuk satu kontrak bisa jadi 10 kali lebih besar dibanding ERC20 biasa, atau node pengarsipan mulai diam-diam menyimpan snapshot memori, desain ini jelas jadi bom RWA—aku langsung tidak akan menyentuhnya.
Oh ya! Ada satu celah lagi: pembuktian DuskDS yang ringkas bisa membuktikan bahwa ledger privat itu sendiri tidak salah, tapi apakah bisa membuktikan bahwa setiap catatan historis dari snapshot memori selalu berurutan dan tidak diubah? Kalau tidak bisa, jejak audit tokenisasi sekuritas akan langsung terputus di antara lapisan privat dan lapisan pengarsipan.
@Dusk
Detail teknis dari mesin virtual Dusk ini—semakin dibedah, makin pusing kepala.
Awalnya aku heran: status seperti kepemilikan (holding) dan izin yang ada di dalam kontrak itu disimpan di mana? Setelah membolak-balik cukup lama, barulah paham—ia memasukkan seluruh status kontrak ke dalam satu blok memori yang berurutan. Setiap kali ada perubahan, yang dilakukan adalah menulis ulang satu blok memori itu sepenuhnya. Ini benar-benar bukan model EVM yang biasa kita kenal. Kalau EVM, yang diubah cuma tempat tertentu; seperti mengedit dokumen, cukup mengubah satu baris. Tapi di sini, meskipun cuma mengubah satu angka, satu halaman memori pun harus ditumbangkan lalu ditulis ulang semuanya.
Sudah mahal sumber dayanya begitu, ia juga menumpuk desain double ledger. Satu ledger publik untuk dilihat regulator, sedangkan ledger privat berjalan di XSC. Begitu transaksi diproses: status publik diubah sekali, status privat harus digenerasi ulang sekali—lalu dua duplikat memori itu sama-sama harus ditulis kembali. Bagian Hedger juga harus menjalankan pembuktian zero-knowledge lagi, node ikut menghitung ulang. Intinya, biayanya bukan sekadar 1+1 yang dijumlahkan, tapi dikalikan.
Untuk tokenisasi sekuritas, holding, whitelist, dan aturan lockup—status seperti itu pada dasarnya hanya bertambah, bukan berkurang. Kalau kamu menerapkan kontrak XSC yang agak kompleks, meskipun cuma mengubah satu saldo, seluruh halaman memori tetap harus ditulis ulang secara penuh.
Pasti ada yang bilang, “Lah gimana? Kan statusnya jalan di lapisan atas, di level bawah DuskDS cuma simpan pembuktian.” Kedengarannya masuk akal, tapi kalau dipikir lebih dalam… tidak sesederhana itu! Node pengarsipan tidak menyimpan snapshot memori historis? Kalau begitu untuk audit yang perlu dicek sejarah status, mau dicek apa? Cek udara? Kalau memang disimpan, lalu apa bedanya dengan full node? Jadi, masalah status yang makin menumpuk dipindahkan saja dari lapisan eksekusi ke lapisan pengarsipan.
Kejadian ini terus dibahas oleh pihak resmi, muter-muter, tapi tak ada satu jawaban yang benar-benar menjawab secara positif.
Sekarang yang paling aku perhatikan adalah kondisi on-chain dari kontrak sekuritas NPEX yang sebenarnya. Kalau dalam setengah tahun ukuran status untuk satu kontrak bisa jadi 10 kali lebih besar dibanding ERC20 biasa, atau node pengarsipan mulai diam-diam menyimpan snapshot memori, desain ini jelas jadi bom RWA—aku langsung tidak akan menyentuhnya.
Oh ya! Ada satu celah lagi: pembuktian DuskDS yang ringkas bisa membuktikan bahwa ledger privat itu sendiri tidak salah, tapi apakah bisa membuktikan bahwa setiap catatan historis dari snapshot memori selalu berurutan dan tidak diubah? Kalau tidak bisa, jejak audit tokenisasi sekuritas akan langsung terputus di antara lapisan privat dan lapisan pengarsipan.
@Dusk