#dusk $DUSK @Dusk
Ayah saya menjalankan dua pembukuan terpisah untuk toko kecilnya selama bertahun-tahun: satu untuk penjualan tunai, satu lagi untuk akun kredit. Saya pernah bertanya, kenapa tidak digabung saja. Ia menjawab bahwa uang tunai harus sederhana dan langsung, kredit perlu melacak jatuh tempo dan tindak lanjut, dan memaksa satu sistem melakukan keduanya justru akan membuat pekerjaan di salah satu sisi menjadi lebih buruk.
Saya mengira Dusk pada akhirnya akan bermuara pada satu model transaksi, seperti kebanyakan rantai yang akhirnya memilih satu pendekatan saja. Dugaan itu runtuh ketika saya benar-benar menelusuri mengapa Moonlight dan Phoenix sama-sama ada.
Moonlight berbasis akun, publik, dan mudah dipahami — dokumentasi Dusk menyebutnya sebagai model untuk saldo dan logika aplikasi yang tidak perlu disamarkan. Phoenix memakai pendekatan UTXO, dan keberadaannya memang khusus untuk mendukung alur yang berorientasi privasi: transfer yang dilindungi, pengungkapan selektif, bagian-bagian yang dibutuhkan oleh keuangan teregulasi ketika transparansi penuh tidak dapat diterima.
Menggabungkan keduanya ke dalam satu model berarti harus memaksa setiap transaksi melewati beban privasi yang tidak perlu, atau menghapus opsi penyamaran dari semua pihak yang membutuhkannya.
Uji nyata bagi DUSK adalah apakah mempertahankan dua model ini benar-benar membantu para pembangun yang membutuhkan jaminan berbeda untuk alur yang berbeda, bukan sekadar menambah beban konseptual yang kebanyakan pengguna tidak pernah sentuh.
Yang belum saya temukan terdokumentasi di mana pun adalah seberapa sering sebuah aplikasi sebenarnya membutuhkan kedua model tersebut secara bersamaan dalam praktik.
Ayah saya menjalankan dua pembukuan terpisah untuk toko kecilnya selama bertahun-tahun: satu untuk penjualan tunai, satu lagi untuk akun kredit. Saya pernah bertanya, kenapa tidak digabung saja. Ia menjawab bahwa uang tunai harus sederhana dan langsung, kredit perlu melacak jatuh tempo dan tindak lanjut, dan memaksa satu sistem melakukan keduanya justru akan membuat pekerjaan di salah satu sisi menjadi lebih buruk.
Saya mengira Dusk pada akhirnya akan bermuara pada satu model transaksi, seperti kebanyakan rantai yang akhirnya memilih satu pendekatan saja. Dugaan itu runtuh ketika saya benar-benar menelusuri mengapa Moonlight dan Phoenix sama-sama ada.
Moonlight berbasis akun, publik, dan mudah dipahami — dokumentasi Dusk menyebutnya sebagai model untuk saldo dan logika aplikasi yang tidak perlu disamarkan. Phoenix memakai pendekatan UTXO, dan keberadaannya memang khusus untuk mendukung alur yang berorientasi privasi: transfer yang dilindungi, pengungkapan selektif, bagian-bagian yang dibutuhkan oleh keuangan teregulasi ketika transparansi penuh tidak dapat diterima.
Menggabungkan keduanya ke dalam satu model berarti harus memaksa setiap transaksi melewati beban privasi yang tidak perlu, atau menghapus opsi penyamaran dari semua pihak yang membutuhkannya.
Uji nyata bagi DUSK adalah apakah mempertahankan dua model ini benar-benar membantu para pembangun yang membutuhkan jaminan berbeda untuk alur yang berbeda, bukan sekadar menambah beban konseptual yang kebanyakan pengguna tidak pernah sentuh.
Yang belum saya temukan terdokumentasi di mana pun adalah seberapa sering sebuah aplikasi sebenarnya membutuhkan kedua model tersebut secara bersamaan dalam praktik.
Genuinely useful split
67%
Unnecessary overhead
33%
3 Voting • Voting ditutup