许晓笛：新共识机制BFT-DPoS，深入理解EOS账户权限映射

原创作者：许晓笛

首发公众号：圆方圆链圈

EOS最新的白皮书中已经将共识机制从DPoS升级为了BFT-DPoS（Byzantine Fault Tolerance - Deligated Proof of Stake，带有拜占庭容错的委托股权证明），本篇文章将详解新共识机制的原理。

传统 DPoS

EOS项目刚刚发布的时候的共识机制是DPoS(Deligated Proof of Stake，委托股权证明)，类似于Bitshares和Steem，这种共识机制采用随机的见证人出块顺序，出块速度为 3 秒，交易不可逆需要45秒。

为什么需要 45 秒呢？因为DPoS下，见证人生产一个新区块，才表示他对之前的整条区块链进行了确认，表明这个见证人认可目前的整条链。而一个交易要达到不可逆状态，需要 2/3 以上的见证人确认，在EOS里就是14个见证人。

我们假设一个交易被包含在1000号区块中，需要其他13个见证人轮流出块至1013号区块，这样才能“收集”到14个见证人对此交易的确认（包括生产1000区块的见证人）。2/3 以上的见证人确认的交易，就是不可逆的交易了，这就是45秒确认时间的由来。

拜占庭容错（BFT）

为了改进传统的DPoS算法，我们可以借鉴PBFT（Practical Byzantine Fault Tolerance，拜占庭容错算法）的机制。在传统DPoS共识机制中，我们让每个见证人在出块时向全网广播这个区块，但即使其他见证人收到了目前的新区块，也无法对新区块进行确认，需要等待轮到自己出块时，才能通过生产区块来确认之前的区块。

在新的机制下，每个见证人出块时依然全网广播，其他见证人收到新区块后，立即对此区块进行验证，并将验证签名完成的区块立即返回出块见证人，不需等待其他见证人自己出块时再确认。

从当前的出块见证人看来，他生产了一个区块，并全网广播，然后陆续收到了其他见证人对此区块的确认，在收到2/3见证人确认的瞬间，区块（包括其中的交易）就不可逆了。交易确认时间大大缩短，从45秒缩短至3秒左右（主要为等待生产区块的时间）。这种机制可以称为初级版的BFT-DPoS共识机制。

BFT-DPoS

为了挖掘EOS系统的性能，Daniel Larimer在以上基础上又进行了修改。首先，他将出块速度由3秒缩短至0.5秒，理论上这样可以极大提升系统性能，但带来了网络延迟问题：0.5秒的确认时间会导致下一个出块者还没有收到上一个出块者的区块，就该生产下一个区块了，那么下一个出块者会忽略上一个区块，导致区块链分叉（相同区块高度有两个区块）。

比如：中国见证人后面可能就是美国见证人，中美网络延迟有时高达300ms，很有可能到时美国见证人没有收到中国见证人的区块时，就该出块了，那么中国见证人的区块就会被略过。

为解决这个问题，Daniel Larimer将原先的随机出块顺序改为由见证人商议后确定的出块顺序，这样网络连接延迟较低的见证人之间就可以相邻出块。

比如：日本的见证人后面是中国的见证人，再后面是俄罗斯的见证人，再后面是英国的见证人，再后面是美国的见证人。这样可以大大降低见证人之间的网络延迟。使得0.5秒的出块速度有了理论上的可能。

为了保证万无一失，不让任何一个见证人因为网络延迟的意外而被跳过，Daniel Larimer让每个见证人连续生产 6个区块，也就是每个见证人还是负责3秒的区块生产，但是由最初的只生产1个变成生产6个。最恶劣的情况下，6个区块中，最后一个或两个有可能因为网络延迟或其他意外被下一个见证人略过，但6个区块中的前几个会有足够的时间传递给下一个见证人。

再来讨论BFT-DPoS的交易确认时间问题：每个区块生产后立即进行全网广播，区块生产者一边等待0.5秒生产下一个区块，同时会接收其他见证人对于上一个区块的确认结果。新区块的生产和旧区块确认的接收同时进行。大部分的情况下，交易会在1秒之内确认（不可逆）。这其中包括了0.5秒的区块生产，和要求其他见证人确认的时间。

EOS系统规定，一旦区块达到不可逆状态（2/3见证人确认），就无法在此之前进行分叉，保证了交易的永久可信。另外，即使多数见证人想分叉区块链，也只能以相同的速度（0.5秒）与主链竞争，就算主链只剩下一个见证人，分叉链也永远不会追上主链，保证了系统的稳定。

