sternhenri
commented
5 years ago Thank you for this. Also adding this here:
I'll add a couple more also motivating "Why not simply adapt an existing Consensus Scheme and drop it into SPC?"
Assumption 5: Simplicity of deployment is a goal
The state of art in the field is fast evolving with academic constructions coming and going at a fast pace (eg SW->Thunder) and no single lexicon yet defined through which to compare tradeoffs (though candidates are slowly starting to emerge). Given that fact, gaining a clear understanding of what tradeoffs we are making in picking an external solution for Filecoin is arduous. Further, most proposed constructions cater to an academic audience and are untested in production. For both reasons, adapting an existing solution provides clear disadvantages over developing our own with inspiration from the state of art. As Raft did with Paxos, we seek to provide a simple solution that takes recent advances into account and sees production-usage as a first class goal.
Assumption 6: Redefining abstractions through Filecoin--as a form of power fault tolerance--will yield interesting results
With Filecoin consensus as a prism through which to think more generally about the interfaces between power fault tolerance and proof of stake protocols, we may get interesting generalizable results that help proper further research in the space.
Here's my understanding. I'm writing it as a set of assumptions that could use more explanation themselves. This level of abstraction has helped me a lot when explaining EC's place in filecoin to myself. Things in quotes are under specified and could be replaced with more formal definitions.
Assumption 1: Algorand Style Cryptographic Sortition is "Good"
We believe section 5.9 in the Algorand theory paper. Using a VRF style ticket generator seems like a good way to get "secure" randomness into the system that an adversary can't "influence too much". Just as important leader elections can be secret (non-globally predictable).
Assumption 2: Longest Chain is "Good"
We don't want the complexity of Algorand's classical byzantine agreement protocol. We would rather use the simple and familiar blockchain concept. Reasoning about this in a proof of stake context is something that Snow White does thoroughly. We build off of that work, combining with ideas from Algorand.
Assumption 3: Waiting isn't Rational
A fundamental assumption of the sleepy consensus protocol that SW builds on top of is that honest nodes will wait a block time before accepting any blocks in the next round. We do not believe that this is rational. Lack of waiting could lead to attacks or unhealthy centralization effects. For this reason EC requires a hardware mechanism to enforce slow block times.
Assumption 4: GHOST is "Good"
We can "speed up" consensus and "prevent attacks" by rewarding all leaders instead of forcing a fork unnecessarily. The "same parent set => same tipset" heuristic is a good balance between not forcing too many forks and not enabling block withholders / destabilizing transaction serialization. This addresses the issue from both SW and Algorand that simple sortition's can't provide very good guarantees around getting one leader every time, i.e. SSLE is hard, so we need other mechanisms to narrow down leaders, i.e. forks or BA*.
Meta Assumption: We can do all of this without shooting ourselves in the foot.
The pieces of the formally/semi-formally analyzed SW, Algorand, GHOST protocols that we are mashing together don't destructively interfere enough to cause major security holes.