Ultrain 公众号将分三篇文章来阐述 Ultrain 的共识协议理论设计,后续还会推出一系列文章来详细说明 Ultrain 共识协议的工程实现。本文为 Ultrain 共识协议理论设计的第二篇(第 4 章),接上文 技术干货 | Ultrain 共识黄皮书解析(1)

04

架构

Ultrain 每一轮,分为如下几步完成

  1. 基于可验证延时函数的随机数层每个共识周期提供一个系统随机数。

  2. 节点利用随机数结合硬件指纹和代币,在每一轮共识开始,选出一定数目的 Proposer 和 Voter。

  3. 由 Proposer 提议需要成块的消息,由 Voter 对选中的唯一提议消息相互发送确认。

  4. 节点对交易批进行执行,再利用上一个块随机数选出一定数量 Voter,通过 BA (binary agreement)协议相互同步对交易批的执行后状态。

  5. 节点对交易批和执行后状态独立打包成块。

4.1 随机数层 随机数层,为上层提供随机数源,比如共识委员会的选择,dapp 的随机源。基于 VDF 的随机数生成层,对于任何人都可以参与,同时任何人都可以验证随机数的正确性。但是考虑到 VDF 本身的复杂特性,特别是要防范专门的硬件设计厂商,所以需要对随机数的生成过程进行设计。 详细原理如下:

  • MAIN 委员会的成员 i 基于上个共识周期的随机数 randi 进行 VDF 的计算,计算时间跟共识的周期相关,只要共识在持续进行,那么 VDF 就要持续计算。

  • VDF 的计算结果将包含在共识最终形成的块中,所有人都可以对 VDF 的计算结果和其中包含的随机数进行验证。

  • 每个委员会成员,都应该运行 VDF 的计算函数。Listener 节点不需要运行 VDF 函数,但是需要验证 VDF 的计算结果。

本设计的主要目的,在于防止随机数生成过程中,有人拒绝提交,或者可以预测未来的随机数,进而对 proposer 和 validator 节点进行预测,进行攻击。同时基于 VDF 的随机数,也非常方便地可以应用在 Dapp 中,达到公平的目的。 4.2 身份层 每个自愿参与共识的节点都有一对密钥 (sk,pk) 作为身份标识。设备被选为共识成员的概率依赖以下三个评分的综合结果。

  • 链上代币。所有公钥对应的资产在链上都可以查询到,所以持有代币的百分比作为 wcoin。有的节点可能持有大量代币,但是不愿参与共识,可以代理给其他可靠的硬件厂商对应账户,类似 Dpos。或者持有大量代币的节点可能同时分散在多个账户,这不会影响到公平性,因为多个账户的综合被选中概率与一个账户相同(假设其他两个账户对应的硬件设备指标相同)。

  • 硬件特性。根据自愿参与共识的设备硬件指纹信息可以得出硬件特性评分。该评分可能有多个维度,比如 CPU/ 网卡 / 硬盘特性,分别适合 committee 中不同的身份。该权重暂定为 whardware。

  • 声誉。根据节点账户对代币的持有寿命(块高度)、设备历史参与记录、成功提交区块的次数,系统自动计算出节点信誉。该权重为 wreputation。

每个公钥对应一个权重 w = r1 ∗ wcoin + r2 ∗ whardware + r3 ∗ wreputation,其中 r1, r2, r3 为系统常量,用来设置各个权重的比率。 4.3 共识层 共识的详细过程如下:技术干货 | Ultrain 共识黄皮书解析(2)Figure 1: 共识时序图

  • propose 轮。节点基于上一个 block,独立判断是否被选为 Proposer 或 Voter。该轮保证消息确定性地由 Proposer 到全网大部分节点。

