@Dusk_Foundation Jarak Pemulihan yang Sebenarnya Saya Pantau di Node DUSK
Pada pukul 03:17, node sudah kembali ke kotak, tetapi masih belum berguna. Rusk terpasang, konfigurasi ada di tempat yang saya harapkan, dan kunci-kuncinya tidak tersentuh. Bagian yang mengganggu adalah statusnya. Jaringan terus bergerak sementara mesin ini tidak.
Di situlah fast-sync DUSK jadi menarik bagi saya. Bukan karena entah bagaimana membuat blok-blok lama menghilang. Ini melakukan sesuatu yang lebih praktis: ia mengganti status Rusk lokal dan basis data chain dengan status yang dipublikasikan, lalu membiarkan node melanjutkan dari sana menuju tip yang aktif.
Saya mulai memikirkan celah itu sebagai jarak pemulihan. Jika snapshot berada di ketinggian S dan jaringan sudah berada di T, maka T minus S adalah pekerjaan yang masih menunggu di depan node. Snapshot yang lebih baru bisa mengecilkan jarak itu, tetapi tidak menghapus sisa jalur pemulihan. Mengunduh itu satu hal. Memulai ulang, mencari peer, menaikkan ketinggian, dan memastikan ia terus maju adalah hal lainnya.
Ada juga sisi yang agak canggung di sini. Fast-sync tidak membangun ulang indeks arsip dari sebelum snapshot, jadi “terpulihkan” berarti hal yang berbeda untuk node biasa dan layanan arsip.
Yang ingin saya pantau berikutnya bukan ukuran snapshot. Melainkan bagaimana jarak pemulihan berperilaku saat terjadi kegagalan yang berantakan—ketika jaringan terus bergerak sementara operator masih memperbaiki semuanya.#dusk $DUSK
Pada pukul 03:17, node sudah kembali ke kotak, tetapi masih belum berguna. Rusk terpasang, konfigurasi ada di tempat yang saya harapkan, dan kunci-kuncinya tidak tersentuh. Bagian yang mengganggu adalah statusnya. Jaringan terus bergerak sementara mesin ini tidak.
Di situlah fast-sync DUSK jadi menarik bagi saya. Bukan karena entah bagaimana membuat blok-blok lama menghilang. Ini melakukan sesuatu yang lebih praktis: ia mengganti status Rusk lokal dan basis data chain dengan status yang dipublikasikan, lalu membiarkan node melanjutkan dari sana menuju tip yang aktif.
Saya mulai memikirkan celah itu sebagai jarak pemulihan. Jika snapshot berada di ketinggian S dan jaringan sudah berada di T, maka T minus S adalah pekerjaan yang masih menunggu di depan node. Snapshot yang lebih baru bisa mengecilkan jarak itu, tetapi tidak menghapus sisa jalur pemulihan. Mengunduh itu satu hal. Memulai ulang, mencari peer, menaikkan ketinggian, dan memastikan ia terus maju adalah hal lainnya.
Ada juga sisi yang agak canggung di sini. Fast-sync tidak membangun ulang indeks arsip dari sebelum snapshot, jadi “terpulihkan” berarti hal yang berbeda untuk node biasa dan layanan arsip.
Yang ingin saya pantau berikutnya bukan ukuran snapshot. Melainkan bagaimana jarak pemulihan berperilaku saat terjadi kegagalan yang berantakan—ketika jaringan terus bergerak sementara operator masih memperbaiki semuanya.#dusk $DUSK