Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix block ids in raft doc #321

Merged
merged 1 commit into from Jul 15, 2018
+3 −3
Merged

Fix block ids in raft doc #321

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
6 changes: 3 additions & 3 deletions raft/doc.md
View file
Open in desktop
Expand Up @@ -75,7 +75,7 @@ Consider the following example where this might occur, where Raft entries attemp

`[ 0xbeda Parent: 0xacaa ]`

Where `0xbeda` is the ID of new block, and `0xaa` is the ID of its parent. Here, the initial minter (node 1) is partitioned, and node 2 takes over as the minter.
Where `0xbeda` is the ID of new block, and `0xacaa` is the ID of its parent. Here, the initial minter (node 1) is partitioned, and node 2 takes over as the minter.

```
time block submissions
Expand All @@ -89,7 +89,7 @@ Where `0xbeda` is the ID of new block, and `0xaa` is the ID of its parent. Here,
|
| -- 1 rejoins --
|
v [ 0x8b37 Parent: 0x8b37 ]
v [ 0x8b37 Parent: 0x839c ]
```

Once the partition heals, at the Raft layer node1 will resubmit `0x2c52`, and the resulting serialized log might look as follows:
Expand All @@ -99,7 +99,7 @@ Once the partition heals, at the Raft layer node1 will resubmit `0x2c52`, and th
[ 0xf0ec Parent: 0xbeda - Extends! ] (due to node 2; let's call this the "winner")
[ 0x839c Parent: 0xf0ec - Extends! ] (due to node 2)
[ 0x2c52 Parent: 0xbeda - NO-OP. ] (due to node 1; let's call this the "loser")
[ 0x8b37 Parent: 0x8b37 - Extends! ] (due to node 2)
[ 0x8b37 Parent: 0x839c - Extends! ] (due to node 2)
```

Due to being serialized after the "winner," the "loser" entry will not extend the chain, because its parent (`0xbeda`) is no longer at the head of the chain when we apply the entry. The "winner" extended the same parent (`0xbeda`) earlier (and then `0x839c` extended it further.)
Expand Down