No longer reserve terms from the terminology chapter
We followed the precedent set by the Rust book here, but now that proposals are integrated, each proposal can simply include its own terminology section.
This commit is contained in:
Greg Fitzgerald
parent
3413ecc2bd
commit
9a49ace606
|
|
@ -1,38 +0,0 @@
|
|||
# EntryTree
|
||||
|
||||
This chapter describes how the TVU manages forks generated by leader rotation.
|
||||
|
||||
### Unified Window and Ledger: EntryTree
|
||||
|
||||
A unified window and ledger allows a validator to record every blob it observes on the network, in any order, as long as the blob is consistent with the network's leader schedule.
|
||||
|
||||
Blobs are moved to a fork-able key space the tuple of `leader slot` + `blob index` (within the slot). This permits the skip-list structure of the Solana protocol to be stored in its entirety, without a-priori choosing which fork to 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 of deeper storage for less recent blobs, as implemented by the store backing EntryTree.
|
||||
|
||||
### Functionalities of EntryTree
|
||||
|
||||
1. Persistence: the EntryTree lives in the front of the nodes verification pipeline, right behind network receive and signature verification. If the blob received is consistent with the leader schedule (i.e. was signed by the leader for the indicated slot), it is immediately stored.
|
||||
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, preserving the chain of origination.
|
||||
3. Forks: EntryTree supports random access of blobs, so can support a validator's need to rollback and replay from a Bank checkpoint.
|
||||
4. Restart: with proper pruning/culling, the EntryTree can be replayed by 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 the EntryTree.
|
||||
|
||||
### Interfacing with Bank
|
||||
|
||||
The bank exposes to replay stage:
|
||||
|
||||
1. prev_id: which PoH chain it's working on as indicated by the id of the last entry it processed
|
||||
2. tick_height: the ticks in the PoH chain currently being verified by this bank
|
||||
3. votes: a stack of records that contain
|
||||
|
||||
1. prev_ids: what anything after this vote must chain to in PoH
|
||||
2. tick height: the tick_height at which this vote was cast
|
||||
3. lockout period: how long a chain must be observed to be in the ledger to be able to be chained below this vote
|
||||
|
||||
Replay stage uses EntryTree 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 latest vote, the replay stage rolls back the bank to that vote and replays the chain from there.
|
||||
|
||||
### Pruning EntryTree
|
||||
|
||||
Once EntryTree entries are old enough, representing all the possible forks becomes less useful, perhaps even problematic for replay upon restart. Once a validator's votes have reached max lockout, however, any EntryTree contents 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, and validators need only persist their bank periodically.
|
||||
|
|
@ -36,8 +36,8 @@ leaders will not be able to use censorship to influence the leader schedule.
|
|||
|
||||
## Appending Entries
|
||||
|
||||
A leader schedule is split into *slots*, where each slot has a duration of `T`
|
||||
PoH ticks.
|
||||
The lifetime of a leader schedule is called an *epoch*. The epoch is split into
|
||||
*slots*, where each slot has a duration of `T` PoH ticks.
|
||||
|
||||
A leader transmits entries during its slot. After `T` ticks, all the
|
||||
validators switch to the next scheduled leader. Validators must ignore entries
|
||||
|
|
@ -45,9 +45,8 @@ sent outside a leader's assigned slot.
|
|||
|
||||
All `T` ticks must be observed by the next leader for it to build its own
|
||||
entries on. If entries are not observed (leader is down) or entries are invalid
|
||||
(leader is buggy or malicious), the next leader must produce ticks to
|
||||
fill the previous leader's slot. Note that the next leader should do repair
|
||||
requests in parallel, and postpone sending ticks until it is confident other
|
||||
validators also failed to observe the previous leader's entries. If a leader
|
||||
incorrectly builds on its own ticks, the leader following it must replace all
|
||||
its ticks.
|
||||
(leader is buggy or malicious), the next leader must produce ticks to fill the
|
||||
previous leader's slot. Note that the next leader should do repair requests in
|
||||
parallel, and postpone sending ticks until it is confident other validators
|
||||
also failed to observe the previous leader's entries. If a leader incorrectly
|
||||
builds on its own ticks, the leader following it must replace all its ticks.
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ proof and it also requires the validator to have the entirety of the encrypted
|
|||
data present for verification of every proof of every identity. So the space
|
||||
required to validate is `number_of_proofs * data_size`
|
||||
|
||||
## Definitions
|
||||
## Terminology
|
||||
|
||||
#### replicator
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ They have some stake that they have put up as collateral that ensures that
|
|||
their work is honest. If you can prove that a validator verified a fake PoRep,
|
||||
then the validators stake can be slashed.
|
||||
|
||||
Replicators are specialized thin clients. They download a part of the ledger
|
||||
Replicators are specialized *light clients*. They download a part of the ledger
|
||||
and store it, and provide PoReps of storing the ledger. For each verified PoRep
|
||||
replicators earn a reward of sol from the mining pool.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,6 @@
|
|||
# Terminology
|
||||
|
||||
## Teminology Currently in Use
|
||||
|
||||
The following list contains words commonly used throughout the Solana
|
||||
architecture.
|
||||
The following terms are used throughout this book.
|
||||
|
||||
#### account
|
||||
|
||||
|
|
@ -14,6 +11,11 @@ A persistent file addressed by [public key](#public-key) and with
|
|||
|
||||
A front-end application that interacts with a Solana cluster.
|
||||
|
||||
#### blob
|
||||
|
||||
A fraction of a [block](#block); the smallest unit sent between
|
||||
[fullnodes](#fullnode).
|
||||
|
||||
#### block
|
||||
|
||||
A contiguous set of [entries](#entry) on the ledger covered by a [vote](#ledger-vote).
|
||||
|
|
@ -32,6 +34,12 @@ A [node](#node) that utilizes the [cluster](#cluster).
|
|||
|
||||
A set of [fullnodes](#fullnode) maintaining a single [ledger](#ledger).
|
||||
|
||||
#### confirmation
|
||||
|
||||
The wallclock duration between a [leader](#leader) creating a [tick
|
||||
entry](#tick) and recognizing a supermajority of [ledger votes](#ledger-vote)
|
||||
with a ledger interpretation that matches the leader's.
|
||||
|
||||
#### control plane
|
||||
|
||||
A gossip network connecting all [nodes](#node) of a [cluster](#cluster).
|
||||
|
|
@ -51,11 +59,10 @@ typically serves to validate and sign transactions.
|
|||
An entry on the [ledger](#ledger) either a [tick](#tick) or a [transactions
|
||||
entry](#transactions-entry).
|
||||
|
||||
#### confirmation
|
||||
#### epoch
|
||||
|
||||
The wallclock duration between a [leader](#leader) creating a [tick
|
||||
entry](#tick) and recognizing a supermajority of [ledger votes](#ledger-vote)
|
||||
with a ledger interpretation that matches the leader's.
|
||||
The time, i.e. number of [slots](#slot), for which a [leader
|
||||
schedule](#leader-schedule) is valid.
|
||||
|
||||
#### fork
|
||||
|
||||
|
|
@ -96,8 +103,8 @@ A fractional [native token](#native-token) with the value of approximately
|
|||
|
||||
#### loader
|
||||
|
||||
A [program](#program) with the ability to interpret the binary encoding
|
||||
of other on-chain programs.
|
||||
A [program](#program) with the ability to interpret the binary encoding of
|
||||
other on-chain programs.
|
||||
|
||||
#### leader
|
||||
|
||||
|
|
@ -120,8 +127,14 @@ A list of [entries](#entry) containing [transactions](#transaction) signed by
|
|||
A [hash](#hash) of the [fullnode's state](#fullnode-state) at a given [tick
|
||||
height](#tick-height). It comprises a validator's affirmation that a
|
||||
[block](#block) it has received has been verified, as well as a promise not to
|
||||
vote for a conflicting [block](#block) (i.e. [fork](#fork)) for a specific amount
|
||||
of time, the [lockout](#lockout) period.
|
||||
vote for a conflicting [block](#block) (i.e. [fork](#fork)) for a specific
|
||||
amount of time, the [lockout](#lockout) period.
|
||||
|
||||
#### light client
|
||||
|
||||
A type of [client](#client) that can verify it's pointing to a valid
|
||||
[cluster](#cluster). It performs more ledger verification than a [thin
|
||||
client](#thin-client) and less than a [fullnode](#fullnode).
|
||||
|
||||
#### lockout
|
||||
|
||||
|
|
@ -176,6 +189,11 @@ by the company Solana.
|
|||
Tokens forfeit to the [cluster](#cluster) if malicious [fullnode](#fullnode)
|
||||
behavior can be proven.
|
||||
|
||||
#### thin client
|
||||
|
||||
A type of [client](#client) that trusts it is communicating with a valid
|
||||
[cluster](#cluster).
|
||||
|
||||
#### tick
|
||||
|
||||
A ledger [entry](#entry) that estimates wallclock duration.
|
||||
|
|
@ -214,35 +232,3 @@ See [ledger vote](#ledger-vote)
|
|||
|
||||
See [block](#block)
|
||||
|
||||
## Terminology Reserved for Future Use
|
||||
|
||||
The following keywords do not have any functionality but are reserved by Solana
|
||||
for potential future use.
|
||||
|
||||
#### blob
|
||||
|
||||
A fraction of a [block](#block); the smallest unit sent between
|
||||
[fullnodes](#fullnode).
|
||||
|
||||
#### curio
|
||||
|
||||
A scarce, non-fungible member of a set of curios.
|
||||
|
||||
#### epoch
|
||||
|
||||
The time, i.e. number of [slots](#slot), for which a [leader
|
||||
schedule](#leader-schedule) is valid.
|
||||
|
||||
#### light client
|
||||
|
||||
A type of [client](#client) that can verify it's pointing to a valid
|
||||
[cluster](#cluster).
|
||||
|
||||
#### mips
|
||||
|
||||
Millions of [instructions](#instruction) per second.
|
||||
|
||||
#### thin client
|
||||
|
||||
A type of [client](#client) that trusts it is communicating with a valid
|
||||
[cluster](#cluster).
|
||||
|
|
|
|||
Loading…
Reference in New Issue