backticks and missing variable descriptions
This commit is contained in:
@ -26,7 +26,7 @@ All `T` ticks must be observed from the current leader for that part of PoH to b
|
||||
|
||||
## Partitions, Forks
|
||||
|
||||
Forks can arise at PoH tick counts that correspond to leader rotations, because leader nodes may or may not have observed the previous leader's data. These empty ticks are generated by all nodes in the network at a network-specified rate for hashes/per/tick `Z`.
|
||||
Forks can arise at PoH tick counts that correspond to leader rotations, because leader nodes may or may not have observed the previous leader's data. These empty ticks are generated by all nodes in the network at a network-specified rate for hashes-per-tick `Z`.
|
||||
|
||||
There are only two possible versions of the PoH during a voting period: PoH with `T` ticks and entries generated by the current leader, or PoH with just ticks. The "just ticks" version of the PoH can be thought of as a virtual ledger, one that all nodes in the network can derive from the last tick in the previous period.
|
||||
|
||||
@ -52,12 +52,12 @@ It's useful to consider leader rotation over PoH tick count as time division of
|
||||
leader period | L1 | L2 | L3 | L4 | L5
|
||||
-------|----|----|----|----|----
|
||||
data | E1| E2 | E3 | E4 | E5
|
||||
ticks to prev | | | | x | xx
|
||||
ticks since prev | | | | x | xx
|
||||
|
||||
Note that only data from leader L3 will be accepted during leader period L3.
|
||||
Data from L3 may include "catchup" ticks back to a period other than L2 if L3
|
||||
did not observe L2's data. L4 and L5's transmissions include the "ticks to
|
||||
prev" PoH entries.
|
||||
Note that only data from leader `L3` will be accepted during leader period
|
||||
`L3`. Data from `L3` may include "catchup" ticks back to a period other than
|
||||
`L2` if `L3` did not observe `L2`'s data. `L4` and `L5`'s transmissions
|
||||
include the "ticks since prev" PoH entries.
|
||||
|
||||
This arrangement of the network data streams permits nodes to save exactly this
|
||||
to the ledger for replay, restart, and checkpoints.
|
||||
@ -72,35 +72,45 @@ period.
|
||||
## Examples
|
||||
|
||||
### Small Partition
|
||||
1. Network partition M occurs for 10% of the nodes
|
||||
2. The larger partition K, with 90% of the stake weight continues to operate as
|
||||
1. Network partition `M` occurs for 10% of the nodes
|
||||
2. The larger partition `K`, with 90% of the stake weight continues to operate as
|
||||
normal
|
||||
3. M cycles through the ranks until one of them is leader, generating ticks for
|
||||
periods where the leader is in K.
|
||||
4. M validators observe 10% of the vote pool, finality is not reached.
|
||||
5. M and K re-connect.
|
||||
6. M validators cancel their votes on M, which has not reached finality, and
|
||||
re-cast on K (after their vote lockout on M).
|
||||
3. `M` cycles through the ranks until one of them is leader, generating ticks for
|
||||
periods where the leader is in `K`.
|
||||
4. `M` validators observe 10% of the vote pool, finality is not reached.
|
||||
5. `M` and `K` reconnect.
|
||||
6. `M` validators cancel their votes on `M`, which has not reached finality, and
|
||||
re-cast on `K` (after their vote lockout on `M`).
|
||||
|
||||
### Leader Timeout
|
||||
1. Next rank leader node V observes a timeout from current leader A, fills in
|
||||
A's period with virtual ticks and starts sending out entries.
|
||||
2. Nodes observing both streams keep track of the forks, waiting for: a. their
|
||||
vote on leader A to expire in order to be able to vote on B b. a
|
||||
supermajority on A's period
|
||||
3. If a occurs, leader B's period is filled with ticks, if b occurs, A's period
|
||||
is filled with ticks
|
||||
4. Partition is resolved just like in the [Small Partition](#small-parition) above
|
||||
1. Next rank leader node `V` observes a timeout from current leader `A`, fills in
|
||||
`A`'s period with virtual ticks and starts sending out entries.
|
||||
2. Nodes observing both streams keep track of the forks, waiting for:
|
||||
* their vote on leader `A` to expire in order to be able to vote on `B`
|
||||
* a supermajority on `A`'s period
|
||||
3. If the first case occurs, leader `B`'s period is filled with ticks. if the
|
||||
second case occurs, A's period is filled with ticks
|
||||
4. Partition is resolved just like in the [Small Partition](#small-parition)
|
||||
above
|
||||
|
||||
|
||||
## Network Variables
|
||||
|
||||
`A` - name of a node
|
||||
|
||||
`B` - name of a node
|
||||
|
||||
`K` - number of nodes in the supermajority to whom leaders broadcast their
|
||||
PoH hash for validation
|
||||
|
||||
`M` - number of nodes outside the supermajority to whom leaders broadcast their
|
||||
PoH for validation
|
||||
PoH hash for validation
|
||||
|
||||
`N` - number of voting rounds for which a leader schedule is considered before
|
||||
a new leader schedule is used
|
||||
|
||||
`T` - number of PoH ticks per leader period (also voting period)
|
||||
|
||||
`V` - name of a node that will create virtual ticks
|
||||
|
||||
`Z` - number of hashes per PoH tick
|
||||
|
Reference in New Issue
Block a user