基于委托与担保行为共识算法的区块链系统设计与实现

摘    要

 

目前人们在享受互联网数字化产品时面临着巨大的信任成本，区块链技术天然的去中心化、数据不能篡改、可追溯等特性是解决互联网信任问题、提高生产效率的高效解决方案。但目前区块链技术采用的共识算法还存在弱去中心化、低吞吐量、浪费资源等问题，在物联网、人工智能大力发展的今天、企业、政府都迫切的需要发展区块链技术，以实现可以构建丰富的上层应用，广泛认可的区块链技术。

  通过研究POW、DPOS等共识算法发现他们都存在资源导向的安全短板，当资源中心化时，意味着单个节点在社群众拥有高权重，区块链数据不可篡改的特性将失效。委托担保证明共识算法（Certificate of entrusted guarantee）简称EG，受启发于道家法天象地的思想，观察社会中委托和担保的行为构建责任链机制来保障数据不可被篡改，委托人发起支付账单，担保人担保这份账单是合法有效的，顶端节点诚实记录委托人的提交的支付链为收款方提供依据，最终数据聚合为支付方账单是否合法“板上钉钉”，若不合法发起集体仲裁，制约和追责作弊者。通过这种责任链机制，在社群中形成多向监督，监察区块链网络中的作弊行为，通过追责机制保障用户资源，惩治作弊者，使攻击行为承担巨大风险，让安全能力不依赖于个体资源的占比，拒绝资源中心化。EG共识算法以角色作为系统的单元，实现单个节点可以集群部署，横向提高个体节点的负载能力。数据上所有节点产生的账单都是有效数据，构成责任链实现价值驱动。以担保能力或实名制系统考察征信能力，灵活进行风险评估选择低风险“无限高”（只考虑共识的维度，不考虑硬件限制及底层系统依赖的限制）的TPS的支付模式和等待聚合确认的零风险的支付模式。本文将围绕着上述功能点结合流程图详细描述算法流程，以此为理论基础实现基于责任链机制的区块链引擎，最后通过功能测试，性能测试验证是否符合理论上的设计要求。

以EG共识算法为理论研发的区块链系统经测试在吞吐能力上可实现横向扩展，以价值来驱动不生产废数据，不浪费资源，作为底层数据库可以为N类行业提供链上解决方案，构建丰富的区块链应用，提高多产业的效率。

 

关键词：共识算法，区块链，委托与担保责任链，EG共识算法

目    录

 

 

 

 

目    录 4

第1章 引言 1

第2章 EG共识算法 2

2.1共识单元 2

2.1.1 委托人 2

2.1.2 担保人 2

2.1.3 顶端节点 2

2.1.4 聚合节点 3

2.2 EG算法流程 3

2.2.1 支付链 5

2.2.2 责任链 6

2.3 仲裁机制实现可靠区块链 6

2.3.1 支付方担保人的“叛变” 7

2.3.2 顶端节点的“叛变” 7

第3章 区块链系统设计与实现 7

3.1 移动端需求分析 7

3.1.1 实现模块 8

3.2 服务端需求有分析 8

3.2.1 实现模块 8

3.2.2 需要实现的接口 8

3.2.3 保障分析 9

3.2.4 接口规范分析 9

3.3 架构设计 10

3.3.1 社群架构 10

3.3.2 系统架构 11

3.3.3 数据模型 13

3.3.4 采用技术 13

3.4 算法设计 14

3.4.1 非对称式加密算法 14

3.4.2 顶点选择算法 14

3.4.3 聚合节点选择算法 15

3.5 模块设计 15

3.5.1 签名模块 15

3.5.2 担保服务模块 16

3.5.3 委托业务模块 16

3.5.4 监察模块 17

3.5.5 仲裁模块 17

3.6 移动端开发实现 17

3.6.1 签名模块实现 17

3.6.1 服务端功能调用模块 18

3.7 服务端实现 18

3.7.1 签名及委托业务模块实现 18

3.7.2 担保模块实现 19

3.7.3 监察模块实现 19

3.7.4 仲裁模块实现 19

3.8 性能评估 19

3.8.1性能评估概念 19

3.8.2 性能测试目的 20

3.8.3 测试环境 20

3.8.4 JMETER测试指标 20

3.8.5 测试工具和测试策略 20

3.8.6 策略1测试结果如下： 20

3.8.7 策略2测试结果如下： 21

3.8.8 结论 21

第4章 总结与展望 24

参考文献 25

 

 

第1章 引言

