Skip to content

Commit 5464563

Browse files
authored
Details for conensus blog post (#304)
* Add links to Nancy Lynch, BFT, etc * Add section on explaining the 1/3 BFT threshold
1 parent aaf3c09 commit 5464563

File tree

1 file changed

+10
-4
lines changed
  • src/app/blog/consensus-is-impossible

1 file changed

+10
-4
lines changed

src/app/blog/consensus-is-impossible/page.mdx

Lines changed: 10 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ export const metadata = {
2828

2929
export default (props) => <BlogPostLayout article={post} {...props} />
3030

31-
Our latest video covers a proof paper by Nancy Lynch that shows that 100% certainty of consensus is impossible in a distributed system with even one faulty node. The paper is very comprensive, and we thought picking one to dramatize would be a great way to introduce impossibility proofs!
31+
Our latest video covers a proof paper by [Nancy Lynch] that shows that 100% certainty of consensus is impossible in a distributed system with even one faulty node. The paper is very comprensive, and we thought picking one to dramatize would be a great way to introduce impossibility proofs!
3232

3333
<iframe width="560" height="315" src="https://www.youtube.com/embed/_VAAC9Rt6H0?si=IWXKlPvoJ2qe6r9R" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
3434

@@ -44,15 +44,17 @@ Our latest video covers a proof paper by Nancy Lynch that shows that 100% certai
4444

4545
Indirectly, yes! All iroh protocols run up against these laws of distributed systems "physics". Some examples:
4646
* strictly speaking, [iroh docs](/proto/iroh-docs) isn't a consensus protocol, it's a "sync" protocol. Here even the word sync is a bit of a misnomer, because there is no such thing as asynchronus synchronization, but we digress. Instead the garuntee iroh docs focuses on is that all nodes will _eventually_ have the same data, once we all have the same entries in our namespace, not that they will all agree on the same data at the same time.
47-
* [iroh blobs](/proto/iroh-blobs) is content-addressed (refer by hash) specifically to get around the potential of byzantine faults, assuming you trust the hash you're asking for in the first place.
47+
* [iroh blobs](/proto/iroh-blobs) is content-addressed (refer by hash) specifically to get around the potential of [Byzantine faults][BFT], assuming you trust the hash you're asking for in the first place.
4848

4949
## The extra `t` is for buggy nodes
5050

51-
In the video, one fix to address the fault is to transition from requiring `2t + 1` to `3t + 1`. The detail we _don't_ cover in the video: the extra `t` describes that you're accounting for buggy/malicious nodes as well as down/delayed nodes. The down/delayed nodes would be covered by the `2t` part of the equation.
51+
In the video, one fix to address the fault is to transition from requiring `2t + 1` to `3t + 1`. The detail we _don't_ cover in the video: the extra `t` describes that you're accounting for buggy or malicious nodes (called ["Byzantine" nodes][BFT]) as well as down/delayed nodes. The down/delayed nodes would be covered by the `2t` part of the equation.
52+
53+
Flipping that ratio around, in essence this extra `t` says that if we want to account for buggy or malicious nodes, we can only tollerate _less than_ 1/3 of the nodes being down, delayed, or faulty instead less than half. This makes sense because we still need to handle the same cases as `2t+1`, but now we're also accounting for the fact that a node that is still sending messages could be giving you bad messages — so you need more redundancy. In a 3-node configuration, a single node failure means that you've already crossed that 1/3 threshold, so you need _at least_ one more healthy node in the system to acocunt for all of these possible errors.
5254

5355
## This is not the most interesting proof in the paper!
5456

55-
That honor goes to the [FLP impossibility proof](https://en.wikipedia.org/wiki/Consensus_(computer_science)#Solvability_results_for_some_agreement_problems), for which the authors won a Dijkstra prize. Nancy Lynch was a co-author on that paper as well, and it's a great read if you're interested in the topic!
57+
That honor goes to the [FLP impossibility proof](https://en.wikipedia.org/wiki/Consensus_(computer_science)#Solvability_results_for_some_agreement_problems), for which the authors won a [Dijkstra Prize]. Nancy Lynch was a co-author on that paper as well, and it's a great read if you're interested in the topic!
5658

5759
## Join our discord & nerd out
5860

@@ -62,3 +64,7 @@ Come tell us what we missed! We'll update here!
6264
<br />
6365
<br />
6466
<br />
67+
68+
[BFT]: https://en.wikipedia.org/wiki/Byzantine_fault
69+
[Dijkstra Prize]: https://www.sigops.org/awards/ewd/
70+
[Nancy Lynch]: https://people.csail.mit.edu/lynch/

0 commit comments

Comments
 (0)