Reconnect dan kamu kembali. Itulah asumsi.
Provider finalitas Babylon tidak bisa begitu saja melewati antrean. Provider finalitas harus mengunci acak publik mereka di muka, untuk tinggi blok di masa depan, secara bertahap. Ini bukan detail kecil — ini menjadi dasar sepenuhnya untuk bagaimana signature EOTS bekerja. TimestampingDelayBlocks menentukan seberapa jauh komitmen itu harus sudah mencapai masa depan, dan nilai yang direkomendasikan adalah lebih dari 10.000 blok, karena acaknya sendiri baru bisa digunakan setelah diberi timestamp di Bitcoin.
FP yang offline lebih lama daripada jendela yang sudah dikomitkan sebelumnya tidak hanya ketinggalan suara. Ia benar-benar kehabisan landasan.
Misalnya, sebuah provider memiliki acak yang dikomitkan hingga tinggi H, lalu tiba-tiba offline, kemudian kembali saat H ditambah 100 — sudah melewati batas yang ia rencanakan. Ia tidak bisa begitu saja mulai ikut memberikan suara lagi. Ia harus mengirim komitmen baru, dan komitmen itu pun tetap harus menunggu proses timestamping BTC untuk mengejar ketertinggalannya sebelum aktif.
Gangguan dan pemulihan adalah dua penundaan yang terpisah, dan keduanya saling ditumpuk.
Awalnya ini terasa terbalik. Aku mengira ketersediaan (uptime) adalah masalah utamanya — kembalikan node kamu online, selesai, semuanya berjalan. Tapi ternyata uptime dan kelayakan untuk voting adalah dua “jam” yang berbeda di sini, dan jam kedua sudah diatur berhari-hari atau berminggu-minggu sebelumnya, sebelum gangguan itu bahkan terjadi.
Jadi, ketahanan nyata seorang operator bukan cuma "seberapa cepat aku bisa restart". Melainkan "seberapa jauh aku merencanakan sebelum ada sesuatu yang salah" — sebuah keputusan yang dibenamkan dalam nilai konfigurasi jauh sebelum ada gangguan yang harus dipulihkan.
Kalau kemampuan untuk bisa voting lagi setelah gangguan ditentukan oleh angka yang kamu set sebelum gangguan itu terjadi, seberapa besar reputasi operator soal "uptime yang andal" sebenarnya hanya taruhan yang dibuat dari awal, dan seberapa besar yang benar-benar ketahanan (resilience) saat momen itu?
@BabylonLabs_io #baby $BABY
Provider finalitas Babylon tidak bisa begitu saja melewati antrean. Provider finalitas harus mengunci acak publik mereka di muka, untuk tinggi blok di masa depan, secara bertahap. Ini bukan detail kecil — ini menjadi dasar sepenuhnya untuk bagaimana signature EOTS bekerja. TimestampingDelayBlocks menentukan seberapa jauh komitmen itu harus sudah mencapai masa depan, dan nilai yang direkomendasikan adalah lebih dari 10.000 blok, karena acaknya sendiri baru bisa digunakan setelah diberi timestamp di Bitcoin.
FP yang offline lebih lama daripada jendela yang sudah dikomitkan sebelumnya tidak hanya ketinggalan suara. Ia benar-benar kehabisan landasan.
Misalnya, sebuah provider memiliki acak yang dikomitkan hingga tinggi H, lalu tiba-tiba offline, kemudian kembali saat H ditambah 100 — sudah melewati batas yang ia rencanakan. Ia tidak bisa begitu saja mulai ikut memberikan suara lagi. Ia harus mengirim komitmen baru, dan komitmen itu pun tetap harus menunggu proses timestamping BTC untuk mengejar ketertinggalannya sebelum aktif.
Gangguan dan pemulihan adalah dua penundaan yang terpisah, dan keduanya saling ditumpuk.
Awalnya ini terasa terbalik. Aku mengira ketersediaan (uptime) adalah masalah utamanya — kembalikan node kamu online, selesai, semuanya berjalan. Tapi ternyata uptime dan kelayakan untuk voting adalah dua “jam” yang berbeda di sini, dan jam kedua sudah diatur berhari-hari atau berminggu-minggu sebelumnya, sebelum gangguan itu bahkan terjadi.
Jadi, ketahanan nyata seorang operator bukan cuma "seberapa cepat aku bisa restart". Melainkan "seberapa jauh aku merencanakan sebelum ada sesuatu yang salah" — sebuah keputusan yang dibenamkan dalam nilai konfigurasi jauh sebelum ada gangguan yang harus dipulihkan.
Kalau kemampuan untuk bisa voting lagi setelah gangguan ditentukan oleh angka yang kamu set sebelum gangguan itu terjadi, seberapa besar reputasi operator soal "uptime yang andal" sebenarnya hanya taruhan yang dibuat dari awal, dan seberapa besar yang benar-benar ketahanan (resilience) saat momen itu?
@BabylonLabs_io #baby $BABY