“共识”是一个充满哲学意义的词语，从原始时代的以物换物，到货币时代发行钱币，甚至是政权的统治无一不因共识而运作，达成共识人们才会参与这个体系。共识的健壮性，先进性决定了这个系统的运作的效率。区块链的共识是指网络系统中各个节点通过软件算法达成共识，使得区块链系统具有可追溯，不可篡改，去中心化等特性。基于委托与担保协议的共识算法受启发于道家思想“法天象地”，通过观察人类社会中的委托（Entrust）和担保（Guarantee）行为将其应用于软件设计当中，实现了高效率、安全的区块链应用。由于设计的架构类似于社会体系，所以可以区别于私链成为首个可以受监管的公链。

假设随着技术发展人类开发出了一个像月亮一样大的“光盘”，这个光盘人人可以看得见、数据开放存储、拥有足够多的存储单元、并且每个存储单元只可写一次和重复读取，人们将公开的账本记录在上面，每一个人都可以参与记账，由此实现了一个人人参与、数据可以追溯、不可篡改的完全可靠区块链系统。由于此区块链系统每一个人都有记账的权利并且数据存入进去无法更改，它符合记账去中心化，账本数据可追溯，不可以篡改的特性。并且无法通过作弊去打破这些规则，便可以称之为完全可靠的区块链系统。

当前只有通过共识机制才能达成社群系统中记账去中心化，数据可追溯，不可被篡改的特性。 然而当下大部分区块链系统都不是完全可靠的，如基于POW、DPOW、DPOS、权威证明、权重证明等共识算法研发的区块链系统都是基于限定条件下达成的数据一致性，当攻击者在持有一定量的资源后可以发起”双重支付攻击“，损害收款人的利益便破坏了这种一致性。在实名制系统中这种行为叫做 “超支”，可以离开物理系统去追究支付者的责任，在非实名制系统中收款人的损失是无法被追回的。这些限定条件有如单个节点的算力不能大于全网百分之51（实际情况是持有比特币网络百分之20的算力便可以成功发起双重支付攻击），百分之50节点是忠诚可靠的等等。实际情况可能更悲观，因发挥共识作用的在线节点数通常是小于总节点数的，且节点资源持有方”财富差异巨大“。综上客观条件得出结论，发动共识攻击者的成本远远小于理论值。这是制约区块链技术发展的主要原因之一。

维持共识的机制的驱动力有通过耗费算力的pow共识算法（俗称”挖矿“），比如比特币，虽然pow是共识算法的先河，但浪费资源且TPS太低无法扩展丰富的上层应用。因为以上2点特性不达标，所以不提倡。还有通过权益证明的算法其安全性依赖于多数节点的诚实，在各方资源占有不均，差距大的当今，其安全性显然难当"重任"。EG共识算法基于担保仲裁机制可以完全规避这种攻击。本文描述了委托担保证明共识算法是如何通过做有价值的工作实现价值驱动、高TPS、安全性不依赖于节点的诚实、不依赖于算力、可实现完全可靠区块链系统的共识算法。

第2章 EG共识算法

本章节描述EG共识算法通过责任链执行监察机制，仲裁机制,实现区块链的去中心化，数据不可篡改的特征。

2.1共识单元

EG共识单元分为4类， 委托人、担保人、顶端节点、聚合节点。每一个共识单元负责不同的算法，实现各个节点互相监督，保障整体的数据是诚实可信不可以被篡改的。

2.1.1 委托人

委托人是数据的生产方，委托人签名的数据需要经过担保人担保才能被EG区块链系统承认，所以委托人必须有一个固定的担保人配合才能正常的展业，本文以“开户方”来描述委托人的担保人。委托人不可以随意转移开户方，转移申请发出后需要冻结一定的时期来生效，这个时期的设置是灵活的，在实名制的区块链体系或顶端节点具有极高的公信力时，比如政府职能单位，可以缩短这个冻结时间，甚至是取消冻结时间。关于冻结时间的考量基于系统安全的设定，是否解除冻结取决于聚合节点的是否执行完毕。

 

2.1.2 担保人

担保人故名思意是担保委托人生产的数据真实有效、没有被篡改。委托人可以冻结账户资产公开声明成为担保人提供担保服务，担保能力取决于冻结的资产数量。当担保人接收到到委托人的大额交易超出担保能力时，可以选择其他担保人节点形成联合担保。其他担保人是否接受担保邀请不是强制的。是由个体终端自定义设置的，比如可以设置指定接受某一个担保人，或者必须经过顶端节点签名认可形成联合担保等。

 

2.1.3 顶端节点

顶端节点是全网选出最有担保能力的节点，由担保人角色负责，但仅负责诚实记录所有担保人节点的发来的支付链的先后顺序，并提供查询服务给其他担保人。顶端节点是收款方节点判断担保人额度有没有超支，支付链合法不合法的重要依据。

