NODE CADANGAN BISA MENJADI SUMBER KEKELIRUAN.
Satu peringatan dalam dokumentasi provisioner milik @Dusk membuat saya memikirkan ulang apa arti “redundansi” bagi sebuah validator.
Dusk secara eksplisit memperingatkan operator untuk tidak menjalankan kunci konsensus yang sama di beberapa node aktif.
Awalnya itu terdengar aneh.
Untuk infrastruktur normal, menyimpan dua mesin yang siap melakukan tugas yang sama persis adalah cara yang tepat untuk mengurangi waktu henti.
Tapi kunci konsensus itu berbeda.
Jika dua node aktif menggunakan identitas yang sama dan pada akhirnya menandatangani proposal atau suara yang saling bertentangan, redundansi itu sendiri dapat berubah menjadi ekuivokasi.
Dan Dusk memperlakukannya dengan cara yang sangat berbeda dibanding sekadar berada dalam kondisi offline.
Ini memberi saya perbedaan yang sebelumnya belum saya pikirkan dengan jelas:
redundansi infrastruktur ≠ redundansi konsensus.
Sebuah provisioner menginginkan node cadangan yang cukup siap untuk mengambil alih dengan cepat.
Namun jangan sampai terlalu aktif sehingga kedua mesin bisa berbicara untuk identitas konsensus yang sama pada saat yang sama.
Itulah yang membuat desain failover jauh lebih menarik daripada sekadar “jalankan server lain.”
Ada garis tipis antara:
satu node gagal → node cadangan mengambil alih
dan
kedua node sempat meyakini bahwa mereka adalah penanda tangan aktif.
Pada kasus kedua, sistem keselamatan bisa menjadi pihak yang justru menciptakan risiko.
Dokumentasi Dusk mengklasifikasikan perilaku konsensus yang saling bertentangan sebagai jenis kesalahan yang dapat mengarah pada penalti berat, termasuk membakar sebagian dari stake.
Jadi metrik operasional yang saya pedulikan bukan hanya sekadar ketersediaan (uptime) provisioner.
Saya ingin tahu seberapa andal seorang operator bisa melakukan failover antar mesin tanpa pernah menciptakan kunci konsensus aktif-aktif.
Itu definisi ketersediaan tinggi yang sangat berbeda.
Cadangan yang paling aman mungkin adalah cadangan yang benar-benar siap untuk menandatangani—
tapi tidak akan pernah menandatangani sampai node pertama benar-benar pasti sudah hilang.
#dusk $DUSK @Dusk
$BTW
$HEMI
Satu peringatan dalam dokumentasi provisioner milik @Dusk membuat saya memikirkan ulang apa arti “redundansi” bagi sebuah validator.
Dusk secara eksplisit memperingatkan operator untuk tidak menjalankan kunci konsensus yang sama di beberapa node aktif.
Awalnya itu terdengar aneh.
Untuk infrastruktur normal, menyimpan dua mesin yang siap melakukan tugas yang sama persis adalah cara yang tepat untuk mengurangi waktu henti.
Tapi kunci konsensus itu berbeda.
Jika dua node aktif menggunakan identitas yang sama dan pada akhirnya menandatangani proposal atau suara yang saling bertentangan, redundansi itu sendiri dapat berubah menjadi ekuivokasi.
Dan Dusk memperlakukannya dengan cara yang sangat berbeda dibanding sekadar berada dalam kondisi offline.
Ini memberi saya perbedaan yang sebelumnya belum saya pikirkan dengan jelas:
redundansi infrastruktur ≠ redundansi konsensus.
Sebuah provisioner menginginkan node cadangan yang cukup siap untuk mengambil alih dengan cepat.
Namun jangan sampai terlalu aktif sehingga kedua mesin bisa berbicara untuk identitas konsensus yang sama pada saat yang sama.
Itulah yang membuat desain failover jauh lebih menarik daripada sekadar “jalankan server lain.”
Ada garis tipis antara:
satu node gagal → node cadangan mengambil alih
dan
kedua node sempat meyakini bahwa mereka adalah penanda tangan aktif.
Pada kasus kedua, sistem keselamatan bisa menjadi pihak yang justru menciptakan risiko.
Dokumentasi Dusk mengklasifikasikan perilaku konsensus yang saling bertentangan sebagai jenis kesalahan yang dapat mengarah pada penalti berat, termasuk membakar sebagian dari stake.
Jadi metrik operasional yang saya pedulikan bukan hanya sekadar ketersediaan (uptime) provisioner.
Saya ingin tahu seberapa andal seorang operator bisa melakukan failover antar mesin tanpa pernah menciptakan kunci konsensus aktif-aktif.
Itu definisi ketersediaan tinggi yang sangat berbeda.
Cadangan yang paling aman mungkin adalah cadangan yang benar-benar siap untuk menandatangani—
tapi tidak akan pernah menandatangani sampai node pertama benar-benar pasti sudah hilang.
#dusk $DUSK @Dusk
$BTW
$HEMI