本文不会对 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 的方案设计和工程实现。