区块链初始化时顶端节点是第一个区块。顶端节点的签名数据的合法性通过节点定时“集会交流”的方式来监督，如果顶级节点作弊，其他节点将通过举证废除重新选取顶级节点。

2.1.4 聚合节点

聚合节点是用来汇总支付链及发布仲裁声明的节点。当支付链汇总时作弊的节点将会显现出”超支“冲突，当节点获取到相互冲突的支付链时会主动发起仲裁，扣除担保人押金用以填平超支的账单。如果发现顶端节点作弊将会扣除顶端节点押金并冻结其账户，然后重新选择最具有担保能力的节点作为顶端节点。如果没有作弊行为，所有的支付链将被担保人签名认可成为不可以变更的事实。

聚合节点是发现作弊行为的终极保障，其执行的频率是实现接近完全可靠的公共账本的关键参数。

假设V代表时间段内可靠率（100%既是完全可靠），聚合数据执行的时间间隔t，b为在这个时间段内被作弊的概率（风险值）。则：

V（1） =b/t

收款人在这个时间点之后进行确认收款操作，风险值将降为0，即已经被认作事实不会被篡改。委托与担保的理念是签名账单即意味着责任，所以在实名制的区块链系统因为监管的存在可以不必等待聚合完成再后确认交易来提高交易效率，因为超支的个人会被追缴，超支的单位会被追责。实名制的系统，法定的监管将作为最有担保能力的节点，即作为顶端节点。

受限于当前软硬件环境，过于频繁的执行聚合数据意味着使系统过高的负载。影响系统整体的吞吐量。在非实名制的系统下，鉴于作弊被追责的代价和交易数值的考量下小额交易可无需考虑等待完成聚合数据再确认交易，仅需要个人终端依据认可的第三方节点提供风险评价参考而决定是否交易即可，而对于大宗交易，等待聚合完成的时间是可以被人们接受的。

 

 

 

2.2 EG算法流程

如图2-1 支出方流程图，假设委托人A发起一份向D支付的签名账单，委托人A会将这份签名的账单发送给系统中的担保人节点C，担保人C拿到账单后会验证委托人A的签名是否正确，余额是否充足，当基本条件满足后会将账单签名后打包成包含本次账单担保人A的支付链数据（A的收支详单）传送给D的开户方担保人B，B确认C有担保能力后， 再将支付链传送给区块链网络中公认担保能力最强的担保人节点签名（顶端节点）以确认支付链是最新的且C的担保能力大于本次交易的数额。

 

 

 

 

2－1 支出方委托人流程图

 

收款人D在A的支付过程中起监察作用，在“仲裁机制实现规避双重支付”章节详解。收款人认为支付条件不可信时可以发起放弃收款来失效本次交易。放弃本次交易的签名指令将会首先发给A的开户方C，然后由C负责同步到顶级节点，解除占用本次交易的担保额度。

 

 

 

 

 

2－2 收入方委托人示意图

 

2.2.1 支付链

支付链是以时间戳排序的支付人的收支详单，如下图所示:

 

 

 

 

图 1-1 支付链

2.2.2 责任链

责任链可以从收支链上的签名反馈，作为“仲裁机制”的重要依据，如图1-1责任链所示：

 

 

 

 

 

 

图 1-1 责任链

 

 

2.3 仲裁机制实现可靠区块链

EG共识算法的仲裁机制能够实现规避双重支付漏洞。理论上任何一个责任链上的节点都有可能“叛变”，但仲裁机制可以保障收款人的权益。当最有担保能力的顶端节点"叛变" 将会使 “付款人”支付超出其能力的账单。在区块链总资产不变且在非实名制的的情况下意味着收款人会损失利益。仲裁机制导向的结果有三种：废弃本次交易，收款人百分百损失；仲裁成功，收款人不损失；仲裁成功，但扣除责任的担保金后仍不足以填平本次交易作弊的部分。

作弊的代价是极高的，不管作弊有没有成功，当作弊节点生成作弊数据被其他节点检测到并仲裁意味着损失押金并冻结账户的风险。在实名制体系里甚至要承担法律责任。

2.3.1 支付方担保人的“叛变”

支付方担保人的“叛变”是指支付方的账单超支，但支付方的开户担保人通过隐藏支出项或伪造收入项来签名支付链欺骗收款人接受交易。

这种作弊只有在超支的额度大于担保额+支付方的余额的情况才是有意义的。否则仲裁机制不仅会扣除支付方的余额和担保额还会进行锁定账户的操作。

