Fix URLs for images (#6148)
This commit is contained in:
Ryan Shea
Michael Vines
@ -58,7 +58,7 @@ Validators vote based on a greedy choice to maximize their reward described in [
|
||||
|
||||
The diagram below represents a validator's view of the PoH stream with possible forks over time. L1, L2, etc. are leader slots, and `E`s represent entries from that leader during that leader's slot. The `x`s represent ticks only, and time flows downwards in the diagram.
|
||||
|
||||
|
||||
|
||||
|
||||
Note that an `E` appearing on 2 forks at the same slot is a slashable condition, so a validator observing `E3` and `E3'` can slash L3 and safely choose `x` for that slot. Once a validator commits to a forks, other forks can be discarded below that tick count. For any slot, validators need only consider a single "has entries" chain or a "ticks only" chain to be proposed by a leader. But multiple virtual entries may overlap as they link back to the a previous slot.
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ A fullnode selects a fork by submiting a vote to a slot leader on that fork. The
|
||||
|
||||
An active fork is as a sequence of checkpoints that has a length at least one longer than the rollback depth. The shortest fork will have a length exactly one longer than the rollback depth. For example:
|
||||
|
||||
|
||||
|
||||
|
||||
The following sequences are _active forks_:
|
||||
|
||||
@ -23,13 +23,13 @@ A fullnode may vote on any checkpoint in the tree. In the diagram above, that's
|
||||
|
||||
Starting from the example above, wth a rollback depth of 2, consider a vote on 5 versus a vote on 6. First, a vote on 5:
|
||||
|
||||
|
||||
|
||||
|
||||
The new root is 2, and any active forks that are not descendants from 2 are pruned.
|
||||
|
||||
Alternatively, a vote on 6:
|
||||
|
||||
|
||||
|
||||
|
||||
The tree remains with a root of 1, since the active fork starting at 6 is only 2 checkpoints from the root.
|
||||
|
||||
|
||||
@ -138,7 +138,7 @@ Lamports build up over time in a Stake account and any excess over activated sta
|
||||
|
||||
## Example Callflow
|
||||
|
||||
|
||||
|
||||
|
||||
## Staking Rewards
|
||||
|
||||
|
||||
@ -20,15 +20,15 @@ This way each node only has to communicate with a maximum of `2 * DATA_PLANE_FAN
|
||||
|
||||
The following diagram shows how the Leader sends blobs with a Fanout of 2 to Neighborhood 0 in Layer 0 and how the nodes in Neighborhood 0 share their data with each other.
|
||||
|
||||
|
||||
|
||||
|
||||
The following diagram shows how Neighborhood 0 fans out to Neighborhoods 1 and 2.
|
||||
|
||||
|
||||
|
||||
|
||||
Finally, the following diagram shows a two layer cluster with a Fanout of 2.
|
||||
|
||||
|
||||
|
||||
|
||||
### Configuration Values
|
||||
|
||||
@ -40,5 +40,5 @@ Currently, configuration is set when the cluster is launched. In the future, the
|
||||
|
||||
The following diagram shows how two neighborhoods in different layers interact. To cripple a neighborhood, enough nodes \(erasure codes +1\) from the neighborhood above need to fail. Since each neighborhood receives blobs from multiple nodes in a neighborhood in the upper layer, we'd need a big network failure in the upper layers to end up with incomplete data.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -128,7 +128,7 @@ The total stake allocated to a VoteState program can be calculated by the sum of
|
||||
|
||||
## Example Callflow
|
||||
|
||||
|
||||
|
||||
|
||||
## Future work
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ A client _app_ interacts with a Solana cluster by sending it _transactions_ with
|
||||
|
||||
## Deploying Programs to a Cluster
|
||||
|
||||
|
||||
|
||||
|
||||
As shown in the diagram above a client creates a program and compiles it to an ELF shared object containing BPF bytecode and sends it to the Solana cluster. The cluster stores the program locally and makes it available to clients via a _program ID_. The program ID is a _public key_ generated by the client and is used to reference the program in subsequent transactions.
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ At any given point in time, a specific validator's interest rate can be determin
|
||||
|
||||
\*\*Figure 3:\*\* The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in \*\*Figure 2\*\* Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabalize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for both state-validation and ledger storage replication \(PoReps\) are not accounted for here. Given these example parameters, annualized validator-specific interest rates can be determined based on the global fraction of tokens bonded as stake, as well as their uptime/activity in the previous epoch. For the purpose of this example, we assume 100% uptime for all validators and a split in interest-based rewards between validators and replicator nodes of 80%/20%. Additionally, the fraction of staked circulating supply is assummed to be constant. Based on these assumptions, an annualized validation-client interest rate schedule as a function of % circulating token supply that is staked is shown in\*\* Figure 4\*\*.
|
||||
|
||||
|
||||
|
||||
|
||||
**Figure 4:** Shown here are example validator interest rates over time, neglecting transaction fees, segmented by fraction of total circulating supply bonded as stake.
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ A payment receipt is a data structure that contains a Merkle Path from a transac
|
||||
|
||||
An Entry-Merkle is a Merkle Root including all transactions in the entry, sorted by signature.
|
||||
|
||||
|
||||
|
||||
|
||||
A Block-Merkle is a Merkle root of all the Entry-Merkles sequenced in the block. Transaction status is necessary for the receipt because the state receipt is constructed for the block. Two transactions over the same state can appear in the block, and therefore, there is no way to infer from just the state whether a transaction that is committed to the ledger has succeeded or failed in modifying the intended state. It may not be necessary to encode the full status code, but a single status bit to indicate the transaction's success.
|
||||
|
||||
@ -48,7 +48,7 @@ At the end of the block, A and B are in the exact same starting state, and any s
|
||||
|
||||
The Bank-Merkle is computed from the Merkle Tree of the new state changes, along with the Previous Bank-Merkle, and the Block-Merkle.
|
||||
|
||||
|
||||
|
||||
|
||||
A state receipt contains only the state changes occurring in the block. A direct Merkle Path to the current Bank-Merkle guarantees the state value at that bank hash, but it cannot be used to generate a “current” receipt to the latest state if the state modification occurred in some previous block. There is no guarantee that the path provided by the validator is the latest one available out of all the previous Bank-Merkles.
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ The fundamental difference between the pipelines is when the PoH is present. In
|
||||
|
||||
We unwrap the many abstraction layers and build a single pipeline that can toggle leader mode on whenever the validator's ID shows up in the leader schedule.
|
||||
|
||||
|
||||
|
||||
|
||||
## Notable changes
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Anatomy of a Validator
|
||||
|
||||
|
||||
|
||||
|
||||
## Pipelining
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@ Transactions are batched and processed in a pipeline. The TPU and TVU follow a s
|
||||
|
||||
The TVU runtime ensures that PoH verification occurs before the runtime processes any transactions.
|
||||
|
||||
|
||||
|
||||
|
||||
At the _execute_ stage, the loaded accounts have no data dependencies, so all the programs can be executed in parallel.
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# TPU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# TVU
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user