Hyperledger Consensus

共识过程

Hyperlydger中建立共识的过程由以下两个独立的过程构成:

  • Ordering of transactions (交易排序)
  • Validating Transactions(交易验证)

逻辑上将这个两个过程分离可以保证Hyperledger快讲可以应用任何的共识模块。

建立共识的第一步是从client端接收交易,然后由Ordering Service进行交易排序。Ordering Service 可以用多种方法实现,在开发测试阶段可以用中心化的排序服务,也可以面向不同的网络采用分布式协议。

为了实现交易的私密,排序层不应看到交易的具体内容(对交易内容不可见),交易的内容可以采用加密或者是哈希处理。

交易通过接口被传递到排序服务,然后排序服务根据共识算法和配置策略将交易排序。为了提高效率,排序服务会将多个交易打包成一个块再输出,排序服务中需要保证块内交易的顺序。

为了校验交易的正确性,共识的建立依赖于智能合约层,智能合约层定义了商业逻辑来确认如何验证交易有效。智能合约层根据特定的策略与约定来确认每一笔交易都是有效的。无效的交易会被拒绝,并在块中剔除。

潜在的校验失败主要分为以下两种:语法错误、逻辑错误。

语法错误包含以下几种类型,比如无效输入、未验证的签名、重复的交易等,这类交易应该被丢弃。

第二类错误比较复杂,需要有特定策略来觉得如何处理。比如,一笔交易经验证是多重支付。我们需要记录这类交易已验证是否是策略所需要的。

共识层通过通讯层来实现与client或者是其他节点的消息互通。

共识属性

共识必须遵循以下两个属性:安全性(Safety)和活跃性(Liveness)。

  • 安全性,是指要保证每个节点都有相同的输入序列,并在每个节点上产生相同的输出。当节点收到一组交易时,每个节点上的状态变化都应该是相同的。算法需要实现在一个节点上,交易以原子方式进行处理,即每次只能处理一个交易。
  • 活跃性,网络中的每个节点都必须接收到每一条提交的交易,除非节点出现错误。

Hyperledger Frameworks 中的共识

因为商业区块链的需求是多样的,因此需要不同的共识机制。Hyperledger工作于多种不同的共识机制上,并且是模块化的。

上面表格比较了Hyperledger中用到的共识算法。

Hyperledger Fabric 中的共识

Fabric中的共识达成过程分解为以下三个步骤:

  • Endorsement,网络参与式endorse一个交易
  • Ordering,接收经过endorse的交易,将其排序,并打包成block
  • Validation, 接收经过排序的block,验证其中交易结果的正确性,包括检查endorsement策略、二次支付等问题。

Fabric建立共识的三个阶段都支持可配置,用户可以实现自己的endorsement、ordering、validation过程。除此之外,Ordering Service还支持配置基于拜占庭容错的共识算法。Ordering Service API包括两个基本动作:广播、传输。

  • 广播:client端调用该接口实现任意消息的广播,当向一个service发送请求时,在BFT部分也被称为request。
  • deliver:Ordering Service调用该接口用来发送带有特定消息序列值和prehash值得消息。或者说,这是一个从排序服务中用到的输出事件。deliver()在广播-订阅系统中,有时也被称为notify(),在BFT系统中称之为commit()。

多个排序组件正处于开发之中,这包括BFT Smart、Simplified Byzantine Fault Tolerance(SBFT)、Honey Badger of BFT 等等。在Fabric v1中,Apache Kafka作为一个包外参考实现被提供。用户根据使用场景及容错模型来决定使用哪个组件。

Hyperledger Indy 中的共识

Hyperledger Indy 中的共识是基于Redundant Byzantine Fault Tolerance (RBFT)的,RBFT是由 Plenum Byzantine Fault Tolerance (Plenum)发展来的,可以把RBFT想象成是几个Plenum实例的并行实现。

由一个单一实体发向master的经过排序的请求消息被用来更新ledger,但是master的性能(吞吐量、延迟等)会周期性的与其他实体的平均值进行比较。如果发现master性能低下,则会发生视图更改,将不同的实例分配给master的角色。

与PBFT一样,RBFT至少需要\(3f+1\)个节点来处理\(f\)个错误节点。下图展示了一个4个节点的网络,该网络可以处理1个错误节点。其中每个节点都可以运行一个primary(leader)实例。

图4中展现了一个RBFT结构视图,在网络中client向节点发送请求。没有必要向所有的节点发送消息,因为发送\(f+1\)个就足够了。节点收到client的请求后,会将消息传播,从而使得其他节点都知道请求消息。每个primary节点在收到请求后,都会创建一个proposal(PRE-PREPARE),然后将其发送到其他所有节点。如果其他节点收到主节点的PRE-PREPARE,会返回一个PREPARE消息。一旦节点收到PRE-PREPARE消息以及\(2f\)个PREPARE消息,那么该节点就有足够的信息来接收proposal并发送commit消息。一旦一个节点收到\(2f+1\)个commit消息,那么这批请求可以被排序确认并加入到账本中。