Daniel Larimer称 EOS新的BFT-DPoS共识机制还在开发中，会在系统上线前完成开发，让我们拭目以待。

深入理解EOS账户权限映射

在EOS里，不论是真人用户还是智能合约，本质上都是一个账户（Account）。或者说，真人账户也是一个智能合约，都可以对外声明别人可以对他做什么动作（比如社交合约里的发帖），EOS官方称之为 “Action”。

比如某个账户可以声明一个叫“SayHi”的Action，别的账户就可以使用Active权限（这里可以参考之前的文章）对他执行SayHi动作。账户还可以声明对Action的回应方式，比如别人对他SayHi后可以回送一个金币什么的。

所以EOS里 “智能合约” 的定义就是：账户声明的Action，以及对Action的回应脚本（程序）。任何智能合约都是由这两个要素组成的。

这种架构自然而然引发了一个问题：对于复杂的智能合约账户，有些Action功能比较简单，比如就是一个查询，安全性要求不高，便利性要求高。还有些Action非常敏感，比如提现，便利性要求不高，安全性要非常高。

用户账户使用自己的Active权限就可以执行所有智能合约的Action，显然是不合理的。EOS为了解决这个问题，采取了三步：

1.（用户）账户自定义分级权限。

2.（智能合约）账户Action分级。

3.用户权限与智能合约Action之间的映射（mapping）。

再次强调，这里只是为了表达方便，将账户分为“用户”与“智能合约”，其实这二者在EOS里没有区别。用户本身就是智能合约，智能合约也是其他智能合约的“用户”。

（用户）账户自定义分级权限

EOS里，账户默认会有两种权限：Owner和Active。Owner是最高权限，Active就是之前提到的操作智能合约权限。所有权限都是基于权重和阈值管理的。EOS在此基础上，增加了分级并分组的自定义权限，如下图所示。

途中箭头方向就是指向“母权限”或者更高级权限。图中不难看出，Owner权限是账户最高权限，可以执行Active权限。Active权限可以执行Family权限和 Lawyer权限。 Family权限可以执行Friends权限。反过来，低级权限不能代替执行更高级的权限。不同级别的权限用 “/” 或”.” 分隔，比如图中的Friends权限就可以表示为 “@User.Active.Family.Friends”。

（智能合约）账户Action分级

与权限分级类似，账户Action也可以分级并分组，如下图所示（图中的Message也就是Action）。

这个智能合约账户叫“@Exchange.Contract”，首先定义了Withdraw（提现）Action，接下来是一组Action名叫 “Trade（交易）组”，组里有三个Action：Buy（买入）、Sell（卖出）、Cancel（取消）。Action同样遵循“向下兼容”，也就是如果某用户账户的某权限拥有“Trade组”的映射，就可以执行“Trade组”的所有Action。不同级别的Action用 “/” 或”.” 分隔，比如图中的Buy Action就可以表示为 “@Exchange.Contract/Trade/Buy”。

权限与 Action 之间的映射

最后一步，我们要将前两步连接起来，也就决定什么权限能执行什么Action，如下如的左下部分。

首先看映射1，我们将@Exchange.Contract合约的所有Action映射到了Family权限，也就是使用@User用户的Family权限（或者更高权限）可以执行@Exchange.Contract合约的所有Action。

映射2表示将@Exchange.Contract合约的Withdraw（提现）Action映射到了Lawyer权限，所以Lawyer权限可以执行 Withdraw Action。但无法执行其他Action。

3表示Trade组并没有特殊映射，不过因为@Exchange.Contract合约的所有Action都映射到了Family权限，可以直接通过Family权限执行，或者使用更高级的Active甚至Owner权限。

如果@User账户想执行@Exchange.Contract/Trade/Buy这个 Action，系统会检查@User账户是否定义了@Exchange.Contract/Trade/Buy映射，没有的话会检查@Exchange.Contract/Trade映射，接着会检查@Exchange.Contract映射，发现@Exchange.Contract映射到了Family权限，就会检查本次执行是否满足了@User.Family权限（达到阈值），若Family权限不足会检查@User.Active，接着会检查@User.Owner。

如果没有发现任何符合的映射，会直接检查本次执行是否满足了@User.Active权限，若不足，会检查@User.Owner。