Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for historical queries after recovery from snapshot #1648

Closed
jumaffre opened this issue Sep 24, 2020 · 3 comments · Fixed by #2200
Closed

Support for historical queries after recovery from snapshot #1648

jumaffre opened this issue Sep 24, 2020 · 3 comments · Fixed by #2200
Assignees

Comments

@jumaffre
Copy link
Contributor

jumaffre commented Sep 24, 2020

When resuming from a snapshot or after recovery, a node doesn't have the history of the ledger secrets as ledger secrets are stored at the same key in the ccf.shares table. Assuming that the historical ledger is later moved to that node (see #1527), if this node has to serve historical queries, it won't be able to decrypt or verify the integrity of these historical entries.

To be able to support historical queries, the node should process the re-sharing entries in the ledger backwards, from the last available re-sharing entry (available in the snapshot). Caveat here: on recovery, the re-sharing entry is written at a version later than the one at which the associated ledger secret is applicable from so this mechanism should account for that.

Ledger secrets can be decrypted one-by-one using the previously restored ledger secret. There is no need to restore ledger secret prior to the latest re-sharing entry prior to the start index of the historical query and no need to keep in memory ledger secrets more recent than the first one after the end index of the historical query (included).

@jumaffre jumaffre added this to the Checkpointing milestone Sep 24, 2020
@achamayou
Copy link
Member

A slightly tangent point that came up in discussion but may be helpful in implementation is that reading through historical secrets going back can be quite quick (each one contains the version of its predecessor) and does not require ledger integrity validation because ledger secrets are encrypted and integrity protected with AES GCM.

A possible optimisation, should this turn out to be a significant cost, may be to include the last X ledger secrets in snapshots (similarly to what's being done for the term history).

@jumaffre jumaffre changed the title Support for historical queries when resuming from snapshot Support for historical queries after ledger rekey Jan 5, 2021
@jumaffre jumaffre removed this from the Checkpointing milestone Jan 5, 2021
@jumaffre
Copy link
Contributor Author

jumaffre commented Jan 5, 2021

Removing checkpoint milestone and re-phrasing issue slightly as this is not snapshot-specific but also applies to recoveries.

@jumaffre jumaffre changed the title Support for historical queries after ledger rekey Support for historical queries after recovery from snapshot Jan 27, 2021
@jumaffre
Copy link
Contributor Author

FYI, the minimal test suite to reproduce the issue is:

suite_rekey_recovery = [
    e2e_logging.test_historical_query,
    rekey.test,
    rekey.test,
    recovery.test, # Assuming this starts from snapshot
]

The recovery test will fail verifying historical queries emitted before the first rekey.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants