github/darkfi
1
1
Fork 0
mirror of https://github.com/darkrenaissance/darkfi.git synced 2026-04-28 03:00:18 -04:00
Code Issues Packages Projects Releases Wiki Activity

book: grammar edit, consensus.md

Browse Source
This commit is contained in:
lunar-mining
2022-11-23 11:48:46 +01:00
parent 4f45b5cae3
commit 8df8653379
1 changed files with 32 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
doc/src/architecture/consensus.md
View File

@@ -6,24 +6,25 @@ This section of the book describes how nodes participating in the DarkFi blockch
| Name | Description |
|------------------------|-------------------------------------------------------------------------------------------|
| Consensus | Algorithm for reaching Blockchain consensus between participating nodes |
| Consensus | Algorithm for reaching blockchain consensus between participating nodes |
| Node | darkfid daemon participating in the network |
| Slot | Specified timeframe for block production, measured in seconds(default=20) |
| Epoch | Specified timeframe for blockchain events, measured in slots(default=10) |
| Leader | Block producer |
| Unproposed Transaction | A transaction that exists in nodes memory pool, but have not yet been included in a block |
| P2P network | Peer-To-Peer network all nodes communicate with each other |
| Finalization | Append a Block and its content to canonical blockchain |
| Fork | Chain of unfinalized blocks, starting by the last canonical block of blockchain |
| Unproposed Transaction | Transaction that exists in the memory pool but has not yet been included in a block |
| Block proposal | Block that has not yet been appended onto the canonical blockchain |
| P2P network | Peer-to-peer network on which nodes communicate with eachother |
| Finalization | State achieved when a block and its contents are appended to the canonical blockchain |
| Fork | Chain of unfinalized blocks that begins with the last block of the canonical blockchain |
## Node main loop
As described in previous chapter, DarkFi is based on Ouroboros Crypsinous, therefore, to be able to produce a block,
at slot start each node checks if they are the slots' leader, based on the leader selection algorithm.
If they succeed, they can produce a block containing unproposed transactions, by extending the largest known fork,
and share it with rest nodes, by broadcasting it in the P2P network.
Right before slot end, each node triggers the finalization check, to verify which blocks can be finalized,
also known as finalization sync period.
As described in previous chapter, DarkFi is based on Ouroboros Crypsinous. Therefore, block production involves the following steps:
At the start of every slot, each node runs a leader selection algorithm to determine if they are the slot's leader. If successful, they can produce a block containing unproposed transactions. This block is then appended to the largest known fork
and shared with rest of the nodes on the P2P network.
Right before the end of every slot each node triggers a _finalization check_, to verify which blocks can be finalized.
This is also known as the finalization sync period.
Pseudocode:
```
@@ -47,21 +48,21 @@ loop {
## Listening for blocks
Concurently with the main loop, each node listens to new block proposals, and upon receiving them,
they try to extend a known fork, as described in next section.
Each node listens to new block proposals concurrently with the main loop. Upon receiving block proposals,
nodes try to extend the proposals onto a fork that they hold in memory. This process is described in the next section.
## Fork extension
Since there can be more than one slot leaders, each node holds a set of known forks in memory.
When a node becomes leader, they extend the longest fork they hold.
Upon receiving a block, one of the following cases occur:
Since there can be more than one slot leader, each node holds a set of known forks in memory.
When a node becomes a leader, they extend the longest fork they hold.
Upon receiving a block, one of the following cases may occur:
| Description | Handling |
|-------------------------------------------|---------------------------------------------------------------------|
| Block extends a known fork at its end | Append block to fork |
| Block extends a known fork not at its end | Create a new fork up to the extended block and append the new block |
| Block extends canonical blockchain | Create a new fork containing the new block |
| Block doesn't extends any known chains | Ignore block |
| Block doesn't extend any known chain | Ignore block |
### Visual Examples
@@ -81,7 +82,7 @@ Starting state:
#### Case 1
New proposal received extending L0 fork:
Extending L0 fork with a new block proposal:
|--[L0]+--[L2] <-- L0L2 fork
[C]--...--[C]--|
@@ -89,7 +90,7 @@ New proposal received extending L0 fork:
#### Case 2
New proposal received extending L0L2 fork at [L0] slot:
Extending L0L2 fork at [L0] slot with a new block proposal:
|--[L0]--[L2] <-- L0L2 fork
[C]--...--[C]--|
@@ -99,7 +100,7 @@ New proposal received extending L0L2 fork at [L0] slot:
##### Case 3
New proposal received extending canonical:
Extending the canonical blockchain with a new block proposal:
|--[L0]--[L2] <-- L0L2 fork
[C]--...--[C]--|
@@ -112,15 +113,13 @@ New proposal received extending canonical:
## Finalization
When finalization sync period kicks in, each node finds the longest fork chain it holds, that is at least 3 blocks long,
without any other fock chain with same length.
If such a fork chain exists, nodes finalizes(appends to canonical blockchain) all proposed blocks up to the last one.
When a fork chain gets finalized, rest fork chains are removed from nodes memory pool.
This practically means, that while we have competting(same length) fork chains,
no finalization occurs until a slot with a single leader happens.
When the finalization sync period kicks in, each node looks up the longest fork chain it holds. This must be at least 3 blocks long and there must be no other fork chain with same length.
If such a fork chain exists, nodes finalize all proposed blocks up to the last one by appending them to the canonical blockchain.
Once finalized, all other fork chains are removed from the memory pool.
Practically this means that no finalization can occur while we have competing fork chains of the same length. In such a case, finalization can only occur when we have a a slot with a single leader.
We continue Case 3 from previous sector to visualize this logic.
On slot 5, node observes 2 proposals, one extending L0L2 fork and one extending L0L3 fork:
We continue Case 3 from the previous section to visualize this logic.
On slot 5, a node observes 2 proposals. One extends the L0L2 fork, and the other extends the L0L3 fork:
|--[L0]--[L2]+--[L5a] <-- L0L2L5a fork
[C]--...--[C]--|
@@ -130,8 +129,8 @@ On slot 5, node observes 2 proposals, one extending L0L2 fork and one extending
|
|--[L4] <-- L4 fork
Finalization cannot occur, since we have two competting fork chains.
On next slot, node only observers 1 proposal, extending L0L3L5b fork:
Since we have two competing fork chains finalization cannot occur.
On next slot, a node only observes 1 proposal. So it extends the L0L3L5b fork:
|--[L0]--[L2]--[L5a] <-- L0L2L5a fork
[C]--...--[C]--|
@@ -141,7 +140,7 @@ On next slot, node only observers 1 proposal, extending L0L3L5b fork:
|
|--[L4] <-- L4 fork
When finalization sync period starts, node sees that it can finalize fork L0L3L5bL6 and drop rest forks:
When the finalization sync period starts, the node finalizes the fork L0L3L5bL6 and all other forks get dropped:
|/--[L0]--[L2]--[L5a] <-- L0L2L5a fork
[C]--...--[C]--|
@@ -152,9 +151,9 @@ When finalization sync period starts, node sees that it can finalize fork L0L3L5
|/--[L4] <-- L4 fork
resulting in the following state:
This results in the following state:
[C]--...--[C]--|--[L6]
where canonical contains blocks L0, L3 and L5b from L0L3L56L6 fork.
The canonical blockchain contains blocks L0, L3 and L5b from the L0L3L56L6 fork.