Algorand 共识算法 BA* 入门

Algorand 由图灵奖获得者 Micali 提出的，其共识机制被称为 BA*，是 PBFT 算法的改进。BA* 算法分为三阶段：区块生成、GC 和 BBA*。算法的停止时间是不确定的，但大概率保证在有限步内结束。

协议里有两种角色：Leader 和 Verifier

• Leader：在区块生成阶段创建区块；
• Verifier：在之后的每一个阶段里，对区块进行共识。

下面对 BA* 协议的细节做一个具体介绍。

符号

• ：第 r 轮第 s步
• ：第 r 轮的 leader
• ：的 verifier 集合。如果 s=1，则为 potential leader 集合
• 和：的诚实 Verifier 和恶意 Verifier 集合
• ：第 r 轮里节点 i 生成的区块
• ：空区块。生成空区块的那一轮是不存在leader的。
• ：节点 i 在签名消息所用的临时密钥。每个都有对应的临时密钥。
• ： i 的签名，用于证明
• ：节点 i 在广播的消息。根据不同，消息格式也不一样
  • ：
  • ：
  • ：
• ：在第 r 轮时已加入系统的所有节点的公钥集合

基本概念

种子

是第 r 轮的种子，用于选举 Leader 和 Verifier。的计算方式如下：

• 如果是合法区块，则
• 如果，即空区块，则

Leader 选举

对于，计算如果满足，则 i 为 potential leader。

其中最小的节点为真正的 leader。

Verifier 选举

Verifier 选举的方式和 Leader 选举的方式一样：对于，计算如果满足，则 i 为 Verifier

区块结构

区块结构不是协议重点，但还是提一下。

• 如果是合法区块，则
• 如果，即空区块，则

BA*共识

BA*由三个部分组成

1. 生成区块（s=1，即第一步）：所有节点检查自己是不是potential leader，如果是，则生成区块并广播
2. GC协议（2≤s≤3）：有点像PBFT的后两个阶段，verifier 会生成1个二进制值
3. BBA（s≥4）：BBA共识的修改版。每次 BBA都由3步组成，会不断地循环。什么时候结束是不确定的，依概率结束。

BA*将 leader 所生成的区块映射成二进制值，分别表示区块合法与否。

• 合法：共识结束后生成一个正常区块
• 不合法：共识结束后生成空区块（）

约定

假设

1. 每一步中，都有，即诚实Verifier比例大于Verifier集合的2/3。（P31.Parameters第1点）
2. 对于发的消息，最多经过时间能被诚实节点收到。（P45第6行）

执行前提

：节点 i 根据「Leader选举规则」检查自己是不是 potential leader。如果不是，结束该 step，否则执行相应规则。

：节点 i 根据「Verifier选举规则」检查自己是不是 vefier。如果不是，结束该 step，否则执行相应规则。

下文协议细节描述里，默认有这些检查。

签名

和都表示用当前的临时密钥来签名消息。

Step 的开始和结束

开始时间：一个节点在达成共识后，会同时进入每个Step（论文 P44.Lemma 5.5(a)）。但并不是所有节点同时开始。

• 设第一个诚实节点达成共识的时间是，则在时间内，所有的诚实节点都会达成共识。
• 为什么是，见分析的 2.1.a 和 2.1.b（论文 p50-52）

结束时间：Step 结束的条件有两种

• 达成 Ending Condition 条件
• 耗尽等待时间：第s步的等待时间为，表示的广播时间上限，表示的广播时间上限。【但为什么是?】
  • 时没有等待时间，因为不需要接收消息。
  • 论文中默认等待后，能收到所有诚实节点在小于的step里发送的消息。

Step 1 生成区块

这一步生成区块并广播

1. 生成区块
2. 生成。其中表示用进行签名的，签名完后销毁。
3. 广播和

备注

• 其他节点通过验证是否有，以检查 i 是否有资格进行该步。
• 敌手收到所有的后，就能知道谁是leader，并立即控制它广播新的，阻止它原来的广播出去。这样敌手就可以控制每一轮的 leader。广播后销毁就是为了避免这种情况发生，因为即使敌手控制了leader，也无法让他发送新的。

GC

Step 2：GC第一步

1. 从收到的多个里找到，即最小的节点。
2. 检查发来的区块的合法性：若合法，令；若不合法，令。
3. 广播

备注

