本文不会对 Narwhal and Tusk 做过多细节描述,更多的是依据论文以及源码,对 Narwhal and Tusk 的设计思路和底层逻辑进行思考,换句话说,我想知道 Narwhal and Tusk 的设计思路,而不仅仅是对这两个协议的原理介绍。
本文专注于Optimisim的架构学习和思考,是第一篇,希望从OP入手,逐渐拓展对Rollup、二层网络等方案的理解。在前面写过一些列文章涉及了常见的共识协议,如HotStuff,Tendermint等传统BFT共识以及更为综合和现代的以太坊Gasper,在学习了它们后,我对
本篇文章是阅读了《区块链架构与实现——Cosmos详解》之后,对Tendermint理解更新。包括部分协议设计的底层逻辑,从工程实现的角度(而不仅仅是原理上)对具体模块进行阐述,比如Proposer轮换以及Slashing策略。本系列共有三篇文章,此为第三篇。从HotStuff
本篇专注于从 Tendermint 代码实现来还原其原理。
本文是介绍以太坊PoS共识的第三部分。以太坊的PoS-Part1共识协议总览以太坊的PoS-Part2LMDGHOST最终确定性Finality最终确定性(Finality)是指区块保证不会被回滚,会永远成为链的一部分。上篇文章介绍了作为以太坊ForkCho
本文是介绍以太坊PoS共识的第二部分。共识协议是个组合学习以太坊PoS时,可以发现所谓的共识协议不是一个单一的协议,而是以下三个部分的组合。ProposeRule:区块发布规则,负责打包区块并发布到链上,比如以太坊的ProposeRule是ProofofStake,
在Shardora共识协议开发之前我产生过两个疑惑?一个是BFT共识居然要求少于1/3的恶意节点,这听起来是个很强的信任假设,这真的可行吗?另一个是HotStuff共识这么好用,为什么主流的这几条公链不用,只是因为历史原因吗?在了解了以太坊PoS设计过程之后,我基本有了答案。
我们在 Shardora 实现了 HotStuff 作为共识层之后,学习并参考了 Tendermint,特别是参考其对接 PoS 的部分,以进一步完善 Shardora 共识的效率和安全性。
原生HotStuff的局限相比其他BFT类共识算法,HotStuff(下文简称HS)通过增加一个投票阶段的方式实现了正常和异常情况下O(n)的通讯复杂度,并且没有牺牲响应性(Responsiveness)。具体请参考文章HotStuff工程设计与实现。然而,HS有以下两个局限
文章从原生 HotStuff 出发,重点讨论 Chained HotStuff 的方案设计和工程实现。