收款人在不经过顶级节点验证支付方担保余额的情况接受这种账单风险是极大的。假设对方出现作弊行为，将会损失仲裁机制填不平的部分。EG共识算法之所以不强制执行经过顶级节点的验证是为了给支付网络更灵活的体验，实现”支票的功能“，最终支票是否有效，取决于实际。

2.3.2 顶端节点的“叛变”

顶端节点通过提供虚假的支付链序列使支付方担保人节点看起来有能力进行合法支付，但因为顶端节点是收款人节点授信支付方的重要依据，所以顶端节点作弊的数据一定会与区块链网络中某个节点的数据冲突，发现作弊行为的时间是避免损失的重要参数。

同样这种作弊只有在超支的额度大于担保额+支付方的余额+顶级节点的担保额度的情况才是有意义的。否则仲裁机制不仅会扣除支付方的余额和担保额还会进行锁定顶端节点账户的操作，然后全网聚合数据选出新的担保额度最高的节点。

 

第3章 区块链系统设计与实现

区块链是一个信息技术领域的术语。从本质上讲，它是一个共享数据库，存储于其中的数据或信息，具有“不可伪造”“全程留痕”“可以追溯”“公开透明”“集体维护”等特征。基于这些特征，区块链技术奠定了坚实的“信任“基础，创造了可靠的“合作”机制，具有广阔的运用前景。

区块链是一个社群化应用，应用应该实现当前的主流设备，移动端和服务端，移动端的基础应用实现支付功能，为方便其他上层应用接入需实现数据传输接口。服务端通过CS架构覆盖移动端功能且实现担保人组件，顶端节点，聚合节点的组件。

3.1 移动端需求分析

当前手持设备没有固定IP地址和高计算能力，在EG共识算法设计的区块链中担保人的组件需要固定IP地址和高计算能力，所以个人手持设备仅适合实现委托人的功能。

3.1.1 实现模块

（1）签名模块

提供委托人账单签名。

（2）服务端功能调用模块

通过调用服务端HTTP接口使用服务端对外开放的功能，比如安全分析，账单担保，数据存储等。

 

3.2 服务端需求有分析

服务端实现担保人，顶端节点，聚合节点的能力，可以为委托人提供服务。

天下熙攘，无利不往，服务端是有投资成本的，让人们参与共识机制，维护去中心化社区是需要激励的，这也是代币常常伴随公链发行的原因。但笔者认为发行货币是政府行为，个体组织凭空随意发行货币是一种扰乱市场的行为。

EG共识算法中总账的数额可以像其他区块链一样可以用作代币，EG链网络设立“矿池”。担保人节点提供担保服务俗称“挖矿”，区块链网络将按照担保人服务情况按劳分配。直到矿池挖空，担保人将以收取手续费的方式继续运营。

3.2.1 实现模块

（1）签名模块

提供担保服务签名。

（2）担保服务模块

提供担保服务。

（3）监察模块

提供交易分析，监察与自身相关的交易是否被作弊。同时提供接口为客户端调用或为第三方提供服务。

（4）仲裁模块

参与仲裁，实现作弊的追责与惩罚。

 

3.2.2 需要实现的接口

为了实现客户端自由调用第三方服务端的功能，服务端所有的接口需要支持跨域访问。此举有利于实现多端确认保障是否可靠。

（1）开户接口

提供委托人开户，配合转移开户的服务。

（2）委托接口

提供委托人账单的担保服务。

（3）联合接口

当担保人担保能力不足或想分担交易风险时可以链接其他支持联合担保服务的担保人节点共同为委托人提供担保服务。

（4）聚合接口

当聚合算法执行后，与其他节点交互的一系列接口。

（5）监察接口

可以为其他委托人特别是无法实现聚合的移动端节点提供监察服务。

（6）仲裁接口

可以为其他委托人特别是无法实现参与仲裁的移动端节点提供监察服务。

3.2.3 保障分析 

EG共识算法中的监察机制仲裁机制保障数据不被篡改。社群仲裁需要数据交互，需要有一个统一数据传输规范和达成共识的条件。

3.2.4 接口规范分析 

HTTP是目前应用最广泛的网络通信协议，EG链的交互接口基于HTTP通信，并支持跨域访问，使用JSON作为数据格式。接口使用RESTFUL风格，便于开发人员理解。

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       3.1.5 模块分析

（1）签名模块：

签名模块定义了系统统一的数据签名及数据验签规范，通过私钥对数据签名，公钥验证数据是否是私钥签发的。公钥作为钱包地址和私钥是一一对应的，在实名制区块链系统中可以绑定用户身份。

