Momen paling memalukan dari satu rantai penyelesaian sekuritas: tidak selalu peretasan oleh hacker, melainkan karena tidak ada pihak yang jelas-jelas berbuat jahat—tetapi buku besar tak kunjung bisa dibuka ke halaman berikutnya. Node terputus, terjadi partisi jaringan, panitia tidak bisa mengumpulkan suara yang cukup; uang tidak hilang, namun semua orang hanya bisa menunggu. Pada blockchain publik biasa, ini disebut kemacetan; pada pasar keuangan, ini bahkan bisa langsung berubah menjadi insiden gagal serah-terima.
Saya meninjau kembali Emergency Mode dari whitepaper @Dusk , dan saya menemukan bahwa ia tidak berpura-pura situasi seperti ini tidak akan terjadi. Succinct Attestation menjalankan maksimal 50 iterasi per putaran; ketika 16 iterasi berturut-turut gagal, protokol akan masuk ke mode darurat. Langkah-langkah dalam alur normal yang melebihi batas waktu akan dimatikan. NoCandidate dan NoQuorum juga tidak lagi dipakai sebagai hasil untuk melanjutkan; iterasi yang sudah berjalan akan tetap menunggu hingga kandidat blok dan tahap verifikasi serta persetujuan benar-benar mencapai jumlah suara sah.
Maksud desainnya sangat jelas: selama keadaan normal, konsensus masih bisa berpindah ke batch berikutnya karena waktu habis. Namun dalam kondisi ekstrem, sistem tidak boleh terus menghindari masalah dengan dalih “tidak ada yang datang tepat waktu”. Sistem memilih untuk membiarkan beberapa iterasi terbuka berjalan paralel, demi menunggu sebuah blok yang bisa dikonfirmasi oleh komite—meningkatkan peluang agar buku besar terus bergerak maju.
Namun biaya yang ditimbulkannya juga tertulis di whitepaper. Iterasi paralel dapat menyebabkan lebih dari satu kandidat blok yang sudah mendapat konsensus muncul pada putaran yang sama, sehingga risiko fork justru meningkat. Protokol hanya bisa memilih kandidat blok dengan nomor iterasi terendah untuk menyatukan (menuntaskan) proses. Jika pada akhirnya tetap tidak bisa dipulihkan, sebagian besar pemegang stake masih bisa secara bersama mengajukan sebuah blok kosong darurat yang tidak berisi transaksi, dan node Dusk akan menghasilkan seed baru, sehingga jaringan bisa melewati putaran ini.
Saya tidak akan memahaminya sebagai “tidak pernah berhenti”. Ini lebih seperti buku panduan pemulihan bencana: mengakui konsensus bisa melambat, lalu menetapkan siapa yang dapat mendorong pemulihan dan pengorbanan apa yang mungkin harus dilakukan selama pemulihan. Ke depan, ketika melihat kemampuan penyelesaian finansial milik $DUSK , saya lebih peduli pada seberapa sering mode darurat benar-benar terpanggil, berapa lama berlangsung, berapa banyak fork terjadi, dan jumlah permintaan blok kosong—bukan hanya berapa detik blok bisa terbentuk dalam kondisi normal.
Infrastruktur dasar tingkat institusi yang sesungguhnya bukanlah yang tidak pernah mengalami gangguan. Melainkan yang aturan penanganannya sudah dituliskan sejak awal ketika gangguan terjadi, dan biayanya juga bisa terlihat oleh semua orang.
#dusk
Saya meninjau kembali Emergency Mode dari whitepaper @Dusk , dan saya menemukan bahwa ia tidak berpura-pura situasi seperti ini tidak akan terjadi. Succinct Attestation menjalankan maksimal 50 iterasi per putaran; ketika 16 iterasi berturut-turut gagal, protokol akan masuk ke mode darurat. Langkah-langkah dalam alur normal yang melebihi batas waktu akan dimatikan. NoCandidate dan NoQuorum juga tidak lagi dipakai sebagai hasil untuk melanjutkan; iterasi yang sudah berjalan akan tetap menunggu hingga kandidat blok dan tahap verifikasi serta persetujuan benar-benar mencapai jumlah suara sah.
Maksud desainnya sangat jelas: selama keadaan normal, konsensus masih bisa berpindah ke batch berikutnya karena waktu habis. Namun dalam kondisi ekstrem, sistem tidak boleh terus menghindari masalah dengan dalih “tidak ada yang datang tepat waktu”. Sistem memilih untuk membiarkan beberapa iterasi terbuka berjalan paralel, demi menunggu sebuah blok yang bisa dikonfirmasi oleh komite—meningkatkan peluang agar buku besar terus bergerak maju.
Namun biaya yang ditimbulkannya juga tertulis di whitepaper. Iterasi paralel dapat menyebabkan lebih dari satu kandidat blok yang sudah mendapat konsensus muncul pada putaran yang sama, sehingga risiko fork justru meningkat. Protokol hanya bisa memilih kandidat blok dengan nomor iterasi terendah untuk menyatukan (menuntaskan) proses. Jika pada akhirnya tetap tidak bisa dipulihkan, sebagian besar pemegang stake masih bisa secara bersama mengajukan sebuah blok kosong darurat yang tidak berisi transaksi, dan node Dusk akan menghasilkan seed baru, sehingga jaringan bisa melewati putaran ini.
Saya tidak akan memahaminya sebagai “tidak pernah berhenti”. Ini lebih seperti buku panduan pemulihan bencana: mengakui konsensus bisa melambat, lalu menetapkan siapa yang dapat mendorong pemulihan dan pengorbanan apa yang mungkin harus dilakukan selama pemulihan. Ke depan, ketika melihat kemampuan penyelesaian finansial milik $DUSK , saya lebih peduli pada seberapa sering mode darurat benar-benar terpanggil, berapa lama berlangsung, berapa banyak fork terjadi, dan jumlah permintaan blok kosong—bukan hanya berapa detik blok bisa terbentuk dalam kondisi normal.
Infrastruktur dasar tingkat institusi yang sesungguhnya bukanlah yang tidak pernah mengalami gangguan. Melainkan yang aturan penanganannya sudah dituliskan sejak awal ketika gangguan terjadi, dan biayanya juga bisa terlihat oleh semua orang.
#dusk
