blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Rename EntryTree to Blocktree

This commit is contained in:
Greg Fitzgerald 2019-01-30 10:29:47 -07:00
parent 1c0758e3bd
commit 883fc39c80
3 changed files with 23 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
book/src/SUMMARY.md
View File

@ -27,7 +27,7 @@
- [Secure Enclave](enclave.md) - [Secure Enclave](enclave.md)
- [Staking Rewards](staking-rewards.md) - [Staking Rewards](staking-rewards.md)
- [Fork Selection](fork-selection.md) - [Fork Selection](fork-selection.md)
- [Entry Tree](entry-tree.md) - [Blocktree](blocktree.md)
- [Data Plane Fanout](data-plane-fanout.md) - [Data Plane Fanout](data-plane-fanout.md)
- [Economic Design](ed_overview.md) - [Economic Design](ed_overview.md)

40
book/src/entry-tree.md → book/src/blocktree.md
View File

@ -1,4 +1,4 @@
# Entry Tree # Blocktree
This document proposes a change to ledger and window to support Solana's [fork This document proposes a change to ledger and window to support Solana's [fork
generation](fork-generation.md) behavior. generation](fork-generation.md) behavior.
@ -72,30 +72,30 @@ follow, which Entries to persist or when to persist them.
Repair requests for recent blobs are served out of RAM or recent files and out Repair requests for recent blobs are served out of RAM or recent files and out
of deeper storage for less recent blobs, as implemented by the store backing of deeper storage for less recent blobs, as implemented by the store backing
EntryTree. Blocktree.
### Functionalities of EntryTree ### Functionalities of Blocktree
1. Persistence: the EntryTree lives in the front of the nodes verification 1. Persistence: the Blocktree lives in the front of the nodes verification
pipeline, right behind network receive and signature verification. If the pipeline, right behind network receive and signature verification. If the
blob received is consistent with the leader schedule (i.e. was signed by the blob received is consistent with the leader schedule (i.e. was signed by the
leader for the indicated slot), it is immediately stored. leader for the indicated slot), it is immediately stored.
2. Repair: repair is the same as window repair above, but able to serve any 2. Repair: repair is the same as window repair above, but able to serve any
blob that's been received. EntryTree stores blobs with signatures, blob that's been received. Blocktree stores blobs with signatures,
preserving the chain of origination. preserving the chain of origination.
3. Forks: EntryTree supports random access of blobs, so can support a 3. Forks: Blocktree supports random access of blobs, so can support a
validator's need to rollback and replay from a Bank checkpoint. validator's need to rollback and replay from a Bank checkpoint.
4. Restart: with proper pruning/culling, the EntryTree can be replayed by 4. Restart: with proper pruning/culling, the Blocktree can be replayed by
ordered enumeration of entries from slot 0. The logic of the replay stage ordered enumeration of entries from slot 0. The logic of the replay stage
(i.e. dealing with forks) will have to be used for the most recent entries in (i.e. dealing with forks) will have to be used for the most recent entries in
the EntryTree. the Blocktree.
### EntryTree Design ### Blocktree Design
1. Entries in the EntryTree are stored as key-value pairs, where the key is the concatenated 1. Entries in the Blocktree are stored as key-value pairs, where the key is the concatenated
slot index and blob index for an entry, and the value is the entry data. Note blob indexes are zero-based for each slot (i.e. they're slot-relative). slot index and blob index for an entry, and the value is the entry data. Note blob indexes are zero-based for each slot (i.e. they're slot-relative).
2. The EntryTree maintains metadata for each slot, in the `SlotMeta` struct containing: 2. The Blocktree maintains metadata for each slot, in the `SlotMeta` struct containing:
* `slot_index` - The index of this slot * `slot_index` - The index of this slot
* `num_blocks` - The number of blocks in the slot (used for chaining to a previous slot) * `num_blocks` - The number of blocks in the slot (used for chaining to a previous slot)
* `consumed` - The highest blob index `n`, such that for all `m < n`, there exists a blob in this slot with blob index equal to `n` (i.e. the highest consecutive blob index). * `consumed` - The highest blob index `n`, such that for all `m < n`, there exists a blob in this slot with blob index equal to `n` (i.e. the highest consecutive blob index).
@ -110,18 +110,18 @@ slot index and blob index for an entry, and the value is the entry data. Note bl
3. Chaining - When a blob for a new slot `x` arrives, we check the number of blocks (`num_blocks`) for that new slot (this information is encoded in the blob). We then know that this new slot chains to slot `x - num_blocks`. 3. Chaining - When a blob for a new slot `x` arrives, we check the number of blocks (`num_blocks`) for that new slot (this information is encoded in the blob). We then know that this new slot chains to slot `x - num_blocks`.
4. Subscriptions - The EntryTree records a set of slots that have been "subscribed" to. This means entries that chain to these slots will be sent on the EntryTree channel for consumption by the ReplayStage. See the `EntryTree APIs` for details. 4. Subscriptions - The Blocktree records a set of slots that have been "subscribed" to. This means entries that chain to these slots will be sent on the Blocktree channel for consumption by the ReplayStage. See the `Blocktree APIs` for details.
5. Update notifications - The EntryTree notifies listeners when slot(n).is_trunk is flipped from false to true for any `n`. 5. Update notifications - The Blocktree notifies listeners when slot(n).is_trunk is flipped from false to true for any `n`.
### EntryTree APIs ### Blocktree APIs
The EntryTree offers a subscription based API that ReplayStage uses to ask for entries it's interested in. The entries will be sent on a channel exposed by the EntryTree. These subscription API's are as follows: The Blocktree offers a subscription based API that ReplayStage uses to ask for entries it's interested in. The entries will be sent on a channel exposed by the Blocktree. These subscription API's are as follows:
1. `fn get_slots_since(slot_indexes: &[u64]) -> Vec<SlotMeta>`: Returns new slots connecting to any element of the list `slot_indexes`. 1. `fn get_slots_since(slot_indexes: &[u64]) -> Vec<SlotMeta>`: Returns new slots connecting to any element of the list `slot_indexes`.
2. `fn get_slot_entries(slot_index: u64, entry_start_index: usize, max_entries: Option<u64>) -> Vec<Entry>`: Returns the entry vector for the slot starting with `entry_start_index`, capping the result at `max` if `max_entries == Some(max)`, otherwise, no upper limit on the length of the return vector is imposed. 2. `fn get_slot_entries(slot_index: u64, entry_start_index: usize, max_entries: Option<u64>) -> Vec<Entry>`: Returns the entry vector for the slot starting with `entry_start_index`, capping the result at `max` if `max_entries == Some(max)`, otherwise, no upper limit on the length of the return vector is imposed.
Note: Cumulatively, this means that the replay stage will now have to know when a slot is finished, and subscribe to the next slot it's interested in to get the next set of entries. Previously, the burden of chaining slots fell on the EntryTree. Note: Cumulatively, this means that the replay stage will now have to know when a slot is finished, and subscribe to the next slot it's interested in to get the next set of entries. Previously, the burden of chaining slots fell on the Blocktree.
### Interfacing with Bank ### Interfacing with Bank
@ -138,16 +138,16 @@ The bank exposes to replay stage:
3. `lockout period`: how long a chain must be observed to be in the ledger to 3. `lockout period`: how long a chain must be observed to be in the ledger to
be able to be chained below this vote be able to be chained below this vote
Replay stage uses EntryTree APIs to find the longest chain of entries it can Replay stage uses Blocktree APIs to find the longest chain of entries it can
hang off a previous vote. If that chain of entries does not hang off the hang off a previous vote. If that chain of entries does not hang off the
latest vote, the replay stage rolls back the bank to that vote and replays the latest vote, the replay stage rolls back the bank to that vote and replays the
chain from there. chain from there.
### Pruning EntryTree ### Pruning Blocktree
Once EntryTree entries are old enough, representing all the possible forks Once Blocktree entries are old enough, representing all the possible forks
becomes less useful, perhaps even problematic for replay upon restart. Once a becomes less useful, perhaps even problematic for replay upon restart. Once a
validator's votes have reached max lockout, however, any EntryTree contents validator's votes have reached max lockout, however, any Blocktree contents
that are not on the PoH chain for that vote for can be pruned, expunged. that are not on the PoH chain for that vote for can be pruned, expunged.
Replicator nodes will be responsible for storing really old ledger contents, Replicator nodes will be responsible for storing really old ledger contents,

4
src/db_ledger.rs
View File

@ -791,11 +791,11 @@ impl DbLedger {
} }
} }
// TODO: all this goes away with EntryTree // TODO: all this goes away with Blocktree
struct EntryIterator { struct EntryIterator {
db_iterator: DBRawIterator, db_iterator: DBRawIterator,
// TODO: remove me when replay_stage is iterating by block (EntryTree) // TODO: remove me when replay_stage is iterating by block (Blocktree)
// this verification is duplicating that of replay_stage, which // this verification is duplicating that of replay_stage, which
// can do this in parallel // can do this in parallel
last_id: Option<Hash>, last_id: Option<Hash>,