Sebuah arsip Dusk bisa kembali pada ketinggian blok yang tepat dan tetap gagal pada satu permintaan yang sebenarnya dibutuhkan aplikasi blob saya: berikan saya sidecar.

Transaksi blob meninggalkan hash blob KZG yang ber-*versioned* di on-chain, tetapi payload diambil secara terpisah melalui Rusk berdasarkan hash blob atau commitment. Artinya catatan rantai dan badan blob tidak berada dalam asumsi pemulihan yang sama.

Peralatan arsip membuat pemisahan itu menjadi eksplisit. Objek blob disimpan secara terpisah, cakupan dibuktikan di rentang blok yang berurutan, dan sebuah checkpoint arsip hanya lengkap ketika status yang cocok, data arsip, dan cakupan blob semuanya selaras.

Jadi jika saya mencadangkan state chain dan indeks arsip tetapi memperlakukan penyimpanan blob seperti cache yang bisa dibuang, pemulihan bisa terlihat sehat. Blok ada. Hash transaksi ada. Aplikasi saya meminta sidecar lama dan tidak mendapatkan apa-apa.

Itulah kegagalan yang ingin saya uji sebelum memanggil arsip Dusk dipulihkan. Pilih blob historis yang sudah final, selesaikan hash yang dilaporkan oleh chain, ambil sidecar, lalu verifikasi commitment dan buktinya.

Bagi saya, “blok dipulihkan” bukan berarti “data dipulihkan” ketika aplikasi bergantung pada payload blob Dusk.

#dusk $DUSK @Dusk