– Proposer 在广播 PROPOSE 消息的同时为了加速传播,广播带交易 hash 的 ECHO。为了最小化带宽消耗,PROPOSE 消息被冗余编码后,分别传给多个节点。每个 Proposer 只能广播一次,多次广播被视为恶意节点。在广播的 propose 消息中,应该包含 VDF 的计算结果。
– Voter 等待 TP ROP 时间后,对收到 PROPOSE 消息校验格式,选择 proof 最小的广播相应 ECHO 消息。同时 Voter 需要对 proposer 发送 VDF 结果进行验证。
– 节点收到 TH1 个消息后,即使在未收到 PROPOSE 消息的情况下,也广播 ECHO 消息。
– 节点收到 T H2 个 ECHO 后完成此轮,返回。
– 节点等待 T IMEOUT 未收集足够数量 ECHO 后,判断超时,将交易批设置为空。

  • 执行,所有节点对上一轮的结果执行,并基于原状态 state1 计算输出状态的摘要 state2。

  • BA 轮,全网基于上一个 block 和轮数,独立判断是否被选为 Voter。该轮保证大部分节点对执行结果的摘要接受与否达成一致。

– Voter 广播包含 state2 的 ECHO 消息。消息中同时包含 VDF 的计算结果和证明。

– 节点收到 T H2 个 ECHO 后,验证 VDF 的计算结果和证明,完成此轮。超时则成空提议,返回。

– 若上轮超时,则新开始一轮,重新判断是否为 voter,基于 CommonCoin 决定是否提起包含 state2 还是空交易批的 ECHO 消息,然后广播。

– 节点收到 TH2 个 ECHO 后完成此轮。否则继续利用 CommonCoin 判断下一轮的 ECHO 消息内容。

– BA 中每一轮时间固定为 TBar,节点判断超时后返回空。若超出特定 BA 轮数,则节点将状态回滚到 state1,该轮包含空交易批。

  • 成块

– 各个节点利用执行结果状态独立成块。同时,将 VDF 的计算结果和证明包含在块中。整个共识过程中,Listener 会接收到跟 Voter 和 Proposer 同样的消息,所以除了传递消息外,Listener 同样会校验、处理消息、成块。 具体算法描述如下:
技术干货 | Ultrain 共识黄皮书解析(2)
节点每轮对消息的响应如下:
技术干货 | Ultrain 共识黄皮书解析(2)技术干货 | Ultrain 共识黄皮书解析(2)技术干货 | Ultrain 共识黄皮书解析(2)4.4 新节点加入 新节点需要经过如下几个步骤:

  • 观察并接收网络正在传播的消息,确定块高度和共识的轮数,当前块共识结果。为了防止被恶意节点通过网络控制的方式攻击,新节点需要尽量从多个网络地址监听共识消息。

  • 根据当前成块,向网络中其他节点拉取历史区块,并验证链的正确性。考虑到链的单向性,新节点可以保证历史区块的正确性。

  • 新节点要同时对 VDF 的结果进行验证,假如有多条链同时存在,那么要选 VDF 累计比较多的链。

让信任计算赋能各行各业

技术干货 | Ultrain 共识黄皮书解析(2)

Ultrain 团队核心管理人员

技术干货 | Ultrain 共识黄皮书解析(2)

扫二维码下载 UltrainOne APP:

技术干货 | Ultrain 共识黄皮书解析(2)


以下为 Ultrain 各社交媒体账号

欢迎大家加入:

技术干货 | Ultrain 共识黄皮书解析(2)

微信用户可关注公众平台:ultrainchain

并可添加管理员微信(Ultrain_Fan-Club)

或扫码申请加入超脑链 Ultrain 中文社区

技术干货 | Ultrain 共识黄皮书解析(2)

技术干货 | Ultrain 共识黄皮书解析(2)

微博用户可关注:@Ultrain 超脑信任计算

技术干货 | Ultrain 共识黄皮书解析(2)

Facebook 用户可访问主页:Ultraincommunity

Link:http://fb.me/Ultraincommunity

技术干货 | Ultrain 共识黄皮书解析(2)

Twitter 用户可关注:@UltrainB

Link:https://twitter.com/UltrainB

技术干货 | Ultrain 共识黄皮书解析(2)

Telegram 用户可加入电报群:

Link:https://t.me/UltrainOfficial

技术干货 | Ultrain 共识黄皮书解析(2)

-END-

来源链接:mp.weixin.qq.com