（2）担保服务模块：

担保服务模块意味中对其他节点提供担保服务，需要有固定的网络访问地址，同时提供给委托人开户的接口。

（3）委托业务模块：

委托业务模块能识别委托人提交的数据，通过签名模块验证签名后自动寻找委托人的开户方将数据上交。

委托人能够实时获取担保人处理交易的进度及结果。收入方委托人能够通过顶端节点实时查询支付方是否有足够的余额支付本次账单并且支付方的担保人是否有担保能力确保本次交易的合法性。同时收入方委托人能够通过区块链中任何一个网络节点查询聚合后的数据。假设发现支付方超支且顶端节点对本次交易提供虚假的参考数据便可以提交问题账单数据主动发起仲裁。

（4）监察模块：

监察模块负责计算委托人的支付链是否有效。监察的第一个维度是通过请求顶级节点获取经过顶端节点排序的委托人支付链，检查支付方是否超支。第二个维度是在数据聚合之后检查顶级节点返回的参考数据存不存在冲突的数据，若存在意味着某个账单存在失效的风险，可立即发起仲裁，追回损失。

（5）仲裁模块：

仲裁模块是在监察模块发现支付链冲突数据时发挥作用，当发现某委托人的支付链与其另一条支付链合并后存在超支问题，此时便可以发起仲裁，扣除某委托人的开户方的押金且冻结其开户方设定的时间作为惩罚。如果其开户方的押金不足以支付超支的部分，检查顶端节点签名其开户方担保额度是否存在冲突，如若错误则判定顶端节点作弊，从顶端节点扣除押金用来支付超支的部分，并废弃顶端节点重新选取顶端节点。假设此账单未经过顶端节点签名，则收款人账单中未被填平的超支部分将损失。

 

3.3 架构设计

单个节点是CS架构，S端可以集群部署来提高系统吞吐量。但区块链是社群应用，所以我称其整体架构是社群架构，在软件设计中还未有社群架构这个名词，但随着人工智能的发展，我相信社群架构的概念会率先通过区块链技术在软件设计中普遍，日后我会专门写一篇论文讨论社群架构标准及应用场景。本文以社群架构描述区块链是为了避免读者产生思维盲区，更容易理解EG共识算法的协作原理。

3.3.1 社群架构

为了更好的描述EG链的系统架构原理，本论文使用了”社群架构“这个名词。是指在软件设计中，每一个单元可以是一个完整的个体，但组合在一起后可以做不同的工作来实现系统整体的一个特性。这样的架构称之为社群架构。本文章中对EG链移动端的实现上做特别说明，因为考虑到移动端的特性及开发成本，移动端不开发独立实现所有功能的软件，但CS架构的C端可以是移动端。即C端可以调用S端实现所有功能。拥有S端资源的用户可以为C端用户提供安全分析，聚合查询，数据托管等等。由此扩展出了基于S端的生态应用，比如EG链中的S端为其他用户提供版权保护服务，C端只需要将数据传给S端，S端将数据上链。

3.3.2 系统架构

如图1-1系统架构所示，一个完整的区块链节点包含表现层、应用层、共识层、信息存储层、用户终端设备系统层。

 

 

 

 

 

图 1-1 系统架构

 

3.3.3 数据模型

如图1-1 委托人担保人签发的账单所示为支付链中的一个环节的基本信息，依照提交给顶端节点的时间戳将委托人的收支账单串联起来便是委托人的支付链。顶端节点将支付链签名，代表着顶端节点已经审核过担保人提交的支付链顺序。并将其完整的展现给其他节点。

 

 

 

 

 

图 1-1 委托人担保人签发的账单

 

3.3.4 采用技术

区块链系统以终端参与维护共识为核心，目前主流设备分为2类移动端和电脑端，考虑到目前的网络部署及设备运算能力，移动端无固定ip及公网能力，且不适合进行大数据处理，所以不适合单机实现担委托人的功能，但可以作为服务端的视窗或单机实现委托人的功能。电脑端等同于服务端可以连接公网作为服务器，所以需要实现担保人角色和委托人角色。

UNIAPP技术是一套代码支持多个终端的框架且拥有丰富UI组件，在开发成本考量，及功能实现上，是移动端开发的不二之选。本次需求将以UNIAPP为框架开发实现EG在app端的应用。

java适合分布式服务开发，其跨平台能力能减少开发成本，所以使用java开发电脑端实现担保人和委托人的角色。移动端使用安卓开发技术和IOS开发技术实现委托人角色。

3.4 算法设计

在整个服务端移动端节点设计中需要用到统一的算法实现整体一致可以协同交互。

