Skip to content
This repository was archived by the owner on Nov 15, 2023. It is now read-only.

Commit fde3bfc

Browse files
tomusdrwtomusdrw
committed
Merge branch 'master' into td-check-era-companion
2 parents edabe73 + c948d2c commit fde3bfc

File tree

5 files changed

+65
-89
lines changed

5 files changed

+65
-89
lines changed

‎roadmap/implementors-guide/.gitignore‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1 +1,2 @@
11
book/
2+
*.generated.svg

‎roadmap/implementors-guide/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
The implementers' guide is compiled from several source files with [mdBook](https://github.com/rust-lang/mdBook). To view it live, locally, from the repo root:
44

55
```sh
6-
cargo install mdbook mdbook-linkcheck
6+
cargo install mdbook mdbook-linkcheck mdbook-graphviz
77
mdbook serve roadmap/implementors-guide
88
open http://localhost:3000
99
```

‎roadmap/implementors-guide/book.toml‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,5 +5,8 @@ multilingual = false
55
src = "src"
66
title = "The Polkadot Parachain Host Implementers' Guide"
77

8+
[preprocessor.graphviz]
9+
command = "mdbook-graphviz"
10+
811
[output.html]
912
[output.linkcheck]

‎roadmap/implementors-guide/src/architecture.md‎

Lines changed: 25 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -2,25 +2,22 @@
22

33
Our Parachain Host includes a blockchain known as the relay-chain. A blockchain is a Directed Acyclic Graph (DAG) of state transitions, where every block can be considered to be the head of a linked-list (known as a "chain" or "fork") with a cumulative state which is determined by applying the state transition of each block in turn. All paths through the DAG terminate at the Genesis Block. In fact, the blockchain is a tree, since each block can have only one parent.
44

5-
```text
6-
+----------------+ +----------------+
7-
| Block 4 | | Block 5 |
8-
+----------------+ +----------------+
9-
\ /
10-
V V
11-
+---------------+
12-
| Block 3 |
13-
+---------------+
14-
|
15-
V
16-
+----------------+ +----------------+
17-
| Block 1 | | Block 2 |
18-
+----------------+ +----------------+
19-
\ /
20-
V V
21-
+----------------+
22-
| Genesis |
23-
+----------------+
5+
```dot process
6+
digraph {
7+
node [shape=box];
8+
genesis [label = Genesis]
9+
b1 [label = "Block 1"]
10+
b2 [label = "Block 2"]
11+
b3 [label = "Block 3"]
12+
b4 [label = "Block 4"]
13+
b5 [label = "Block 5"]
14+
15+
b5 -> b3
16+
b4 -> b3
17+
b3 -> b1
18+
b2 -> genesis
19+
b1 -> genesis
20+
}
2421
```
2522

2623
A blockchain network is comprised of nodes. These nodes each have a view of many different forks of a blockchain and must decide which forks to follow and what actions to take based on the forks of the chain that they are aware of.
@@ -34,26 +31,16 @@ The first category of questions will be addressed by the Runtime, which defines
3431

3532
The second category of questions addressed by Node-side behavior. Node-side behavior defines all activities that a node undertakes, given its view of the blockchain/block-DAG. Node-side behavior can take into account all or many of the forks of the blockchain, and only conditionally undertake certain activities based on which forks it is aware of, as well as the state of the head of those forks.
3633

37-
```text
34+
```dot process
35+
digraph G {
36+
Runtime [shape=box]
37+
"Node" [shape=box margin=0.5]
38+
Transport [shape=rectangle width=5]
39+
40+
Runtime -> "Node" [dir=both label="Runtime API"]
3841
39-
__________________________________
40-
/ \
41-
| Runtime |
42-
| |
43-
\_________(Runtime API )___________/
44-
| ^
45-
V |
46-
+----------------------------------------------+
47-
| |
48-
| Node |
49-
| |
50-
| |
51-
+----------------------------------------------+
52-
+ +
53-
| |
54-
--------------------+ +------------------------
55-
Transport
56-
------------------------------------------------
42+
"Node" -> Transport [penwidth=1]
43+
}
5744
5845
```
5946

‎roadmap/implementors-guide/src/parachains-overview.md‎

Lines changed: 35 additions & 50 deletions
Original file line numberDiff line numberDiff line change
@@ -60,61 +60,46 @@ Reiterating the lifecycle of a candidate:
6060
6161
It is also important to take note of the fact that the relay-chain is extended by BABE, which is a forkful algorithm. That means that different block authors can be chosen at the same time, and may not be building on the same block parent. Furthermore, the set of validators is not fixed, nor is the set of parachains. And even with the same set of validators and parachains, the validators' assignments to parachains is flexible. This means that the architecture proposed in the next chapters must deal with the variability and multiplicity of the network state.
6262