Hyperledger Indy 使用RNFT来同处理ordering和validation,从而实现一个简单账本同时实现排序和验证。这一点与很多其他区块链网络有所不同,很多只是使用BFT协议来ordering。这些网络将验证留到请求被排序之后进行。

RBFT中用状态来描述账本,所有有效的、被接收的请求都可能改变账本状态。账本状态是保存在数据库中的变量及其值的组合。状态以Merkle Patricia树的结构被加密保存在数据库中(Merkle Patricia树在以太坊中实现)。Hyperledger Indy将Decentralized Identifers (DIDs) 作为状态来存储,其中状态包括验证秘钥及其他东西。内存中账本交易的复制及状态的改变是在proposal过程中更新的,主节点在发出proposal后就更新状态,而非主节点是在收到确认proposal时才更新状态。当proposal获得排序验证,账本的状态改变就会被确认。如果由于某种原因,proposal失败了,那么尤其发生的状态改变将会恢复。

Hyperledger Iroha 中的共识

Hyperledger Iroha中引入了称为Sumeragi的BFT算法,该方法可以容错\(f\)个错误节点,在下面论文中提出。

BChain: Byzantine Replication with High Throughput and Embedded Reconfiguration

在B-Chain中,我们在验证交易时考虑全局顺序的概念,并且把节点分为A、B两组,其中A包含\(2f+1\)个节点,B组包含剩余的节点。在正常情况下,确认一个交易只需要\(2f+1\)个节点签名就可以了,因此这是我们在交易确认中只使用\(2f+1\)个节点。只有当确认出现错误时,才会用到剩余的节点,第\(2f+1\)个节点称为代理尾部。正常情况下的交易验证过程如下图所示:

Client端首先会向主导节点提交交易,这个主导节点会验证交易并将其放到队列中,并且对交易签名。之后,该节点将交易光波导其他\(2f+1\)个验证节点。

处理节点的顺序是由称之为hijiri的服务器信誉系统来决定的,Hijiri基于以下三个因素来计算服务器的可靠性。

  • 每个server在成员管理系统中注册的时间
  • 成功处理交易的次数
  • 是否发生过错误

为了检测错误,每个server在签署并向代理尾部节点(第2f+1个节点)广播一个交易时会设置一个定时器。如果在定时器时间内没有收到回复或者是发生了错误,那么该server会继续下尾部节点的下一个节点广播该交易。这个过程如下图所示。

当一个验证节点收到和交易时,会做如下几步操作:

    1. 验证签名有效
    1. 验证交易内容有效
    1. 临时性将交易加入到账本,这包括更新全局状态的merkel root
    1. 签署更新的Merkel root 以及交易内容的hash
    1. 广播
    1. 当节点间同步时,Merkel树的有效部分会在root符合的情况下共享。

Hyperledger Sawtooth中的共识

Hyperledger Sawtooth 推动同时使用lottery-based和voting-based算法的共识机制。默认情况下,Sawtooth使用一个lottery-based算法,称为PoET。为了实现更为有效的分布式共识,一个好的lottery-based算法需要具备以下特点:

  • 公平性,各个节点应该基于公平的相同的概率参与投票
  • 投入,选举的结果应该从潜在的投入值来获得
  • 有效性,应该有一个建档的方式是所有的节点都可以验证结果有效性

当前的Hyperledger Sawtooth实现中,构建了一个TEE(Trusted Execution Environment )系统,这保证了选举过程的安全性及随机性,而不用电力耗费或者是特殊硬件来加速工作量证明算法。

Every PoET validator requests a random time to wait from a trusted function before claiming leadership. The validator with the shortest wait time for a particular transaction block is implicitly elected the leader. The function “CreateTimer” creates a timer for a transaction block that is guaranteed to have been created by the TEE. The “CheckTimer” function verifes that the timer was created by the TEE and, if it has expired, creates an attestation that can be used to verify that validator did, in fact, wait the allotted time before claiming the leadership role.

The PoET leader election algorithm meets the criteria for a good lottery algorithm. It randomly distributes leadership election across the entire population of validators with a distribution that is similar to what is provided by other lottery algorithms. The probability of election is proportional to the resources contributed, where resources are general purpose processors with a TEE. An attestation of execution provides information for verifying that the certifcate was created within the TEE and that the validator waited the allotted time. Further, the low cost of participation increases the likelihood that the population of validators will be large, increasing the robustness of the consensus algorithm.

