menjalankan dua model transaksi yang secara struktural berbeda pada satu settlement layer adalah satu hal untuk dijelaskan secara abstrak. namun, benar-benar memastikan keduanya tidak saling bertentangan adalah masalah yang sama sekali berbeda, dan DuskDS menyelesaikannya melalui satu bagian arsitektur yang spesifik: Transfer Contract.
Phoenix dan Moonlight bukanlah sistem yang berjalan independen secara paralel sambil berharap tetap konsisten secara kebetulan. setiap perpindahan nilai, baik itu catatan UTXO yang di-shield di Phoenix atau saldo akun publik di Moonlight, pada akhirnya melewati Transfer Contract—yang merupakan otoritas sebenarnya atas state global di DuskDS. inilah satu-satunya tempat yang bertanggung jawab untuk memastikan bahwa ketika sebuah catatan ter-shield dibelanjakan dan sebuah saldo publik diperbarui, keduanya tidak pernah menghasilkan total yang tidak konsisten, tidak dapat menciptakan nilai dari ketiadaan, dan tidak membiarkan dua model tersebut saling menjauh seiring waktu.
yang sebenarnya berarti bahwa Phoenix dan Moonlight bukan dua buku besar terpisah yang kebetulan berbagi satu chain. keduanya adalah dua representasi berbeda yang diberlakukan oleh satu sumber kebenaran yang sama. model privasinya berubah tergantung jenis transaksi yang Anda gunakan, tetapi akuntansinya di bawah tidak boleh saling bertentangan hanya karena Anda melihat dari sisi yang berbeda dalam sistem.
bagian desain inilah yang harus benar-benar sempurna agar pendekatan dual-model dari beberapa hari lalu bisa bertahan dalam penggunaan dunia nyata. jika Transfer Contract memiliki ketidakkonsistenan dalam bagaimana ia merekonsiliasi keduanya, itu bukan bug kecil; itu adalah titik di mana nilai secara teoritis bisa diciptakan atau hilang hanya dengan berpindah antara representasi ter-shield dan representasi transparan dari aset yang sama.
jadi, memusatkan rekonsiliasi tersebut ke dalam satu kontrak adalah desain yang lebih aman karena hanya ada satu tempat untuk mengaudit dan memverifikasi kebenarannya, atau dengan menaruh begitu banyak tanggung jawab pada satu kontrak justru risiko menjadi semakin terkonsentrasi alih-alih benar-benar menguranginya.
#dusk @Dusk $DUSK
Phoenix dan Moonlight bukanlah sistem yang berjalan independen secara paralel sambil berharap tetap konsisten secara kebetulan. setiap perpindahan nilai, baik itu catatan UTXO yang di-shield di Phoenix atau saldo akun publik di Moonlight, pada akhirnya melewati Transfer Contract—yang merupakan otoritas sebenarnya atas state global di DuskDS. inilah satu-satunya tempat yang bertanggung jawab untuk memastikan bahwa ketika sebuah catatan ter-shield dibelanjakan dan sebuah saldo publik diperbarui, keduanya tidak pernah menghasilkan total yang tidak konsisten, tidak dapat menciptakan nilai dari ketiadaan, dan tidak membiarkan dua model tersebut saling menjauh seiring waktu.
yang sebenarnya berarti bahwa Phoenix dan Moonlight bukan dua buku besar terpisah yang kebetulan berbagi satu chain. keduanya adalah dua representasi berbeda yang diberlakukan oleh satu sumber kebenaran yang sama. model privasinya berubah tergantung jenis transaksi yang Anda gunakan, tetapi akuntansinya di bawah tidak boleh saling bertentangan hanya karena Anda melihat dari sisi yang berbeda dalam sistem.
bagian desain inilah yang harus benar-benar sempurna agar pendekatan dual-model dari beberapa hari lalu bisa bertahan dalam penggunaan dunia nyata. jika Transfer Contract memiliki ketidakkonsistenan dalam bagaimana ia merekonsiliasi keduanya, itu bukan bug kecil; itu adalah titik di mana nilai secara teoritis bisa diciptakan atau hilang hanya dengan berpindah antara representasi ter-shield dan representasi transparan dari aset yang sama.
jadi, memusatkan rekonsiliasi tersebut ke dalam satu kontrak adalah desain yang lebih aman karena hanya ada satu tempat untuk mengaudit dan memverifikasi kebenarannya, atau dengan menaruh begitu banyak tanggung jawab pada satu kontrak justru risiko menjadi semakin terkonsentrasi alih-alih benar-benar menguranginya.
#dusk @Dusk $DUSK