• 是协议要共识的值，在协议中不会用到。
• 整个协议里只有这一步检查 Leader 和区块的合法性

Step 3：GC第二步

1. 在收到的中，如果有超过 2/3 的（他们的全部相同），则令；否则，则令
2. 广播

Step 4：GC输出

1. 收到的中，有 3 种可能出现的情况
   1. 如果有超过的，则令
   2. 如果有超过的，且，则令。这里可以保证只有唯一的超过1/3的值。
   3. 否则令
2. 广播

备注：表示区块合法，表示区块不合法

【思考】：在诚实节点中，似乎不会出现部分，部分的场景，而是会全部共识到合法区块或空区块。恶意的和Verifier不能对下一步的诚实节点进行单播，因为他们不知道下一步的诚实节点是谁。

BBA*

在BBA*中，会不断对收到的历史进行检查，查看是否触发Ending Condition

以下两个结束条件是互斥的

【Ending Condition 0】

• 条件：收到超过的，且有；同时在中对应的区块是合法的（注意是区块的哈希）
• 满足条件则达成共识，将相应的集合作为，停止该轮。

【Ending Condition 1】

• 条件：收到超过的，且有
• 满足条件则达成共识， 将相应的集合作为，停止该轮。

Step 5：Coin-Fixed-To-0

当时进行这一步时，如果触发Ending Condition 0 或 1，则停止。否则等待后

• 在收到的中，有超过2/3比例的，则令，否则另
• 广播
• 【为什么要令和0】

Step 6：Coin-Fixed-To-1

和 Coin-Fixed-To-0 类似，当时进行这一步时，如果触发 Ending Condition 0 或 1，则停止。否则等待后

• 在收到的中，有超过2/3的，则令，否则令
• 广播

Step 7：Coin-Genuinely-Flipped

当时进行这一步，如果触发 Ending Condition 0 或 1，则停止。否则等待后

• 可能出现三种互斥的情况：
  • 在收到的中，有超过2/3的，则令
  • 在收到的中，有超过2/3的，则令
  • 否则令
• 广播

Step m+3：最后一步

这一步比较特殊，不用检查自己是不是Verifier，所有节点都要参与。

如果触发Ending Condition 0 或 1，则停止。否则等待后

• 令和
• 广播

达成共识，收集集合作为。

总结

【达成共识的情况】：有三种，分别是 Ending Condition 0、Ending Condition 1 和 Step m+3。

【Ending Condition】

1. 若因为收到超过 2n/3 的而触发 Ending Condition，则在的 step 里，肯定是因为耗尽等待时间而结束step。
2. 触发 Ending Condition 0，则一定是 Coin-Fixed-To-0；如果触发 Ending Condition 1，则一定是 Coin-Fixed-To-1。
3. Ending Condition 要求收到的个数要超过确定值，而其他的都只要求收到的中有2/3满足条件即可。

拜占庭共识要保证参与共识的诚实节点大于2/3，但随机选出的集合不能保证该条件。于是

1. 进行多次的随机选取（循环），只要有一次参与共识的诚实节点大于 2/3，就能达成共识。
2. 如果不进行多次随机选取（循环），则恶意节点每次把合法区块变成空区块的概率就会大大增加。

临时密钥

在每一个里，节点 i 所用的使用临时密钥签名消息。一旦消息广播出去，立即销毁签名所用的私钥。

这么做的理由：节点 i 发送消息的瞬间，敌手可以立即知道，就可以collud它，用它的重新签名消息并广播。比如敌手可以这么攻击

• 时：则每一轮敌手都可以控制 leader
• 时，敌手可以有策略地控制verifier，使得每一轮都共识成空区块

节点 i 每次会生成100万轮*180步的临时密钥（在加入系统或临时密钥用完时生成）。下面简单介绍两种生成方案（论文 p32）

第一种方案

1. i 生成 PMK 和 SMK
2. 广播 PMK
3. 通过 SMK 和计算出100万轮*180步的。计算完后销毁 SMK
4. 任何人可以通过 PMK 和计算出（这一步论文里没有写，是我猜的）

第二种方案

• i 生成100万轮*180步的公私钥对
• 利用全部的私钥生成 Merkle Tree，广播 Root。
• i 广播时，附带公钥和 Merkle Tree的验证路径

https://zhuanlan.zhihu.com/p/32282367