以下是不管使用任何语言编制EG链程序必须用到的规范算法。

3.4.1 非对称式加密算法

非对称加密算法需要两个密钥：公开密钥（PUBLICKEY:简称公钥）和私有密钥（PRIVATEKEY:简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。 非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将公钥公开，需要向甲方发送信息的其他角色(乙方)使用该密钥(甲方的公钥)对机密信息进行加密后再发送给甲方；甲方再用自己私钥对加密后的信息进行解密。甲方想要回复乙方时正好相反，使用乙方的公钥对数据进行加密，同理，乙方使用自己的私钥来进行解密。

另一方面，甲方可以使用自己的私钥对机密信息进行签名后再发送给乙方；乙方再用甲方的公钥对甲方发送回来的数据进行验签。

3.4.2 顶点选择算法

EG链规定数据集合中担保额度最高且没有失信的担保人节点为顶端节点，简称顶点。若顶端节点因为网络及硬件原因不能提供服务，重新选举顶端节点，若恢复服务可申请转回顶端节点。

不能服务选举其他顶端节点的条件：

10分钟内未返回结果记录为失败1次，若同一个节点失败次数在1个小时之内超过6次，则可以在下次聚合过程中举报，举报的权重为处理的能力。在全网中累计的举报权重超过总权重的一半即是举报成功，重新选举顶端节点。

3.4.3 聚合节点选择算法

每一个节点可以发起聚合请求，但是这种行为需要进行必要的控制，以免整个系统频繁的负载过高。

（1）不拒绝关心的数据

从聚合需求上分析，聚合数据是为了监察顶级节点是否有作弊行为，而担保人实际更关心跟自己经济的账单委托人的数据。所以EG链中的单个节点发起一个聚合请求首先要公布自己关心的委托人名单。当系统中其他节点收到聚合请求有共同关心的委托人时便“不能拒绝（没有理由拒绝）”交流全部数据。

（2）不拒绝关心的数据，且选择“聚合能力最强”的节点作为中心投送数据

为了“防患于未然”，每个节点的趋向都是想拥有整个账单。但假设系统有极多的节点，或黑客造就极多的节点发起聚合请求，如果满足所有节点的聚合请求那意味着系统中每一个节点的负载是极高的且是浪费的。

为了解决这个问题我们要求节点发起聚合请求时不仅要公布自己关心的委托人相关数据，还要公布与其担保数据聚合的情况。系统设置一定时间间隔视为完成聚合。

因为”关心“级联的存在，意味着发起聚合请求且自己关心的节点中存在着聚合节点多少不一的情况。这里选择聚合节点数最多的节点视为”聚合能力最强“的节点。

（3）数据安全

由于聚合能力最强具有可预测性，那么聚合能力最强的节点会不会被策反呢？关于这个问题其实是可以百分百解决的。从任何节点聚合而来的数据块都有那个节点的签名，如果被篡改会第一时间被同步数据的节点”察觉到“，由此将此节点加入黑名单，重新开始聚合数据且被加入黑名单的节点意味着永久不能作为聚合节点。

（4）对关联性的数据负责

当聚合发起后，无论是其他节点的询问还是主动参与聚合，需要提交诚实的关于自己担保的支付链数据，如果不诚实意味自己隐藏的部分将不被公众接受，与其他节点矛盾的部分将被追责和惩罚。所以聚合发起每一个节点会主动诚实的公布自己的数据。

 

3.5 模块设计

3.5.1 签名模块

EG链共识算法选定ECC算法（椭圆曲线算法）作为公私钥的非对称式加密算法。选用ECC的理由是，ECC是目前破解难度系数最高的加密算法。

椭圆加密算法（ECC）是一种公钥加密体制，最初由Koblitz和Miller两人于1985年提出，其数学基础是利用椭圆曲线上的有理点构成Abel加法群上椭圆离散对数的计算困难性。公钥密码体制根据其所依据的难题一般分为三类：大素数分解问题类、离散对数问题类、椭圆曲线类。有时也把椭圆曲线类归为离散对数类。选用的理由：

安全性高

有研究表示160位的椭圆密钥与1024位的RSA密钥安全性相同。

处理速度快

在私钥的加密解密速度上，ecc算法比RSA、DSA速度更快。

存储空间占用小。

带宽要求低。 [2]

参考资料来源：百度百科——椭圆加密算法

 

3.5.2 担保服务模块

担保服务分为2块，一块是接收委托人的账单签名，一块是接受其他担保人的支付链形成联合担保。第二块担保节点可以选择是否开启。

接受委托人账单：

计算委托人余额，余额充足后对账单签名担保。

