Casper共识协议到底是如何工作的

一、出块和投注

  协议中的节点，作为“锁定保证金的验证人(bonded validators)”，必须先缴纳保证金，才可以参与出块和投注。出块是一个独立于其它所有事件而发生的过程：验证人收集交易，当轮到他们的出块时间时，他们就制造一个区块，签名，然后发送到网络上。投注的过程更为复杂一些，目前Casper默认的验证人策略被设计为模仿传统的拜占庭容错共识：观察其他的验证人如何投注，取33%处的值，向0或者1进一步移动。简单来说就是验证人将保证金中的大部分对共识结果（即哪个区块块会被最终确定）进行下注，如果赌对了，他就可以获得收益，否则只能拿回部分保证金。此外如果验证人快速的改变下注，他将被严惩。

二、一次投注的具体信息

  所有的逻辑都通过一个Casper合约来实现，它提供投注，加入，取款和获取共识信息等一系列功能，因此通过简单的调用Casper合约我们就能提交投注或者进行其他操作。这个合约会记录当前的验证人集合，对于每位验证人记录6项主要数据：

• 验证人保证金的返还地址
• 当前验证人保证金的数量（注意验证人的投注会使这个值增加或减少）
• 验证人的验证代码(validation code)
• 最近一次投注的序号
• 最近一次投注的hash
• 验证人的意见表

一次投注可以看成如下的一个对象：

投注的信息

这里的关键信息是：

• 投注的序号
• 上次投注的hash
• 签名
• 意见更新组成的列表

三、投注过程

  验证人对每一个区块高度上的每一个候选块（由缴纳了保证金的验证人提交的块）独立下注，给每个块指定一个胜出概率并公布。通过多位验证人的下注，对于每个高度最终会选出唯一一个胜出块，这个过程也决定了交易(transaction)执行的顺序。如果一个验证人在某个高度公布的概率分布总和大于100%，或者公布了小于0%的概率，或者对一个无效块指定了大于0%的概率，Casper将罚没他的保证金。

四、交易最终确认(Transaction Finality)

  当缴纳保证金的验证人中的绝大多数（保证金比例达到67%到90%的一群验证人）以非常高的概率（例如> 99.9%）下注某个块时，我们说这个块已最终确认(final)，因为任何不包含这个块的分叉都不可能胜出。此外，如果客户端发现所有小于高度H的块都已最终确认，这个状态(H - 1高度的状态)已最终确认。因为此客户端永远不能接受一个在高度H - 1的状态和顺序执行这些完全块得到的状态不一样的分叉。
　　因此这里有相关的两种交易的最终确认：交易在特定高度被执行的最终确认（也就是对应块的最终确认，早于所有此高度之后的交易执行），以及交易执行后状态的最终确认（需要对应块和所有低于此高度的块被最终确认）。

参考文章
以太坊的POS共识机制（一）友善的小精灵 Casper
以太坊的POS共识机制（二）理解 Serenity ：Casper