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*由三个部分组成
- 生成区块(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的验证路径
Algorand 共识算法 BA* 入门相关推荐
- MIT教授提出可扩展的新共识算法Algorand,彻底消除区块链分叉的可能性
如果公有区块链要想获得成功--无论是被用作货币,智能合约还是其他某些东西--它就需要一种能够扩展的共识算法. 尽管开发者正在竞相开发一种这样的系统,不过最近一位杰出学者的设计可能会成为这场长期探索中取 ...
- 区块链入门系列之共识算法
区块链入门系列文章 区块链基本概念和名词解释 P2P 共识算法 梅克尔-帕特里夏树 从零开始搭建区块链 这里写自定义目录标题 区块链入门系列文章 前言 POW POS PBFT Raft 其他共识算法 ...
- 区块链快速入门(三)——CFT(非拜占庭容错)共识算法
一.CFT简介 CFT(Crash Fault Tolerance),即故障容错,是非拜占庭问题的容错技术. Paxos 问题是指分布式的系统中存在故障(crash fault),但不存在恶意(cor ...
- 区块链快速入门(四)——BFT(拜占庭容错)共识算法
一.BFT简介 1.拜占庭将军问题简介 拜占庭将军问题(Byzantine Generals Problem)是Leslie Lamport(2013年的图灵奖得主)用来为描述分布式系统一致性问题(D ...
- algorand共识协议_Algorand协议简介
Algorand是权益证明(POS)的一个升级,彻底消除区块链分叉的可能性,可以在一小段时间内确认交易,Algorand的核心使用称为BA⋆的拜占庭协议,同时扩展到许多用户.即使一些用户是恶意的,网络 ...
- algorand共识协议_基于Algorand结合VRF的共识机制介绍
相信大家对于PoS权益证明的概念都不陌生,但是究竟一个PoS的Protocol是如运作的?如何公平的选出下个区块的生产者?如何保证区块生产者不能bias下次自己再次当选的机率?这些实行的细节都是需要经 ...
- 区块链共识算法的发展现状与展望
来源:平行区块链 摘 要 共识算法是区块链技术的核心要素, 也是近年来分布式系统研究的热点. 本文系统性地梳理和讨论了区块链发展过程中的 32 种重要共识算法, 介绍了传统分布式一致性算法以及分布式共 ...
- algorand共识协议_【Filecoin】理解预期共识 - 及它的优缺点
摘 要 预期共识就是上帝掷飞镖 预期共识的优点在于简单,而且每一次选举胜出者数量的平均数为1 但预期共识不能保证每次选举的胜出者数量,这是其最大的问题 期待有更好的基于可验证随机函数的共识算法出现,设 ...
- 投票选举 算法_区块链主流共识算法一文全通
在每种伟大的加密货币背后,都有着一个伟大的共识算法.没有共识算法是完美的,但是它们各有千秋.在加密世界中,需要共识算法来防止重支付.这是迄今为止一些最流行的共识算法的简要介绍,从区块链到DAG以及介于 ...
最新文章
- 漫画 | 理解了TCP连接的实现以后,客户端的并发也爆发了!
- Apache用户认证配置文件
- iOS Newsstand Tutorial
- 最实用DOS命令参数的中文详解
- 30 MM配置-采购-采购申请-采购申请审批策略-编辑类
- JVM类加载机制详解
- c函数sscanf的高级技巧(二)
- android emmc生产日期,碎碎念android eMMC【转】
- [转载] 树莓派4B使用 Adafruit_PCA9685 报错IOError: [Errno 121] Remote I/O error解决办法
- oracle归档日志满正常么,oracle归档日志满了的处理方法
- GitHub 和GitLab的开发工具使用
- 前端实现Office在线预览 (一)
- 【3D动态脑图制作软件】万彩脑图大师教程 | 将思维导图输出到云服务
- 计算机都学什么数学,计算机专业的数学应学到什么水平?应该学习数学的那些分支?...
- Debian10更改源
- Oracle-ASM-PRCR-1079-监听启动报错
- 卡西欧计算机算坐标步骤,卡西欧计算器坐标的正反算.doc
- Java语言的特性和优点
- python爱情动画_人生苦短,我用Python-从Houdini里导出RBD解算的Skin动画
- WPF内部DeliverEvent读锁和PrivateAddListener写锁导致死锁
热门文章
- struts2 集成webservice 的方法
- Unity3d webplayer发布的问题和100%自适应浏览器
- Python学习笔记:面向对象编程(2)
- 【Python】append和extend的区别
- 学长毕业日记 :本科毕业论文写成博士论文的神操作20170328
- 台湾大学林轩田机器学习技法课程学习笔记2 -- Dual Support Vector Machine
- python状态机实现_如何实现Python状态机设计?
- Unet项目解析(4): ./src/RetinaNN_predict.py
- Qt修炼手册11_多线程编程和QThread类
- Asp.net常用优化方法