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

Hot archive #200

Merged
merged 1 commit into from
Aug 8, 2024
Merged

Hot archive #200

merged 1 commit into from
Aug 8, 2024

Conversation

SirTyson
Copy link
Contributor

Adds Hot Archive types to vNext.

@SirTyson SirTyson requested a review from dmkozh July 30, 2024 17:54
@dmkozh dmkozh enabled auto-merge (squash) August 8, 2024 17:32
@dmkozh dmkozh merged commit 82b904a into stellar:next Aug 8, 2024
1 check passed
SirTyson added a commit to SirTyson/stellar-xdr that referenced this pull request Aug 8, 2024
dmkozh pushed a commit that referenced this pull request Aug 8, 2024
github-merge-queue bot pushed a commit to stellar/stellar-core that referenced this pull request Nov 23, 2024
# Description

Resolves #4394

Depends on XDR changes in
stellar/stellar-xdr#200.

This change refactors the BucketList so that we can have multiple Bucket
Lists simultaneously. This is necessary for State Archival, where
validators will maintain a live BucketList, hot archive BucketList, and
cold archive BucketList. This change does not yet support writing the
new archival BucketLists to history,

Each BucketList has small differences wrt to the entry types it stores,
merge logic, and how lookups are done, but the overall BucketList level
logic is the same. Because of this, it seemed easiest to template the
Bucket related classes and specialize a few functions. The difference
are as follows (I'll be updating the Archival CAP with this info soon)

Entry Types:
Live BucketList: `BucketEntry`
Hot Archive BucketList: `HotArchiveBucketEntry`.

This change was necessary due to how LedgerKeys are stored. In the Live
BucketList, only `DEADENTRY` store plain `LedgerKey`. `DEADENTRY` is
equivalent to null, so these LedgerKeys are dropped at the bottom level
bucket.

Hot Archives require two types that store LedgerKeys: `HA_LIVE` and
`HA_DELETED`. `HA_LIVE` is equivalent to the "null" type in the Live
BucketList, and is dropped in the bottom bucket. However, `HA_DELETED`
needs to be persisted.

Merging:
In the hot archive, `LedgerEntry` are never updated. They may be
overwritten by another `HotArchiveBucketEntry` type, but the
`LedgerEntry` contents itself never change. This means that the
`INITENTRY`, `LIVEENTRY`, and `DEADENTRY` abstraction doesn't really
make sense. This makes the merge logic for Hot Archive buckets very
simple, the newer entry always overwrites the older entry.

This PR adds the concept of a "Tombstone" entry. A tombstone entry
essentially represents null in the given BucketList and can be dropped
once it reaches the bottom bucket. On the live BucketList, DEADENTRY is
the tombstone type. On the Hot Archive BucketList, `HA_LIVE` is the
tombstone.

BucketListDB lookup:
The live BucketList only ever returns `LedgerEntry` types when queried.
Any DEADENTRY LedgerKey is simply omitted from the return, as this is
the "null" tombstone type.

Hot archive lookups must return both LedgerKey and LedgerEntry types.
HA_LIVE entries are of type LedgerKey and can be omitted from the return
since they are the tombstone type. However, HA_ARCHIVED entries are not
tombstone entries and must be returned when found. Do to this, Hot
Archive lookups return `HotArchiveBucketEntry` instead of `LedgerEntry`
when queried.

Future updates will add more functionality to Hot Archives, further
distinguishing it from the live BucketList, and add a third BucketList
type called the cold archive. This cold archive will add a third
BucketEntry type and have different merge logic as well, so I think the
templated Bucket classes, while verbose, are warranted.

This is currently a draft until the XDR changes are merged.

# Checklist
- [x] Reviewed the
[contributing](https://github.com/stellar/stellar-core/blob/master/CONTRIBUTING.md#submitting-changes)
document
- [x] Rebased on top of master (no merge commits)
- [x] Ran `clang-format` v8.0.0 (via `make format` or the Visual Studio
extension)
- [x] Compiles
- [x] Ran all tests
- [ ] If change impacts performance, include supporting evidence per the
[performance
document](https://github.com/stellar/stellar-core/blob/master/performance-eval/performance-eval.md)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants