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*由三个部分组成
- 生成区块(s=1,即第一步):所有节点检查自己是不是potential leader,如果是,则生成区块并广播
- GC协议(2≤s≤3):有点像PBFT的后两个阶段,verifier 会生成1个二进制值
- BBA(s≥4):BBA共识的修改版。每次 BBA都由3步组成,会不断地循环。什么时候结束是不确定的,依概率结束。
BA*将 leader 所生成的区块映射成二进制值,分别表示区块合法与否。
- 合法:共识结束后生成一个正常区块
- 不合法:共识结束后生成空区块()
约定
假设
- 每一步中,都有,即诚实Verifier比例大于Verifier集合的2/3。(P31.Parameters第1点)
- 对于发的消息,最多经过时间能被诚实节点收到。(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 生成区块
这一步生成区块并广播
- 生成区块
- 生成。其中表示用进行签名的,签名完后销毁。
- 广播和
备注
- 其他节点通过验证是否有,以检查 i 是否有资格进行该步。
- 敌手收到所有的后,就能知道谁是leader,并立即控制它广播新的,阻止它原来的广播出去。这样敌手就可以控制每一轮的 leader。广播后销毁就是为了避免这种情况发生,因为即使敌手控制了leader,也无法让他发送新的。
GC
Step 2:GC第一步
- 从收到的多个里找到,即最小的节点。
- 检查发来的区块的合法性:若合法,令;若不合法,令。
- 广播
备注
- 是协议要共识的值,在协议中不会用到。
- 整个协议里只有这一步检查 Leader 和区块的合法性
Step 3:GC第二步
- 在收到的中,如果有超过 2/3 的(他们的全部相同),则令;否则,则令
- 广播
Step 4:GC输出
- 收到的中,有 3 种可能出现的情况
- 如果有超过的,则令
- 如果有超过的,且,则令。这里可以保证只有唯一的超过1/3的值。
- 否则令
- 广播
备注:表示区块合法,表示区块不合法
【思考】:在诚实节点中,似乎不会出现部分,部分的场景,而是会全部共识到合法区块或空区块。恶意的和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】
- 若因为收到超过 2n/3 的而触发 Ending Condition,则在的 step 里,肯定是因为耗尽等待时间而结束step。
- 触发 Ending Condition 0,则一定是 Coin-Fixed-To-0;如果触发 Ending Condition 1,则一定是 Coin-Fixed-To-1。
- Ending Condition 要求收到的个数要超过确定值,而其他的都只要求收到的中有2/3满足条件即可。
拜占庭共识要保证参与共识的诚实节点大于2/3,但随机选出的集合不能保证该条件。于是
- 进行多次的随机选取(循环),只要有一次参与共识的诚实节点大于 2/3,就能达成共识。
- 如果不进行多次随机选取(循环),则恶意节点每次把合法区块变成空区块的概率就会大大增加。
临时密钥
在每一个里,节点 i 所用的使用临时密钥签名消息。一旦消息广播出去,立即销毁签名所用的私钥。
这么做的理由:节点 i 发送消息的瞬间,敌手可以立即知道,就可以collud它,用它的重新签名消息并广播。比如敌手可以这么攻击
- 时:则每一轮敌手都可以控制 leader
- 时,敌手可以有策略地控制verifier,使得每一轮都共识成空区块
节点 i 每次会生成100万轮*180步的临时密钥(在加入系统或临时密钥用完时生成)。下面简单介绍两种生成方案(论文 p32)
第一种方案
- i 生成 PMK 和 SMK
- 广播 PMK
- 通过 SMK 和计算出100万轮*180步的。计算完后销毁 SMK
- 任何人可以通过 PMK 和计算出(这一步论文里没有写,是我猜的)
第二种方案
- i 生成100万轮*180步的公私钥对
- 利用全部的私钥生成 Merkle Tree,广播 Root。
- i 广播时,附带公钥和 Merkle Tree的验证路径