63-
```text
64-
65-
....... Validator Group 1 ..........
66-
. .
67-
. (Validator 4) .
68-
. (Validator 1) (Validator 2) .
69-
. (Validator 5) .
70-
. .
71-
..........Building on C ........... ........ Validator Group 2 ...........
72-
+----------------------+ . .
73-
| Relay Block C | . (Validator 7) .
74-
+----------------------+ . ( Validator 3) (Validator 6) .
75-
\ . .
76-
\ ......... Building on B .............
77-
\
78-
+----------------------+
79-
| Relay Block B |
80-
+----------------------+
81-
|
82-
+----------------------+
83-
| Relay Block A |
84-
+----------------------+
8563

64+
```dot process
65+
digraph {
66+
rca [label = "Relay Block A" shape=rectangle]
67+
rcb [label = "Relay Block B" shape=rectangle]
68+
rcc [label = "Relay Block C" shape=rectangle]
69+
70+
vg1 [label =<<b>Validator Group 1</b><br/><br/><font point-size="10">(Validator 4)<br/>(Validator 1) (Validator 2)<br/>(Validator 5)</font>>]
71+
vg2 [label =<<b>Validator Group 2</b><br/><br/><font point-size="10">(Validator 7)<br/>(Validator 3) (Validator 6)</font>>]
72+
73+
rcb -> rca
74+
rcc -> rcb
75+
76+
vg1 -> rcc [label="Building on C" style=dashed arrowhead=none]
77+
vg2 -> rcb [label="Building on B" style=dashed arrowhead=none]
78+
}
8679
```
8780

8881
In this example, group 1 has received block C while the others have not due to network asynchrony. Now, a validator from group 2 may be able to build another block on top of B, called C'. Assume that afterwards, some validators become aware of both C and C', while others remain only aware of one.
8982

90-
```text
91-
....... Validator Group 1 .......... ........ Validator Group 2 ...........
92-
. . . .
93-
. (Validator 4) (Validator 1) . . (Validator 7) (Validator 6) .
94-
. . . .
95-
.......... Building on C .......... ......... Building on C' .............
96-
97-
98-
....... Validator Group 3 ..........
99-
. .
100-
. (Validator 2) (Validator 3) .
101-
. (Validator 5) .
102-
. .
103-
....... Building on C and C' .......
104-
105-
+----------------------+ +----------------------+
106-
| Relay Block C | | Relay Block C' |
107-
+----------------------+ +----------------------+
108-
\ /
109-
\ /
110-
\ /
111-
+----------------------+
112-
| Relay Block B |
113-
+----------------------+
114-
|
115-
+----------------------+
116-
| Relay Block A |
117-
+----------------------+
83+
```dot process
84+
digraph {
85+
rca [label = "Relay Block A" shape=rectangle]
86+
rcb [label = "Relay Block B" shape=rectangle]
87+
rcc [label = "Relay Block C" shape=rectangle]
88+
rcc_prime [label = "Relay Block C'" shape=rectangle]
89+
90+
vg1 [label =<<b>Validator Group 1</b><br/><br/><font point-size="10">(Validator 4) (Validator 1)</font>>]
91+
vg2 [label =<<b>Validator Group 2</b><br/><br/><font point-size="10">(Validator 7) (Validator 6)</font>>]
92+
vg3 [label =<<b>Validator Group 3</b><br/><br/><font point-size="10">(Validator 2) (Validator 3)<br/>(Validator 5)</font>>]
93+
94+
rcb -> rca
95+
rcc -> rcb
96+
rcc_prime -> rcb
97+
98+
vg1 -> rcc [style=dashed arrowhead=none]
99+
vg2 -> rcc_prime [style=dashed arrowhead=none]
100+
vg3 -> rcc_prime [style=dashed arrowhead=none]
101+
vg3 -> rcc [style=dashed arrowhead=none]
102+
}
118103
```
119104

120105
Those validators that are aware of many competing heads must be aware of the work happening on each one. They may contribute to some or a full extent on both. It is possible that due to network asynchrony two forks may grow in parallel for some time, although in the absence of an adversarial network this is unlikely in the case where there are validators who are aware of both chain heads.

0 commit comments

Comments
 (0)