Saya kembali menelusuri dokumentasi Dusk ( @Dusk ) tadi malam, dan semakin dalam saya masuk ke konsensus, semakin menarik kasus kegagalannya.
Awalnya, mode darurat terdengar seperti cadangan sederhana. Tapi mengapa Dusk membutuhkannya jika protokol normal sudah bisa melakukan percobaan ulang untuk iterasi yang gagal? Dokumentasi menjelaskan bahwa setelah kegagalan berulang, protokol dapat terus menjalankan iterasi terbuka sampai konsensus berhasil. Itu membuat saya bertanya-tanya seberapa besar kelangsungan (liveness) diprioritaskan dibanding efisiensi selama kondisi jaringan yang sangat ekstrem.
Lalu ada pertanyaan tentang fork. Bagaimana dua blok kandidat bisa mencapai konsensus dalam putaran yang sama? Dusk menggunakan nomor iterasi dan melakukan fallback untuk menyelesaikannya, tetapi blok dengan iterasi yang lebih tinggi tetap bisa dibatalkan. Untuk penyelesaian finansial, perbedaan itu tampaknya penting.
Saya juga memperhatikan struktur imbalannya. Generator menerima sebagian besar imbalan blok, sementara para pemilih mendapatkan bagian terpisah. Itu semakin masuk akal setelah saya mempertimbangkan masalah insentif: apa yang mencegah generator di masa depan mendapatkan keuntungan ketika iterasi sebelumnya gagal?
Sistem kesalahan menambah lapisan lain. Mengapa memisahkan kesalahan minor dari yang mayor? Penangguhan dan soft slashing tampak dirancang secara berbeda dari hard slashing untuk perilaku serius seperti double voting atau blok yang tidak valid.
Terakhir, Moonlight dan Phoenix membuat saya memikirkan ulang lapisan transaksi. Mengapa mempertahankan model transparan berbasis akun sekaligus model privasi berbasis UTXO?
Apakah desain ganda ini menciptakan fleksibilitas yang bermanfaat, atau justru menambah kompleksitas? Dan saat Dusk berkembang, di mana desentralisasi dan keamanan bisa menjadi lebih sulit untuk dijaga?
@Dusk_Foundation #dusk $DUSK
Awalnya, mode darurat terdengar seperti cadangan sederhana. Tapi mengapa Dusk membutuhkannya jika protokol normal sudah bisa melakukan percobaan ulang untuk iterasi yang gagal? Dokumentasi menjelaskan bahwa setelah kegagalan berulang, protokol dapat terus menjalankan iterasi terbuka sampai konsensus berhasil. Itu membuat saya bertanya-tanya seberapa besar kelangsungan (liveness) diprioritaskan dibanding efisiensi selama kondisi jaringan yang sangat ekstrem.
Lalu ada pertanyaan tentang fork. Bagaimana dua blok kandidat bisa mencapai konsensus dalam putaran yang sama? Dusk menggunakan nomor iterasi dan melakukan fallback untuk menyelesaikannya, tetapi blok dengan iterasi yang lebih tinggi tetap bisa dibatalkan. Untuk penyelesaian finansial, perbedaan itu tampaknya penting.
Saya juga memperhatikan struktur imbalannya. Generator menerima sebagian besar imbalan blok, sementara para pemilih mendapatkan bagian terpisah. Itu semakin masuk akal setelah saya mempertimbangkan masalah insentif: apa yang mencegah generator di masa depan mendapatkan keuntungan ketika iterasi sebelumnya gagal?
Sistem kesalahan menambah lapisan lain. Mengapa memisahkan kesalahan minor dari yang mayor? Penangguhan dan soft slashing tampak dirancang secara berbeda dari hard slashing untuk perilaku serius seperti double voting atau blok yang tidak valid.
Terakhir, Moonlight dan Phoenix membuat saya memikirkan ulang lapisan transaksi. Mengapa mempertahankan model transparan berbasis akun sekaligus model privasi berbasis UTXO?
Apakah desain ganda ini menciptakan fleksibilitas yang bermanfaat, atau justru menambah kompleksitas? Dan saat Dusk berkembang, di mana desentralisasi dan keamanan bisa menjadi lebih sulit untuk dijaga?
@Dusk_Foundation #dusk $DUSK