接受其他担保人发来的委托人支付链：

根据节点的参数设置：单纯验签委托人支付链，判断余额充足便签名担保；通过顶端节点签名后再签名担保；数据聚合后再签名担保。风险级别是依次降低的，但吞吐效率是也是依次降低的。

3.5.3 委托业务模块

委托人从担保人那里获取到支付链后会计算余额给展示层。为了避免计算资源浪费，当委托人多次提交无效账单时进行锁定服务操作。委托业务模块为了避免这种情况会主动提示用户钱包余额是0，不要尝试签发账单。

签发账单：

如图1-1签发账单所示，委托人需要对签发的账单进行负责，类似于银行支票，发出去意味中支出。

 

图 1-1 签发账单

3.5.4 监察模块

用户的区块链钱包进账后会检查付款人的支付链是否有超支的情况。有超支的情况意味着付款人联合担保人作弊，若经过顶级节点签名则代表着顶级节点也有作弊行为，此时便可以将作弊信息提交给仲裁模块处理。

担保人聚合数据后会检查包含自身及在当前节点开户的担保人节点的支付链是否超支的情况，然后同上处理。

3.5.5 仲裁模块

当接收到监察模块发起的仲裁后会立即开始仲裁事务。

担保人作弊：

担保人作弊意味着数据并没有经过顶端节点签名，此时仲裁模块只需要将问题账单提交给顶端节点追回损失，顶端节点收到问题帐单后确认属实后会做扣除问题账单担保人押金的裁决，其他节点同步数据时会同步这个裁决并认可。未填平的部分将损失。

顶端节点作弊：

顶端节点作弊将由聚合事务处理，委托人或担保人提交顶端节点作弊证据后，所有节点以相同的规则判定扣除问题账单的担保人押金，若不足账单金额会以顶端节点的押金补充，同时废除顶端节点，根据顶点选择算法选出新的顶端节点。未填平的部分将损失。

 

 

3.6 移动端开发实现

委托人进行业务委托及社群架构的维护都离不开网络交互，EG链本着代码复用且低开发成本的原则规定，数据交互使用JSON格式的数据体，接口以RESTFUL风格实现。

3.6.1 签名模块实现

为减少开发成本，移动端的视窗及数据处理使用UNIAPP技术，实现签名模块和委托业务模块，及调用其他担保人节点监察模块和仲裁模块的功能。

（1）非对称加密算法的实现

eosjs-ecc.js是使用js实现椭圆曲线加密算法的代码库。调用ecc.randomKey()随机生成公钥私钥对，由于默认生成的密钥对字符串长度太长不利于人眼识别，经过BASE64加密后可生成121个字符的公钥和89个字符的私钥。随机生成的公钥可以向担保人申请开户既可以成为EG链的钱包身份标识。

3.6.1 服务端功能调用模块

（1）委托业务模块实现

使用ecc将图1-1委托人签发账单 所示的账单进行签名，发送给担保人进行交易。

 

 

图 1-1 委托人签发账单

 

 

（2）数据存储

数据存储模块用于支付链及初始化参数的存储，使用SQLLITE,SQLLITE是一个关系型数据库，可以很好的存储支付链数据结构的数据。

（3）调取委托人监察接口和仲裁接口

Js的 ajax功能可以胜任调用接口的交互能力。由于移动端没有固定IP和低算力，所以无法实现参与聚合，但移动端可以选择担保人为其实现监察模块和仲裁模块的功能。

3.7 服务端实现

3.7.1 签名及委托业务模块实现

Java的ScriptEngineManager是一个用java实现的js引擎，可以调用eosjs-ecc.js签名算法。所以可以完全复用移动端开发的签名和委托业务模块。

3.7.2 担保模块实现

担保模块在接收到委托人账单数据后进行验证余额，余额充足后将账单签名打包成支付链发送给收款方担保人。

担保人签名的账单的数据结果如图1-1担保人签名账单：

 

图 1-1 担保人签发账单

 

3.7.3 监察模块实现

监察模块实现自己及他人账单数据的监察。调用getTopSupervise(blockchain)方法将支付链发送给顶端节点，顶端节点签名返回该支付链是否经由顶端节点签名且没有超支。如果超支调用仲裁模块发起仲裁。调用getUniSuoervise(blockchain)监察聚合后的数据中的支付链是否合法。

3.7.4 仲裁模块实现

发现非顶端节点的作弊调用doTopArbitrate(blockchain)通过顶端节点仲裁。发现顶端节点参与作弊调用doUniArbitrate(blockchanin)发起聚合节点仲裁事务。doUniArbitrate发起后通过递归的方式互相通知其他节点,任何一个担保服务节点一经确认证据便停止担保服务参与仲裁事务直到仲裁完成。仲裁过程是在聚合算法执行后开始，全网任何一个参与的节点可以查询。

