共识
CAP理论
一致性consistency
服务可用性availability:请求在一定时间内得到响应,可终止、不会一直等待
分区容错性partition-tolerance:网络分区情况下,被分割的节点仍能对外服务
tendermint
协议中的参与者叫着 “验证人”(validator)。他们轮流对交易区块进行提议,并对这些区块进行投票。区块会被提交到链上,每一个块占据一个“高度”(height)。提交块可能会失败,如果失败,协议就会开始下一轮的提交,并且一个新的验证人会继续提交那个高度的区块。要想成功提交一个块,需要有两个阶段的投票:“预投票”(pre-vote)和“预提交”(pre-commit)。在同一轮提交中,只有超过 2/3 的验证人对同一个块进行了预提交,这个块才能被提交到链上。
上图右下角有一对夫妇在跳波卡舞,因为验证人做的事情就像是在跳波卡舞。当超过 2/3 的验证人对同一个块进行了预投票,我们就把它叫做一个“波卡”(polka)。每一个预提交都必须被同一轮中的一个波卡所证明。
由于一些原因,验证人可能在提交一个块时失败:当前提议者可能离线了,或者网络非常慢。Tendermint 允许他们证实一个验证人应该被跳过。在进行下一轮的投票前,验证人会等待一小段时间从提议者那里接收一个完整的提议块。这种对于超时的依赖,使得 Tendermint 成为了一个弱同步协议,而非一个异步协议。但是,协议的剩余部分都是异步的,只有在接收到超过 2/3 的验证人集合时,验证人才会采取下一步操作。Tendermint 能够简化的一个原因就是它使用了同样的机制来提交一个块和跳过直接进入下一轮。
基于不到 1/3 的验证人是拜占庭节点的前提,Tendermint 保证了永远都不会违背其安全性 – 也就是说,验证人永远不会在同一高度提交冲突块。为了达到这一点,它引入了一些 “锁定”(locking)的规则,这些规则对流程图中的路径进行了模块化。一旦一个验证人预提交了一个块,它就被“锁定”在了那个块上。然后,
- 它必须为被锁定的那个块进行预投票
- 只有在之后的轮中,有了那个块的一个波卡,它才能够解锁,并为一个新块进行预提交。
PAXOS
raft