Hyperledger中的共识机制的更多相关文章

  1. 老K漫谈区块链的共识(1)——免信任的共识机制

    老k,柏链道捷CTO.清华阿尔山区块链研究中心高级工程师,超过17年的系统软件开发经验,在操作系统.编译器.虚拟机和符号执行方面都有实战经验.主持开发多个开眼项目,目前主要从事区块链底层系统开发工作. ...

  2. hyperledger中文文档学习-2-简介

    参考https://hyperledgercn.github.io/hyperledgerDocs/blockchain_zh/ Hyperledger区块链框架(https://blog.csdn. ...

  3. (转)区块链共识机制分析——论PoW,PoS,DPos和DAG的优缺点

    近期,随着区块链技术在社区中的声音越来越大,业界已经开始从技术角度对区块链进行全方位的解读.作为第一批区块链技术的实现,传统比特币与以太坊在共识机制.存储机制.智能合约机制.跨链通讯机制等领域并没有非 ...

  4. 菜鸟系列Fabric——Fabric 1.4共识机制(5)

    fabric 共识机制 由于fabric是分布式的系统,因此需要共识机制来保障各个节点以相同的顺序状态保存账本,达成一致性. 在当前fabric1.4版本中,存在三种共识机制,分别是solo,kafk ...

  5. 菜鸟学习Fabric源码学习 — kafka共识机制

    Fabric 1.4源码分析 kafka共识机制 本文档主要介绍kafka共识机制流程.在查看文档之前可以先阅览raft共识流程以及orderer服务启动流程. 1. kafka 简介 Kafka是最 ...

  6. 区块链共识机制(POW、POS、DPOS等)的优缺点

    一.POW:工作量证明机制 基本原理: 第一代共识机制,比特币的基础.理解起来,很简单,就是“按劳取酬”,你付出多少工作量,就会获得多少报酬(比特币等加密货币).在网络世界里,这里的劳动就是你为网络提 ...

  7. 从分布式一致性到共识机制(二)Raft算法

    春秋五霸说开 春秋五霸,是指东周春秋时期相继称霸主的五个诸侯,“霸”,意为霸主,即是诸侯之领袖.典型的比如齐桓公,晋文公,春秋时期诸侯国的称霸,与今天要讨论的Raft算法很像. 一.更加直观的Raft ...

  8. 共识机制:AngelToken技术的根基

    共识机制是区块链技术的一个核心问题,它决定了区块链中区块的生成法则,保证了各节点的诚实性.账本的容错性和系统的稳健性. 常用的共识机制主要有 PoW.PoS.DPoS.Paxos.PBFT等. 基于区 ...

  9. 通俗讲解:PoW共识机制与以太坊的关系、Ghost协议 及 PoS共识机制的变种---Casper

    作者:林冠宏 / 指尖下的幽灵 掘金:https://juejin.im/user/587f0dfe128fe100570ce2d8 博客:http://www.cnblogs.com/linguan ...

随机推荐

  1. 获取并安装XWAF框架压缩包(2)

    建议在Eclipse环境下使用XWAF框架来开发用户的Web项目,并遵循以下步骤和约定. 1.获取XWAF框架压缩包文件 程序员点击下列地址免费下载XWAF框架的压缩包文件:XWAF框架压缩文件 2. ...

  2. docker搭建本地私仓

    环境centos7  docker-ce 18 启动仓库镜像 docker run -d -p 5000:5000 registry:2 docker images 通过docker tag 标识镜像 ...

  3. Spring boot Mybatis整合构建Rest服务(超细版)

     Springboot+ Mybatis+MySql整合构建Rest服务(涵盖增.删.改.查) 1.概要 1.1 为什么要使用Spring  boot? 1.1.1 简单方便.配置少.整合了大多数框架 ...

  4. DELPHI DOUBLE不解之迷

    procedure TForm1.cmd2Click(Sender: TObject);var str1, str2: string; LValue1: Double; LValue2: Extend ...

  5. Python学习笔记十:json序列化,软件结构目录规范,ATM作业讲解,import本质论

    json序列化 将系统的某个状态保存为字符串(挂起),序列化. import json json.dumps():序列化 json.loads():反序列化 简单类型数据处理 import pickl ...

  6. 20155226 2016-2017-2 《Java程序设计》第2周学习总结

    20155226 2016-2017-2 <Java程序设计>第2周学习总结 教材学习内容总结 了解了基本类型以及初识类类型,熟悉了注释,变量及运算符的使用. 了解了几种运算方式但还不算熟 ...

  7. 20145226 《Java程序设计》第3周学习总结

    教材学习内容总结 学习目标 区分基本类型与类类型 理解对象的生成与引用的关系 掌握String类和数组 理解封装的概念 掌握构造方法的定义 理解重载的概念 掌握static的应用 教材第四章内容总结 ...

  8. adb的配置

    http://jingyan.baidu.com/article/2fb0ba405e815f00f2ec5f9e.html 1. 用快捷键Ctrl + Alt + T 打开终端命令工具,电脑不要插入 ...

  9. echarts 去掉最外部边框

    在option中,插入一下代码即可: grid: {show:'true',borderWidth:'0'}, 插入代码前: 插入代码后:

  10. Mysql本地安装多实例后启动遇到的问题

    一.本文紧接上一篇[win10-MySql免安装版-安装/多实例] 在上一篇文章里,安装Mysql解压版后,复制多份到本地,实现了多实例的安装 在后续启动其它实例的时候会遇到一些问题,以下就是自己遇到 ...