You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been chasing this bug for a while in #3573.
The generation of a snapshot is two-step. First, a snapshot of the store at the snapshot seqno is taken and the snapshot generation is actually done later, asynchronously. However, if a ledger rekey happens in between the two, the ledger secret used to encrypt the snapshot will be the one of after the rekey. When a new node joins from this snapshot, it will try to (correctly!) use the ledger secret applicable at the seqno at which the snapshot was generated, but the decryption of the snapshot will fail with the following error:
The issue is due to the fast path on the selection of a ledger secret used to encrypt ledger entries: we assume that entries are always encrypted in the global order on the primary node, but it isn't the case for snapshots that are encrypted "retroactively".
The text was updated successfully, but these errors were encountered:
I have been chasing this bug for a while in #3573.
The generation of a snapshot is two-step. First, a snapshot of the store at the snapshot
seqno
is taken and the snapshot generation is actually done later, asynchronously. However, if a ledger rekey happens in between the two, the ledger secret used to encrypt the snapshot will be the one of after the rekey. When a new node joins from this snapshot, it will try to (correctly!) use the ledger secret applicable at theseqno
at which the snapshot was generated, but the decryption of the snapshot will fail with the following error:The issue is due to the fast path on the selection of a ledger secret used to encrypt ledger entries: we assume that entries are always encrypted in the global order on the primary node, but it isn't the case for snapshots that are encrypted "retroactively".
The text was updated successfully, but these errors were encountered: