Ein Dusk-Archiv kann zur richtigen Blockhöhe zurückkommen und dennoch bei der einen Anfrage scheitern, die meine Blob-App tatsächlich benötigt: gib mir den Sidecar.
Blob-Transaktionen hinterlassen einen versionierten KZG-Blob-Hash on-chain, aber die Nutzdaten werden separat über Rusk anhand des Blob-Hashes oder des Commitments abgerufen. Das bedeutet, dass der Ketteneintrag und der Blob-Body nicht in derselben Wiederherstellungsannahme liegen.
Das Archiv-Tooling macht die Trennung explizit. Blob-Objekte werden separat gespeichert, die Abdeckung wird über zusammenhängende Blockbereiche hinweg nachgewiesen, und ein Archiv-Checkpoint ist erst vollständig, wenn sein passender Zustand, die Archivdaten und die Blob-Abdeckung zusammenpassen.
Wenn ich also den Kettenzustand und die Archivindizes sichere, aber die Blob-Speicherung wie einen wegwerfbaren Cache behandle, kann die Wiederherstellung gesund aussehen. Die Blöcke sind da. Die Transaktionshashes sind da. Meine Anwendung fragt nach einem alten Sidecar und bekommt nichts.
Das ist der Fehler, den ich testen würde, bevor ich ein wiederhergestelltes Dusk-Archiv als wiederhergestellt betrachte. Wähle einen finalisierten historischen Blob, löse seinen Ketten-berichteten Hash auf, hole den Sidecar und überprüfe dann Commitment und Proof.
Für mich bedeutet „Block wiederhergestellt“ nicht „Daten wiederhergestellt“, wenn die Anwendung von Dusk-Blob-Nutzdaten abhängt.
#dusk $DUSK @Dusk
Blob-Transaktionen hinterlassen einen versionierten KZG-Blob-Hash on-chain, aber die Nutzdaten werden separat über Rusk anhand des Blob-Hashes oder des Commitments abgerufen. Das bedeutet, dass der Ketteneintrag und der Blob-Body nicht in derselben Wiederherstellungsannahme liegen.
Das Archiv-Tooling macht die Trennung explizit. Blob-Objekte werden separat gespeichert, die Abdeckung wird über zusammenhängende Blockbereiche hinweg nachgewiesen, und ein Archiv-Checkpoint ist erst vollständig, wenn sein passender Zustand, die Archivdaten und die Blob-Abdeckung zusammenpassen.
Wenn ich also den Kettenzustand und die Archivindizes sichere, aber die Blob-Speicherung wie einen wegwerfbaren Cache behandle, kann die Wiederherstellung gesund aussehen. Die Blöcke sind da. Die Transaktionshashes sind da. Meine Anwendung fragt nach einem alten Sidecar und bekommt nichts.
Das ist der Fehler, den ich testen würde, bevor ich ein wiederhergestelltes Dusk-Archiv als wiederhergestellt betrachte. Wähle einen finalisierten historischen Blob, löse seinen Ketten-berichteten Hash auf, hole den Sidecar und überprüfe dann Commitment und Proof.
Für mich bedeutet „Block wiederhergestellt“ nicht „Daten wiederhergestellt“, wenn die Anwendung von Dusk-Blob-Nutzdaten abhängt.
#dusk $DUSK @Dusk
