Lift di area perumahan sering mengalami gangguan. Di grup pemilik, ada yang membagikan rancangan perbaikan. Awalnya saya mengira karena jumlah suara paling banyak berarti bisa langsung mulai kerja. Tapi kemudian saya baru sadar masih ada proses penawaran, peninjauan, pengujian saat pembangunan, dan verifikasi/serah-terima. Tata kelola di rantai (on-chain) juga mudah disalahpahami: sebuah proposal dipublikasikan, hanya menunjukkan bahwa diskusi sudah punya wadah resmi; kode pada mainnet tidak otomatis berubah seketika.
Dusk menyusun perubahan protokol menjadi DIP, yaitu Dusk Improvement Proposal. Proses resmi dimulai dari Idea. Setelah idenya matang, masuk ke Draft dan mendapat nomor. Lalu membuat prototipe atau hasil teknis masuk ke Feedback. Menjelang selesai, beralih ke Staging. DIP yang melibatkan kode akan terlebih dahulu ditempatkan di testnet Nocturne. Setelah menerima konsensus barulah ditandai sebagai Active, dan pencapaian tersebut digabungkan ke lingkungan produksi.#dusk
Salah satu hal yang saya sukai dari alur ini adalah perubahan protokol DUSK harus meninggalkan arsip lengkap. Proposal harus menuliskan motivasi, spesifikasi teknis, trade-off, kompatibilitas ke belakang, pengujian, dampak keamanan, serta tautan implementasi. Proposal Stagnant yang tidak dilanjutkan pengembangannya selama enam bulan bisa masuk ke Dead. Saat menengok lagi satu siklus upgrade, komunitas bisa melacak risiko apa saja yang pernah dibahas pada waktu itu, bukan hanya melihat pengumuman versi baru.
Namun, “siapa pun bisa mengajukan” tidak bisa langsung disimpulkan bahwa “siapa pun bisa mengubah aturan.” Editor DIP akan ikut meninjau, memberi nomor, menggabungkan, dan memantau pelaksanaan. Operator node juga harus memasang perangkat lunak yang mencakup perubahan tersebut. Penjelasan publik saat ini tidak memberikan ambang batas persyaratan suara yang dihitung berdasarkan kepemilikan dengan $DUSK , dan juga tidak menuliskan “memperoleh konsensus” sebagai persentase yang jelas. Saya tidak akan membungkus diskusi terbuka seolah-olah tata kelola on-chain sudah selesai.
Saat memperhatikan upgrade yang terkait @Dusk , saya akan memeriksa terpisah empat hal: DIP berada di tahap apa, apakah kode implementasinya dipublikasikan, apakah hasil pengujian di Nocturne bisa diverifikasi ulang, dan kapan node di mainnet akan mengadopsinya. Suka/like di grup hanya menunjukkan ide itu disukai; hanya ketika status Active dan benar-benar dideploy, itu baru berarti aturan Dusk sudah sampai tahap yang mana.
Dusk menyusun perubahan protokol menjadi DIP, yaitu Dusk Improvement Proposal. Proses resmi dimulai dari Idea. Setelah idenya matang, masuk ke Draft dan mendapat nomor. Lalu membuat prototipe atau hasil teknis masuk ke Feedback. Menjelang selesai, beralih ke Staging. DIP yang melibatkan kode akan terlebih dahulu ditempatkan di testnet Nocturne. Setelah menerima konsensus barulah ditandai sebagai Active, dan pencapaian tersebut digabungkan ke lingkungan produksi.#dusk
Salah satu hal yang saya sukai dari alur ini adalah perubahan protokol DUSK harus meninggalkan arsip lengkap. Proposal harus menuliskan motivasi, spesifikasi teknis, trade-off, kompatibilitas ke belakang, pengujian, dampak keamanan, serta tautan implementasi. Proposal Stagnant yang tidak dilanjutkan pengembangannya selama enam bulan bisa masuk ke Dead. Saat menengok lagi satu siklus upgrade, komunitas bisa melacak risiko apa saja yang pernah dibahas pada waktu itu, bukan hanya melihat pengumuman versi baru.
Namun, “siapa pun bisa mengajukan” tidak bisa langsung disimpulkan bahwa “siapa pun bisa mengubah aturan.” Editor DIP akan ikut meninjau, memberi nomor, menggabungkan, dan memantau pelaksanaan. Operator node juga harus memasang perangkat lunak yang mencakup perubahan tersebut. Penjelasan publik saat ini tidak memberikan ambang batas persyaratan suara yang dihitung berdasarkan kepemilikan dengan $DUSK , dan juga tidak menuliskan “memperoleh konsensus” sebagai persentase yang jelas. Saya tidak akan membungkus diskusi terbuka seolah-olah tata kelola on-chain sudah selesai.
Saat memperhatikan upgrade yang terkait @Dusk , saya akan memeriksa terpisah empat hal: DIP berada di tahap apa, apakah kode implementasinya dipublikasikan, apakah hasil pengujian di Nocturne bisa diverifikasi ulang, dan kapan node di mainnet akan mengadopsinya. Suka/like di grup hanya menunjukkan ide itu disukai; hanya ketika status Active dan benar-benar dideploy, itu baru berarti aturan Dusk sudah sampai tahap yang mana.