3.8 性能评估

本次性能评估包含2个维度，软硬件横向扩展和达成保障共识耗用的时间，主要验证基于EG共识算法能不能实现TPS的横向扩展。

3.8.1性能评估概念

本次测评按照EG共识算法中完全可靠的方式测评，即每次交易主动发起聚合数据请求，等待完成聚合为一个交易完成。理论上一个完全可靠的交易需要等待聚合数据的完成，而聚合算法是所有节点积极执行的，也就是说在共识维度不存在直接事务限制，限制来源于软硬件指标。

 

3.8.2 性能测试目的

测试少量节点和多个节点及不同硬件指标下系统的性能是否可以横向优化 。

3.8.3 测试环境

（1）服务器硬件配置

2.3GHZ双核CPU

8G内存

1M带宽

软件环境

LINUX

3.8.4 JMETER测试指标

（1）Averge/ms:服务器处理事务平均响应时间（表示客户端请求到服务器处理信息且反馈客户端的时间）

 

3.8.5 测试工具和测试策略

测试工具：Apache-jmeter

测试策略:

（1）5000份不同委托人的账单发起支付请求。

（2）委托人节点和顶端节点扩充1倍集群部署。

3.8.6 策略1测试结果如下：

 

指标	测试值
压测时长	20分10秒
并发数	100个线程（等价100个虚拟用户）
平均响应时间	10556毫秒
最大响应时间	41595毫秒
吞吐量	3542.3/sec
容错率	0.01%

3.8.7 策略2测试结果如下：

 

指标	测试值
压测时长	20分10秒
并发数	100个线程（等价100个虚拟用户）
平均响应时间	6040毫秒
最大响应时间	8907毫秒
吞吐量	5000/sec
容错率	0.01%

3.8.8 结论

基于EG算法实现的区块链系统的吞吐量可以实现横向扩展。

单个节点的程序可以集群部署。集群数量越多TPS值越高。

 

第4章 总结与展望

本文以EG共识算法为理论基础进行了区块链系统的设计，她是通过围绕着用户的支付行为，构建支付链数据，由此映射出责任链，EG区块链整个系统的仲裁和追责机制确保解了数据的可追溯，不可篡改的特性，这样的设计模式是符合生产规率的，以价值去驱动，以角色参与系统构成社群整体，分别承担不同的责任，在软件层面解耦合，整体上达成共识形成统一规则，而且使系统的吞吐能力不限制于每一个节点实现的功能可以集群部署，在支付领域，对安全性和支付效率有着极高的要求，比特币的共识特性决定了只有在多个分支内认可了交易才能认为是有效的交易，而这个时间需要10多分钟，在日常生活中这样慢的交易是不被认可，仅凭这一点决定了比特币无法成为货币，无法构建要求10分钟内响应结果的上层应用，且资源导向型的架构一定会被淘汰，无法成为主流，而EG共识算法以责任链作为保障数据不被篡改，符合生产规率，其吞吐能力可以伴随硬件优化。不限制于共识本身。但EG共识算法在非记名系统里完全可靠依赖于聚合算法的执行，但聚合算法的执行频率受限于单节点的软硬件环境，执行频率越高意味着系统负载越高，当受限于硬件负载，将无法实现高吞吐量，在EG2.0版本可以围绕高性能聚合数据这个问题，展开研究，提升EG链的生产效率。

 

 

参考文献

[1] 章刘成, 张莉, 杨维芝. 区块链技术研究概述及其应用研究[J]. 商业经济, 2018(4):170-171.

[2] I. Blake, G. Seroussi, and N. Smart, editors, Advances in Elliptic Curve Cryptography, London Mathematical Society 317, Cambridge University Press, 2005.

[3] 区块链技术的现状与趋势探析[J]. 狄刚.  金融电子化. 2018(09)

[4] 区块链技术发展现状与展望[J]. 袁勇,王飞跃.  自动化学报. 2016(04)

[5] A Survey on the security of blockchain systems[J] . Xiaoqi Li,Peng Jiang,Ting Chen,Xiapu Luo,Qiaoyan Wen.  Future Generation Computer Systems . 2017

致    谢

本论文是在郑秋梅教授的悉心指导下完成的。郑秋梅教授的以严格治学态度使我受益匪浅，她通过渊博的学识让论文增加色彩，使我完成了一个工整严谨的论文。

 

指导教师 ：郑秋梅职称：教授