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

Added proof requirements to entry recreation #1572

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Renamed evictedTemporaryLedgerKeys
  • Loading branch information
SirTyson committed Dec 2, 2024
commit cbd5984c1c874dc1583bfec858674a3d6a5caf76
27 changes: 20 additions & 7 deletions core/cap-0057.md
Original file line number Diff line number Diff line change
Expand Up @@ -341,6 +341,12 @@ struct LedgerCloseMetaV2
...
// same as LedgerCloseMetaV1 up to here

// Soroban code, data, and TTL keys that are being evicted at this ledger.
// Note: This has been renamed from evictedTemporaryLedgerKeys in V1
LedgerKey evictedLedgerKeys<>;

// Note: evictedPersistentLedgerEntries has been removed

uint32 currentArchivalEpoch;

// The last epoch currently stored by validators
Expand Down Expand Up @@ -662,7 +668,7 @@ the binary fuse filter claims a key does not exist in the set, it is guaranteed
However if the filter claims a key exist in the set, it may or may not actually exist.
These guarantees allow validators to check for AST subtree exclusion directly without
the need of actual proofs of nonexistence in most cases. In the case of a false positive,
a full proof can be provided to "override," as detailed in the section below.
a full proof can be provided to "override", as detailed in the section below.

The Archival Filter will be implemented as a 3 wise binary fuse filter with a bit width of
32 bits. This provides a 1 / 4 billion false positive rate with a storage overhead of 36 bits
Expand All @@ -676,7 +682,7 @@ network.
When a key is being created, it has either never existed before, or has existed, but
has since been deleted. These cases carry different proof requirements.

If a key is never existed, is is necessary to prove that the key does not exist in
If a key has never existed, is is necessary to prove that the key does not exist in
any AST subtree.

If a key previously existed and has been deleted, a proof of the deletion is required.
Expand Down Expand Up @@ -1059,8 +1065,15 @@ for key in footprint.readWrite:
// Entry was most recently deleted, do not allow outdated restore
failTx()

// oldest epoch is epoch is cold archive (if one exists), the oldest pending archival snapshot,
// or hot archive in there are no pending snapshots
// If there is currently a cold archive stored on disk
if coldArchiveExists:
oldestEpochOnDisk = coldArchive.epoch()
// If there are pending archives, use oldest epoch in archive
else if not pendingArchiveQueue.empty():
oldestEpochOnDisk = pendingArchiveQueue.back().epoch()
// If no cold archive or pending archives, use current hot archive epoch
else:
oldestEpochOnDisk = hotArchive.epoch()
if isRestoreValid(key, tx.proofs, oldestEpochOnDisk) == INVALID:
failTx()
```
Expand All @@ -1072,14 +1085,14 @@ required for proofs of nonexistence.

#### Meta

Meta will contain the current Archival Epoch via `currentArchivalEpoch`.This will be useful
Meta will contain the current Archival Epoch via `currentArchivalEpoch`. This will be useful
for downstream diagnostics such as Hubble. Meta will also contain the oldest Archival Snapshot
persisted on validators via `lastArchivalEpochPersisted`. This will be useful to RPC preflight,
as it is the cutoff point at which a proof will need to be generated for `RestoreFootprintOp`.

Whenever a `PERSISTENT` entry is evicted (i.e. removed from the Live State BucketList and added to the Hot Archive),
the entry key and its associated TTL key will be emitted via `evictedTemporaryLedgerKeys` (this field is unfortunately
named for legacy reasons).
the entry key and its associated TTL key will be emitted via `evictedLedgerKeys`
(this field has been renamed and was previously named `evictedTemporaryLedgerKeys`).

Whenever an entry is restored via `RestoreFootprintOp`, the `LedgerEntry` being restored and its
associated TTL will be emitted as a `LedgerEntryChange` of type `LEDGER_ENTRY_RESTORE`. Note that
Expand Down
Loading