根据微众银行与BSN的合作协议新葡萄京官网8455,系统合约原则上由区块链管理员在网络启动之初部署全网生效

新葡萄京官网8455 1

.wqpc_wechat_view *{max-width: 100%!important;box-sizing:
border-box!important;-webkit-box-sizing: border-box!important;
word-wrap: break-word!important;} 微信号 功能介绍
在回答这个问题之前,首先要理清“区块链数据”和“链上数据”的概念。区块链数据“区块链数据”广义上包括区块链的区块数据和区块链的状态数据:区块数据记录了区块链上发生的每一笔交易,譬如小明给小王转账了50元、小王充值了20元等类似这样的交易数据;状态数据记录了区块链上每个账户或智能合约的当前状态,比如小明当前的余额是50元、小王当前的余额是100元。无论区块数据还是状态数据,它们都是由区块链节点使用和存储的。区块链节点是一个程序,运行在我们的个人电脑、虚拟机或服务器上。多个分布在不同电脑或服务器上的区块链节点,通过网络互相连接,组成了完整的区块链网络。区块链节点通常会把区块链数据存储在个人电脑、虚拟机或服务器上,存储区块链数据最常见的介质,就是磁盘。区块链节点不会直接访问磁盘,它们会通过特定的数据库,如LevelDB、RocksDB或MySQL等单机或分布式数据库来操作数据。相比于直接操作磁盘,数据库抽象了特定的数据访问模型,对区块链节点更为友好。因此,当我们说:“区块链数据保存在数据库”时,可以认为区块链节点将区块链数据保存在MySQL(或其它数据库),MySQL将区块链数据保存在磁盘。数据库有独立式与嵌入式之分:独立式数据库,如MySQL、Oracle是通常理解的数据库,独立式数据库作为独立的进程运行,需要单独部署和启停。独立式数据库可以与区块链节点部署在同一台服务器,或者部署在不同的服务器,还支持分布式、集群化的部署。无论何种部署方式,独立式数据库都是区块链节点的存储组件,隶属于区块链节点,与区块链网络无关。嵌入式数据库如LevelDB、RocksDB,它们以动态依赖库或静态依赖库的方式,与区块链节点整合在同一个进程中,同时启停,用户不会明显感受到它们的存在。链上数据区块链数据的区块数据和状态数据并不是凭空产生的。区块数据中的交易,是由区块链的用户生成,用户把交易发送到区块链节点,区块链节点将多个交易打包进区块,区块会在区块链网络上广播和共识,区块链网络对区块达成共识后,认同区块中的交易,将交易的执行结果保存到状态数据中。假设区块链原本的状态数据是:小明当前的余额是50元、小王当前的余额是100元,那么执行了“小明给小王转账了50元”的交易后,状态数据会发生变化,小明当前的余额会变为0元,小王当前的余额变为150元。区块需要进行区块链共识,状态数据是通过执行区块中的交易生成的,这两类数据都直接或间接跟区块链共识有关系,可以将其称为“链上数据”。那么,“链上数据”的明确定义,就是:链上数据是直接或间接由区块链共识产生的数据。回到最初的问题很显然,“链上数据”和“数据库”不是同一个层面的概念,“区块链数据是存在链上还是存在数据库?”这个问题不成立,区块链数据无论是存储在LevelDB、RocksDB、MySQL数据库或直接存储在磁盘,只要是直接或间接由区块链共识产生,都可以视为链上数据。FISCO
BCOS的链上数据FISCO
BCOS的区块链数据,默认是通过RocksDB保存在磁盘中。如果希望把数据保存到MySQL数据库,可以先自行部署一个MySQL数据库,然后修改区块链节点下的群组配置文件,群组配置文件通常位于区块链节点的配置目录下:conf/group.1.ini[storage]type=mysqldb_ip=127.0.0.1db_port=3306db_username=rootdb_name=db_Group1_Adb_passwd=******其中:type为区块链节点的存储类型,配置为mysql,表示使用MySQL来存储区块链数据;db_ip为MySQL数据库的IP地址,如果部署在本机,就是127.0.0.1;db_port为MySQL数据库的端口,默认为3306;db_username是MySQL数据库的登陆用户名;db_name是MySQL数据库中用于存储区块链数据的数据库名,无需先行创建;db_passwd是MySQL数据库的登陆密码。其它未提及的配置项,可保留默认值不修改,完成这些信息的填写以后,确保数据库运行正常,然后重启区块链节点,区块链节点就会将区块链数据保存到MySQL数据库中。FISCO
BCOS的区块链,无论是保存在RocksDB还是MySQL中,都可视为链上数据。使用MySQL,可以方便地查看链上数据的大小、结构等信息,如区块的大小、账户的大小等等。总
结FISCO
BCOS提供了灵活的数据存储机制,对于追求便利与性能的场景,可以使用默认的RocksDB;对于偏重审计和治理的场景,可以使用MySQL,满足不同的需求。

联盟链是目前区块链落地实践的热点,也是大家对“杀手级应用”期望最大的区块链部署形态。联盟链的诞生源于对区块链技术的“反思”,是对比特币、以太坊所体现的技术特点与企业客户实际需要的融合与折衷,蕴含了大量区块链工作者的智慧与辛劳。由于对未来价值的“共识”,很多厂商推出了自己的联盟链框架或平台,本文选择了
Hyperledger Fabric、FISCO BCOS、微软的 Coco、企业以太坊联盟(EEA)及 R3
的 Corda
这五个具有一定影响力的联盟链,拟从设计理念、生态、效率、扩展性、节点管理与权限管理、智能合约、部署与运维友好性、隐私保护、公链结合或演化能力九个方面进行比对,以供各位开发者、爱好者参考。其中,EEA
由于只出具规范而不涉及代码,所以比对中采用了其官方承认的技术基础——摩根大通的
Quorum 平台;Corda
并不是区块链,严格说与其他四者的比较属于分布式账本技术这个层级的比较,但是由于其承认设计上是受到区块链技术启发,且对其他联盟链也产生了一定的影响,因此,也列入了比较范围。本文的信息主要来源于公开的技术白皮书、Github
中的开源信息,就不在文中一一注明了。一、设计理念设计理念其实决定了一个框架或者系统的最佳应用方式,是其设计的出发点,因此,研究每种区块链时,都应当认真关注其如何“看待自己”,以免在应用上出现“硬套”的问题。设计理念上本文分成核心思路与市场定位两部分进行比较。(一)核心思路核心思路体现的是其设计初衷,这个“初心”对其后续技术走向有一定的影响。Hyperledger
Fabric
是希望改变公链的单一通用网络模式,通过建立多个可以互联的区块链网络覆盖各类不同的业务场景,实现设计的灵活性,满足多样化的要求,并实现网络间的交互,这种思路体现在了其独特的通道机制设计上。FISCO
BCOS
初衷是设计一个国内企业主导研发、自主可控、对外开源的满足金融行业需求企业级区块链底层平台,并逐渐扩展至其他领域、适用于广泛的分布式商业场景,所以进行了自底向上的完整设计,并考虑了较多国内的特殊需求。Coco
基于保密联盟环境的假定,重新评估了公链的设计,通过将其他区块链协议集成为底层,快速高效地构建区块链应用。在这种思路下
Coco
大胆放松了一些关键的设计限制,并且最终实现了一个对现有区块链协议的加速机制,可集成的协议已经包括
Hyperledger Fabric、以太坊、Corda、Quorum 等。EEA
是力求引导一种基于以太坊的标准区块链设计,可根据成员需要定制,但不提供代码(Quorum
提供部分开源代码)。官方承认其技术基础是摩根大通开发的 Quorum
平台,该平台的目标则是提供高速、高吞吐量交易的能力,以解决区块链技术在金融等领域遭遇的挑战。Corda
希望提供一个具有唯一性、权威性、可以记录企业间所有协议的全局逻辑账本,核心是实现具有节点间最小信任机制的无中心数据库,因此,Corda
主张充分考虑与现有业务系统的结合,而非将现有业务系统拆掉重来。Corda
的设计思路对 Hyperledger Fabric
有一定影响,也参与了对后者的建设。(二)市场定位市场定位反映了对自身应用方向的价值主张。五个联盟链都是面向企业级应用的,但是具体的定位略有差异:Hyperledger
Fabric 旨在打造不分行业的通用区块链开源框架;FISCO BCOS
源自企业级区块链平台
BCOS,做为一个金融版本分支,保留通用性的同时,更关注于金融行业,并且较多考虑了监管机构的特殊性;Coco
希望提供更高效易用的区块链技术,没有特殊的行业定位;EEA
比较有趣,它以将所有企业导向一个统一的路线图(该路线图以以太坊技术发展为基础)为目标,但是由于目前的技术代表是摩根大通的
Quorum,所以,应用实例上对金融行业更有指导性;Corda
则是针对金融行业的,并且明确提出至少一定时间内不会考虑其他行业。从设计理念的角度来讲,选用
Hyperledger Fabric
时,应当善用其通道机制,通过通道机制降低业务或者环境的复杂度,但是要注意其跨通道能力的一些技术限制;FISCO
BCOS
则应关注其对国内市场特殊需求的适应性设计,这些设计会带来很多部署上的优势;Coco

EEA(Quorum)设计理念上都属于基于现有协议的优化加速机制,只是前者“博爱”,兼容的协议更多,后者“专一”,只针对以太坊;选用
Corda
则要先明确,它不是区块链,不要带着区块链的价值假定去应用。二、生态大家常说建联盟链就是建生态,所以本文就比较下要帮着别人建生态的联盟链,其自身的生态建的如何。生态考察主要包括管理方、社区和商业应用这三个方面。(一)管理方从管理方看,各家都是“实力派”。Hyperledger
Fabric 的管理方是 Linux 基金会,基金会管理下的 Hyperledger
其实是一个项目系列,包括 Cello、Swatooth、Burrow、Iroha 等;FISCO BCOS
管理方是金链盟,金链盟是由深圳市金融科技协会、深圳前海微众银行、深证通、腾讯、华为、中科院等金融机构、科技企业、学术机构等组成的非营利性组织;(参考
的管理方是微软;EEA
是由芝加哥交易所、因特尔、ING、摩根大通和微软等三十几家创始成员组成的;Corda
的管理方 R3 是以银行为主的组织,至少已经吸收了 42
家金融巨头,包括富国银行、美国银行、花旗银行、德意志银行、加拿大皇家银行等,我国的平安、招行等也是其成员,不过
R3
麻烦不断,也有些重量级成员已经退出。(二)社区现今科技发展比较流行开源,五大联盟链也都是开源的,开源意味着要搞好社区建设,通过社区推广和改进设计,凝聚更多智慧。Hyperledger
Fabric 已经打造了国际化的社区,除了在 GitHub 上比较活跃外,大量的线下
Meetup、技术推广活动也比较多,加上 IBM
的有力推动,使其有了大量的活跃用户;FISCO BCOS
社区建设初现规模,已有了千级成员、百级机构参与,除了 GitHub
外,还有官方微信群。FISCO BCOS
在不断迭代源码和文档的基础上,陆续推出了线上线下多种形式的系列运营活动,包括技术培训、高校开课、线上线下讲座沙龙、包括近期举办的金链盟中国区块链大赛,影响力逐渐扩散。作为国内开源项目,相信未来发展上会有一定的“天时地利人和”;Coco
社区不是很活跃;Quorum 在 GitHub 上已经有了 551
个话题,有一定活跃度;Corda
也不是很活跃。(三)商业应用商业应用是大家打造区块链平台的目的,也是一个联盟链最重要的人气所在。Hyperledger
Fabric 得益于 IBM
的大力推广,加上技术框架比较成熟、推出较早,目前已有较多商业应用,据 IBM
披露有 400
多个落地项目,其中不乏马士基、沃尔玛、联想、邮储银行这类大型客户,也有统计称,所有联盟链项目中
Hyperledger Fabric 已占据半壁江山;FISCO BCOS
从金融出发,携本土优势,落地项目也有数十个,包括微众银行的机构间对账平台、网易的竞猜游戏,四方精创的供应链金融、城商行旅游金融联盟的旅游金融、仲裁链、安妮股份的版权存证平台、乐寻坊的人才活动平台、链动时代的不动产登记系统等;Coco
目前在项目方面乏善可陈,除了其白皮书中提到的 Mojix 将其供应链 Dapp
转移到 Coco 平台上之外,没有更多公开的项目信息;Quorum
上,比较有影响的应该算是 2017 年 10 月摩根大通开发的 IIN(Interbank
Information
Network)平台,实现跨行信息交互,摩根大通、加拿大皇家银行、澳大利亚 ANZ
银行、新西兰银行等相继加入该平台;Corda
也是同样的境地,雷大雨小,耗费巨资,但是测试的多,落地的少。从生态角度看,Hyperledger
Fabric启动的比较早,目前领先一步,但是 FISCO BCOS
奋起直追,已经初见规模,Coco、Quorum、Corda
还需要做很大努力。三、效率区块链目前最差强人意的指标莫过于效率,虽然现在也有些人开始反思也许不应当苛求区块链的效率,但是商业应用总是回避不了这个问题。效率方面,本文从共识协议、出块速度、TPS
和存储消耗这四点加以比对。(一)共识协议联盟链为了提升交易速度,往往是先从共识协议“下手”。POW
和 POS
都无法满足商业应用的需要,“挖矿”对联盟链来讲也是没必要的,因此,各家都采用了替代的共识方案。Hyperledger
Fabric 在 0.6 版中应用了 PBFT,而在 1.0 版中放弃了
PBFT,转而采用效率更高的 Kafka,支持单点和集群两种方式,由 Kafka
直接给交易排序和出块。FISCO BCOS 支持并行计算的 PBFT 和标准 RAFT
两种方式,前者是将通常的 PBFT
中议长节点和投票节点分步验证的方式优化为并发验证,从而进一步提高共识效率;Coco
支持 Paxos 和 Caesar 两种协议。由于 Coco 节点是建立在基于硬件的
TEEs(可信执行环境)上,因此就假定了节点充分可信,所以在 Paxos
中,leader 节点处理过的事务,follwer
节点简单跟随即可,这体现了其对公链假定的改变;Caesar
支持灵活的容错模型,可以与 Paxos 共同使用以防范 leader 节点由于 TEEs
遭到破坏产生的安全威胁,该协议支持在 follwer 节点发现 leader
节点不可靠时将其驱逐,从而保证全网的安全;Quorum 支持 Raft 和 Istanbul
BFT 两种协议。后者是由来自台湾的 AMIS 帐联网公司在 2017
年研发的,可以大幅提升现有的以太坊架构的讯息交换效率;Corda
比较特殊,它借鉴“矿工”角色设计了公证人模块来提供交易公证(也即签名)服务,整个网络不依赖于任何特定的共识算法。但公证人是一个集群概念,一般使用
BFT 或 Raft
在公证人间达成一致,因此,公证人是存在效率问题,可能成为效率瓶颈;与传统分布式系统的共识设计相比,Hyperledger
Fabric 并没有什么改进,其共识方式与中心化共识的分布式数据库一致;FISCO
BCOS 支持 PBFT 共识算法,具备拜占庭容错功能,也提供 RAFT
共识算法,适用于在节点可信度比较乐观的场景;Coco 是通过 TEEs
提高节点可信性,以降低共识协议的复杂度;Quorum
也没做多少调整,尤其是在引入 Istanbul BFT 之前;Corda
应该说是在传统设计中引入了“矿工”理念。(二)出块速度由于替换了共识机制,因此相比使用
POW 的比特币、以太坊,联盟链出块速度要提高很多。Hyperledger
Fabric、FISCO BCOS、Coco 都是秒级出块;Quorum 则称是毫秒级,默认设定是
50 毫秒,可以调整;Corda
没有块,所以也没有出块速度可以考量。(三)TPSTPS
相当于区块链世界中的“网红”,很多新出现的链都把 TPS
贴在“脑门”上。这五大联盟链虽然 TPS
远高于比特币、以太坊,但还是比现有的分布式系统逊色:Hyperledger Fabric
通常实测的 TPS 在 300-500 之间;FISCO BCOS 实测单链可以达到 1000
以上。并且支持多链架构下的并行计算,可灵活扩展,理论上无上限。Coco
官方数据是 1600;Quorum 在 Istanbul BFT 协议下可以达到 400-800,Raft
下缺少数据;Corda 由于其网络结构的原因,没有全局吞吐量可以衡量。其实 TPS
方面如果没有达到一个数量级以上的差异,是不用特殊关注的,因为在实际应用中,节点数量、网络环境、硬件配置、软件设计等都会对
TPS
产生影响,而现有的联盟链在吞吐量上已经可以满足相当一部分商业场景的要求,毕竟
Visa 在 2016 年每秒实际处理的交易也只有 1,667 笔,尽管 Visanet
据称有每秒处理 56,000
笔交易的能力。(四)存储消耗区块链可以说是以“浪费”存储来换取信任的技术。虽然存储设备的价格越来越低廉,但这不代表“浪费”就没毛病,存储的快速膨胀一定会带来效率、成本、可用性等诸多问题,甚至会要求改变设计架构,尤其是在大家都想追求“杀手级应用”的时候。Hyperledger
Fabric 方面,蚂蚁金服倒是给出了一个详细的计算公式,Fabric
数据容量估算(GB) = 每种业务每天平均交易笔数 x (Fabric 每笔交易基本开销

新葡萄京官网8455 1

机构证书合约

CAAction.sol是机构证书模块的实现合约。它实现了对网络中所有节点的机构证书信息的登记、管理、维护功能。当网络启用机构证书验证功能的情况下,网络中节点加入或退出都需要与机构证书合约进行交互。

机构证书的数据结构是:

struct CaInfo{
        string  hash;       #节点机构证书哈希
        string pubkey;      #证书公钥
        string orgname;     #机构名称
        uint notbefore;     #证书启用日期
        uint notafter;      #证书失效时间
        CaStatus status;    #证书状态
        string    whitelist;#IP白名单
        string    blacklist;#IP黑名单
        uint    blocknumber;#生效区块高度
      }

主要接口如下:

接口 输入参数 输出参数 说明
update string _hash,string _pubkey,string _orgname,uint _notbefore,uint _notafter,CaStatus _status,string _whitelist,string _blacklist # 证书哈希、证书公钥、机构名称、 证书启用日期、 证书失效时间、证书状态、IP白名单、IP黑名单 bool #更新结果 更新证书信息, 若该证书信息不存在,则新建证书记录
get string _hash#证书哈希 string,string,string,uint,uint,CaStatus,uint# 证书哈希、证书公钥、机构名称、证书启用日期、证书失效时间、证书状态、生效区块块号 查询证书信息

近年来,中国作为区块链研究的先行者,取得诸多有目共睹的成就。但在实操层面,各行业用户在应用区块链技术的过程中,常面临成链成本高昂、底层平台异构、数据无法交互等困境。推进区块链底层公用基础设施建设已成为谋求数字经济发展的题中之义。

  • 每笔交易平均业务数据大小 KB x 2 ) x 业务 Channel 数量 x(365 x 年数
    x(Peer 节点数量 x 2~1 之间 + Orderer 节点数量)+ Kafka Retention 天数 x
    Kafka Replica 数量) / (1024 x 1024),其计算示例中,在业务笔数每天 10
    万、4 节点、2 通道、单笔交易容量 1K
    的情况(其他因素不详细列出了)下,年存储消耗 4619G;FISCO BCOS
    支持历史数据快速追踪,对接数据库,实现分布式存储,能够支持海量服务的存储需求,提高存储访问速率,节省存储消耗。Coco
    由于设计上需要集成区块链协议做底层,因此其消耗就取决于集成的区块链协议,比如集成了
    Hyperledger Fabric,那加上 Coco 自身的消耗,其存储消耗量至少应该是比肩
    Fabric 的;Quorum
    也没有针对存储的特殊优化,至少应当按照大于以太坊消耗来估算;Corda
    倒是不同于其他联盟链,因为它基本上就是传统的分布式数据库,而且没有任何节点保存全局数据,每个节点都只保存跟自己有关的数据,所以,其存储消耗应该与传统分布式系统设计类似,没有过多的冗余消耗。综上,从效率方面看,在
    Hyperledger Fabric 之后推出或开源的其他联盟链,效率高于它也属正常。FISCO
    BCOS、Quorum
    本就是面向金融的设计,所以效率要求自然要高于一开始就希望做通用框架
    Hyperledger Fabric;Coco
    设计理念上就是希望做成“加速器”的,它的效率理应高于任何它可以集成的区块链;而
    Corda
    的设计模式决定了很难全面评价其效率,只能去单独观察每个实例。四、扩展性联盟链的用户都希望自己能发展成生态圈,比如海尔的供应链、中化的原油进出口贸易平台、马士基的全球交易平台等,因此,扩展性是联盟链设计必须要考虑的问题。这方面本文关注了节点数量扩展、共识扩展、单多链模式、加密算法扩展、第三方认证证书支持这五点。(一)节点数量扩展Hyperledger
    Fabric
    在节点数量扩展方面是弱项,已落地项目多是个位数节点,但是可以支持较多的客户端,算是一种弥补,不过节点数少其实意味着参与方的独立性是会有所下降的;FISCO
    BCOS
    的分组模式支持根据节点数量进行水平扩容,因此理论上节点数量是不受限制的;Coco
    在这方面有些“投机取巧”,可支持的节点数量取决于其集成的区块链协议,如果集成的是公链协议,在理论上也不受限制;Quorum
    是基于以太坊的,因此理论上也没有限制;Corda
    同样也没有节点数限制。虽然除了 Hyperledger
    Fabric,其他联盟链似乎都没有节点数量问题,但是节点数量其实还受共识协议的影响,BFT
    类共识协议在节点数量超过一定水平时会出现吞吐量下降,设计时应当考虑这点。(二)共识协议扩展共识协议的扩展能力对联盟链的稳定性有很大影响,能否根据节点数量、网络平衡情况、吞吐量进行调整决定了其网络的扩展能力。Hyperledger
    Fabric
    虽然很早在设计上就称其共识模块可插拔,但是目前实际应用上看是不具备插拔能力的,每个版本仅支持一种共识模式;FISCO
    BCOS 支持共识协议的插件式实现,允许切换共识机制;Coco、Quorum
    目前也具备了这种能力;Corda
    实现的应该说不是共识协议的直接插拔,而是公证人模块的可插拔,可以通过切换公证人模块来选择公证人的共识模式。(三)单多链模式多链模式目前被很多新出现的链用于性能扩展,不过多链模式有利有弊,提升性能的同时也增加了设计复杂度。Hyperledger
    Fabric 的通道机制其实可以算是早期的多链设计,但是通道在 Hyperledger
    Fabric
    中并不是出于提升效率的目的设计的,而是为了满足业务多样性要求,以降低业务复杂度,因此,通道机制目前在性能扩展方面没有显著贡献;FISCO
    BCOS
    是明确的并行计算多链设计,设计上要求开发者尽可能保持多链的同构特征以减少冲突,多链设计被直接应用在系统扩展方面;Coco
    的模式仍然取决于其集成的区块链协议;Quorum
    是单链模式的,底层的性能扩展要跟随以太坊的技术路线,可能要依赖以太坊的分片等技术进行扩展;Corda
    设计上是多网络模式,没有单多链的概念,但是可以建立两个网络节点的双向连接,配置双方信任的公正和认证机构进行网络融合,融合算是其扩展的一种方式。(四)加密算法扩展对于国内的应用,加密算法的扩展也即国密替换是一个强烈需求,尤其是在金融领域。Hyperledger
    Fabric
    不支持国密替换,目前已有的应用凡实现国密的基本上是自行替换或者依赖第三方服务;FISCO
    BCOS 是支持国密的;Coco 未对加密算法的选择有明确说明,因为这对 Coco
    而言属于底层,取决于其集成区块链协议,但目前它所集成的协议中还没有支持国密的;Quorum、Corda
    都没有对国密的支持方案。(五)第三方认证证书支持这一点对国内的应用也很重要。Hyperledger
    Fabric 目前不支持第三方 CA;FISCO BCOS
    支持第三方证书,支持证书的撤销,支持多CA;Coco
    由于私钥都保管在本地业务系统且允许自己生成,网络上只存公钥集,因此技术上看应该可以支持第三方
    CA;Quorum、Corda 都未见有此类支持。综上,Hyperledger Fabric
    在扩展性上有一定的限制; FISCO BCOS
    的可扩展性是很有优势的,尤其是面向国内应用时;Coco
    扩展性取决于其集成的协议;Quorum 的扩展性与以太坊关系密切;Corda
    除了在加密算法和第三方认证证书方面外,扩展的自由度有可能是最高的。五、节点管理与权限管理除了共识之外,联盟链与公链的显著区别当属在节点和权限上的设计了。本文从节点类型、作用、成员准入控制、角色和权限管理这几个方面比较下各联盟链之间的差异。(一)节点类型Hyperledger
    Fabric
    网络中的节点主要分为排序节点、背书节点和记账节点三类,实际应用中还可以加入只有同步账本能力的二级节点;FISCO
    BCOS 中包含核心节点、全节点、轻节点;Coco
    是一个可信验证节点(VN)分布式网络,也即,它只有一类节点就是 VN;Quorum
    中的节点是基于的以太坊 Golang
    版本实现的,因此节点之间是对等的,没有节点类型的区分,节点之间可以有白名单管理;Corda
    也不区分节点类型。(二)节点作用Hyperledger Fabric
    网络中背书节点负责提供签名服务,经背书节点签名且满足签名策略的交易提案会提交给排序节点进行交易排序和出块,再由记账节点完成账本更新;FISCO
    BCOS 中核心节点负责共识和记账,共识节点参与记账共识,
    观察节点同步账本;Coco、Quorum、Corda
    中节点都是对等的。(三)准入控制Hyperledger Fabric 中有专门的 CA
    模块提供用户信息注册、数字证书发行、延期和吊销等服务,成员管理采用 MSP
    方式,同一个组织内的成员通过共用同一个 MSP 标识进行识别;FISCO BCOS
    中,成员加入网络采用管理员认证的方式,提供合法有效的成员信息与CA证书,由管理员审核通过后,加入网络;Coco
    网络中的角色分为成员和参与者两种,成员是网络的集体管理者,拥有投票权,投票决定其他机构的加入或删除;Quorum
    网络中节点通过授权才能加入网络,授权是集中式的,通过 Java
    控制台操作;Corda
    中节点也是需要授权加入的,节点选择加入一个或多个网络地图,网络地图相当于网络成员及其地址列表,节点只能与所在地图中的成员进行交易。(四)角色Hyperledger
    Fabric
    中虽然成员没有明确的角色划分,但是基于其运维或对应的节点的差异会自然形成不同的角色;FISCO
    BCOS
    网络中的角色包含超级管理员、链或权限管理员、运维、交易、监管等;Coco
    网络中的角色分为成员和参与者两种,但不是必须同时具有两类参加者,也可以只有成员类型;Quorum
    网络中没有角色的区分;Corda
    网络中的角色分为公证人和参与者两种,公证人提供公证服务,参与者进行交易。(五)权限管理Hyperledger
    Fabric
    中权限主要通过策略进行管理,策略实际上是成员通过节点进行某种操作,比如提交交易提案等,所需要满足的签名数量要求。FISCO
    BCOS
    权限管理采用系统合约的方式,并可以通过自定义合约的方式进行权限管理功能的扩展,权限管理模型为
    ARPI(账户——角色——权限——接口)模式,多个账户可以对应同一个角色,角色有明确的权限列表,每个权限对应一个接口,接口指向智能合约,权限列表按照系统合约方式维护。业务中的权限管理则采用交易权限链的方式,一个交易相当于一组权限链,包含多个
    Filter,交易处理是逐个 Filter 进行权限判断,一个交易完成相当于一组
    Filter 审核都通过。Coco
    网络有成员负责治理,参与者是没有投票权的,不能参加网络管理。成员和参与者都可以拥有
    VN。成员对网络的管理通过共同维护一个可编程的网络章程来进行,章程内容至少包括成员列表、VN
    列表、代码清单、TEE 清单和投票策略。Quorum、Corda
    没有明显的权限管理内容。综合比较,FISCO BCOS
    的设计比较周全,也有一定的复杂性,但这也意味着它能够支持更复杂的场景;
    Hyperledger Fabric 、Coco 带有一定中心化因素;相较之下,Quorum、Corda
    更接近公链思路。带有中心化因素本就是联盟链对其应用的商业环境的体现,这也无可厚非。六、智能合约为了提升效率,支持更加友好的设计,各联盟链在智能合约上也出现了不同的发展思路。Hyperledger
    Fabric
    中的智能合约称为“链码”。链码分为系统链码和普通链码,前者包括生命周期管理、配置管理等,属于系统控制层面的链码;普通链码则是用于实现业务逻辑的链码,智能合约开发通常指的就是这部分链码。链码的业务模型为“MCV-B”,即,在传统的
    MVC(模型、控制器、视图)模式中嵌入
    B(区块链),强调链码是业务逻辑的加强。链码的生命周期包括打包、安装、实例化、升级、停止和启动,运行在
    Docker 中,由背书节点进行调用,目前主要支持的是 Go 语言。Hyperledger
    Fabric
    虽然提供了跨通道机制,允许跨通道调用链码,但是跨通道调用只支持读而不支持写。FISCO
    BCOS
    中除了通常用于业务逻辑的智能合约外,将系统管理也智能合约化了,统称为系统合约,包含系统代理、节点管理、机构证书、权限管理、全网配置五类。上述合约原则上由区块链管理员在网络启动时部署,网络运行期间的变更则需要在去全网所有节点许可的情况下由管理员操作。FISCO
    BCOS 主要支持 EVM 引擎的智能合约。Coco
    由于其节点运行在可信执行环境中,因此,与其他联盟链不同的是智能合约只需单个节点运行,不必多次验证。更与众不同的是,因为可以单点只运行一次,所以
    Coco
    的智能合约支持不确定交易。此外,允许智能合约直接连接外部可信数据源。Quorum
    是基于以太坊智能合约的,智能合约本身没有特别之处,合约运行结果方面,节点只对公开交易和节点涉及的私有交易进行验证,而不必验证所有交易。Corda
    的智能合约设计思路也比较独特,首先,它主张智能合约的业务数据和业务逻辑要能关联到明确的法律依据上,这相当于要智能合约跟业务凭证之间具有强联系;其次,Corda
    主张纯函数式设计,力推金融合约的标准化,提供小型类库,以减少对低层次逻辑的重新开发;再次,单纯看智能合约的话,Corda
    的智能合约是“碎片化”的小段程序,而且只能做为起流转控制作用的“验证程序”,做不到一般智能合约那种价值转移功能,在
    Corda
    中,“交易”、“智能合约”和“流式架构”加起来才能与其他平台的智能合约相当。总结一下,Hyperledger
    Fabric 的链码设计给了智能合约一个新的设计框架,这方面它是开创性的;FISCO
    BCOS 则将智能合约应用扩展到了系统管理方面;Coco
    采取了改变公链设计假定的思路,不仅不对智能合约进行重复验证,还支持不确定交易;Quorum
    的智能合约基本沿袭公链思路;Corda
    的思路也比较另类,但是智能合约本身却更弱化了。智能合约是随着以太坊火起来的,成了区块链的标志性技术,但其实目前的智能合约还远不够“智能”,这个名字容易引起误解。以太坊创始人
    Vitalik
    最近在推特上发文称对使用智能合约这个术语表示“十分遗憾”,应该使用更专业或更无聊的名字,比如,“持续的脚本”之类的东西,想来也有此意。七、部署与运维友好性联盟链常被称为是个“坑”,这个“坑”主要是在部署和运维方面。(一)部署Hyperledger
    Fabric
    虽然已经是个成熟框架了,有良好的社区环境,市面上还有若干不错的教材,但是部署方面依然让很多新人不知就里,笔者所在的微信群里大部分时间都在交流部署问题而非设计问题;FISCO
    BCOS提供一键安装/step-by-step/docker等搭链方式,同时还未企业生产部署提供物料包的打包工具,简化部署复杂度;Coco
    的部署特点是增加了一次对其他区块链协议的集成,要先有底层区块链协议,才能部署
    Coco,这其实要设计人员对 Coco
    和其集成的区块链协议都有一定了解才好,学习成本较大,此外,Coco 需要部署
    TEE 硬件设备来支持可信执行环境构建,这是其他联盟链通常不需要的,TEE
    因此也成为一个安全隐患;Quorum 需要在以太坊之上部署,依赖以太坊,与 Coco
    相同,设计人员最好也要了解以太坊;Corda
    的部署目前缺乏实例来做比较。(二)运维Fabric
    目前没有提供多少支持工具,多数需要设计者自己开发;FISCO BCOS
    提供了方便运维的合约命名服务,提供区块链浏览器和监控,并且有上帝模式用于处理节点崩溃问题,运维友好度有一定改善;Coco
    目前未见提供多少运维工具;Quorum 有一些第三方支持工具;Corda
    与其他联盟链相比,运维方面最大的特色莫过于支持受限形式的数据库回滚。联盟链的部署和运维都有一定的学习曲线,其复杂度远高于公链,一个新手部署一条以太坊要不了多少时间,但是运转起一个联盟链,还是需要打听不少“小伙伴”的。八、隐私保护联盟链有一个让大家纠结的问题是,明明要上链一起共建生态、共享信息,却纷纷要求隐私保护,要上链又不能随意公开,不仅希望身份保密,还希望交易信息保密,这与公链信息公开、身份保密的设计理念有很大不同,但这是合理要求,尤其是在金融领域。本文从可见范围、加密措施两方面对各链加以比较。(一)可见范围Hyperledger
    Fabric
    的通道可以用来隔离数据,只有在同一通道内的节点才可以共享同一套账本信息,而通过组织设计,基于
    MSP 标识可以在同一通道内进一步控制数据可见范围,1.2
    版中加入了私有数据模式,允许指定的节点间共享信息,这比组织更加灵活;FISCO
    BCOS 设计了 AMOP
    协议,以提供机构间的点对点通信,通信信息属于链下信息,不在全网共享,链上部分在引入中央对手方提供信用背书的情况下,数据也仅在交易方和中央对手方之间共享,多链方式也可用于数据隔离,必要时通过跨连互通;Coco
    支持两个或多个交易者的机密交易,通过 TEE
    控制可见性,但要求集成的区块链协议最好也提供一定支持;Quorum
    区分公开数据和私有数据,私有数据只允许限定的交易方可见;Corda
    数据仅在交易方之间可见,节点之间提供一个交易依赖关系图,数据根据需要发送,而不在全局广播,任何参与方都无法见到包含全部数据的全局账本。(二)加密措施Hyperledger
    Fabric 1.1 开始支持账本数据加密,1.2 版引入私有数据后,设计上允许只给
    Kafka 提供交易 Hash 用于排序而不向 Kafka
    提供交易信息,以防排序节点泄露数据;FISCO BCOS
    允许采用高强度的加密数据信封进行保护,未参与交易的机构只能接收到密文,此外,建议对敏感数据采用脱敏上链、Hash
    上链等方式进行保密处理;支持零知识证明,环签名,群签名,同态加密等隐私保护方法。Coco
    允许应用程序先进行数据加密再提交事务,公网数据采用加密传播的方式,以对不受信任的
    host 保密;Quorum 有独立的 Constellation
    模块,对私有事务的交易数据进行加密保护,还提供了独立的零知识证明(ZSL)模块以防止验证用户身份时发生信息泄露;Corda
    也使用 enclave
    进行数据保护,并考虑使用安全硬件。在隐私保护上,各链都下了很大力气,这方面与其一较短长,不如考虑互相借鉴。九、选型建议通过以上八个方面,本文粗略比较了五大联盟链的设计与差异,如果非要从技术角度给各家打个分、排个名,实在有些“霸王硬上弓”之嫌,各家原本思路和焦点就不同,都有自己的“小目标”,非要不管人家自己的想法去论个短长,有些不太“科学”,也不是应用的合理“姿势”。各联盟链毕竟都是为了解决实际问题、为了落地区块链项目而设计的,所以,本文最后从大家都会关心的技术选型角度做个总结。整体而言,Hyperledger
    Fabric
    的综合实力依然最强,推出时间早、框架完整且比较成熟,有国际化应用和国际化社区加持,案例和技术支持对于仍属早期发展阶段的区块链而言非常重要,Hyperledger
    Fabric
    在这方面可以说优势极大。但是,它也有些不能回避的问题,比如基础研发进展缓慢,研发主体不明确,一些应用者关心的关键问题迟迟不见解决。随着百度、阿里、腾讯、京东等一众国内大厂的强势加入,Hyperledger
    Fabric
    的优势地位也会受到越来越多的挑战,对此,它急需合适的应对措施。FISCO BCOS
    应该说是本土化设计的代表,其在底层研究上的投入、关键技术上的改进、对国内需要的适应性调整、对社区建设和运维的重视,都有可圈点之处,平台在各行业的通用性也在加强,随着开源工作的推进和案例的不断增加,其本土化优势会逐步显现。在国家政策的鼓励下,国内大厂如今纷纷高调杀入联盟链市场,如果这些大厂真的“倾情”加入,那与
    Hyperledger Fabric
    相较,其开发主体、资金投入的稳定性要更有优势,而且,大厂们基本自带生态和流量,案例的增长、生态的发展也是可以预期的,是很多项目可以借力之处。Coco、Quorum、Corda
    都存在支持能力不足、缺乏有效案例的问题,虽然微软目前在 Coco 以及其他基于
    Azure
    的区块链平台和应用上投入了一定力量,但是对国内应用者而言,仍显不足。因此,从技术选型角度来讲,应用者,尤其是新入局的应用者,最好还是在
    Hyperledger Fabric 这种影响广泛的成熟框架或者 FISCO BCOS
    这种有实力且能提供较强本土支持的平台上做选择,而在开发过程中借鉴下
    Coco、Quorum、Corda
    中的优秀设计理念。区块链仍属于技术的早期阶段,这个阶段必然要求应用者具备较强的学习能力,多做基础研究,敢于对所选择的技术平台进行改良,积极与平台提供商合作进行技术探索,区块链还没到像主流操作系统那样可以“坐享其成”的阶段,仍然需要所有参与者秉持“开源”思想,不辞辛苦、热情奉献、共同进步。作者按:文章大部分是晚上写的,是“夜话”;挑来选去,最后写了五个链,想起了“春秋”。春秋之后是战国,估计是随着
    BATJ
    积极加入后的战国。“天下大势,合久必分,分久必合”,联盟链乃至区块链会否如此,可能要“久”到下一代技术来决定了。近期有文章称当前的基础研究越来越难以支撑技术的创新发展了,区块链也有此忧虑。作为早期形态,刻意“浪费”算力和存储换取信任,可以;作为未来的成熟形态,不妥。五大联盟链中也有对此问题的些许思考,但现有方案乃是当下之技术或认知所能达到的较高水平了。今日“链人”之努力乃是前进的必经之路,足以启发天下之想象。没有今日的“痛苦”,就没有未来理想的区块链世界,愿大家广发宏愿,持续努力。作者介绍付晓岩,原中国建设银行资深业务架构师,负责业务架构设计、项目管理,热衷新技术探索与实践,具有丰富的银行业务经验和企业级项目业务架构设计经验。2000
    年加入建行,曾长期参加建行“新一代核心业务系统”建设,主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。从
    2017
    年开始探索区块链技术及其应用,并发表《关于使用区块链技术建设行业级同业交易平台的探讨》、《数字货币可能诱发的现金社会经济活动的模拟与思考》等多篇文章。

现实世界有许多的Key-Value数据库,它们都被广泛应用于很多系统。比如,我们能够用
Memcached数据库存储一个MySQL查询结果集给后续相同的查询使用,用MongoDB存储文档以得到更好的查询性能等等。针对不同的场景,我们应该选不同的Key-Value数据库,没有一个Key-Value数据库适用于所有解决方案,但是如果你仅仅想要一个简单、易于使用、快速、支持多种强大数据结构的Key-Value数据库,Redis可能是你作为开始的一个很好的选择。Redis是一个先进的Key-Value缓存和数据库,它基于BSD许可证。它的速度很快,支持许多数据类型,使用RDB或AOF持久化和复制来保证数据的安全性,并且支持多种语言的客户端库。最重要的是市场选择了Redis,有许多公司正在使用Redis并且它证明了自身的价值。虽然redis是相当不错的,它仍然有一些缺点,最大的缺点就是内存限制,Redis将所有数据驻留内存,这就限制了整个数据集的大小,让我们不可能保存更多的数据。官方的Redis集群通过将数据分发到多个Redis服务器来解决这个问题,但是这个方法并没有在许多实际环境中被证明。同时,它需要我们改变自己的客户端库来支持“MOVED”重定向和其它特殊命令,而这在正在运行的生产环境同样是不可接受的。所以,Redis集群现在看来并不是一个好的解决方案。QDB我们喜欢Redis,并且希望超越它的局限,因此我们创建了一个服务叫做QDB,它兼容Redis,将数据保存在磁盘来越过内存大小的限制并且将热点数据保存在内存中以提高性能。介绍QDB是一个类似Redis的快速Key-Value数据库,它有以下优点:兼容Redis:如果你对
Redis很熟悉,你就能轻松使用QDB,它支持大多数的Redis命令和数据结构;将数据保存在磁盘:可以将热点数据在内存中保存,利用了后端存储;支持多种后端存储:你可以选择
RocksDB、LevelDB 或者
GoLevelDB;和Redis双向同步:我们可以作为一个从节点从
Redis同步数据,也可以作为一个主节点复制数据到Redis。后端存储QDB使用LevelDB、RocksDB、GoLevelDB作为后端存储。这些存储都是基于有着很好的快速读写性能的日志结构的合并树,同时他们都使用布隆过滤器和LRU缓存来提高读的性能。LevelDB是由Google开发的最早的版本,RocksDB是由Facebook维护的一个优化版本,GoLevelDB是一个纯粹用GO语言实现的LevelDB。如果你仅仅想要一个快速试验并且不想构建和安装RocksDB或者LevelDB,你可以直接使用GoLevelDB,但是我们不推荐你将其使用在生产环境中,因为它的性能比较差。LevelDB和RocksDB对于你的生产环境来说都是非常不错的,但是鉴于RocksDB绝佳的性能,我们更喜欢RocksDB,之后我们将只支持RocksDB和GoLevelDB,一个用于生产环境,另一个用于试验和测试环境中。RebirnDBQDB是很棒的,我们能够在一个机器上存储巨大的数据,并且获得较好的读写性能,但是随着数据集的增长,我们仍然会面临这样的问题,即:我们不能将所有数据都保存在一个机器上。同时,QDB服务器将变成一个瓶颈并且面临单点失败的风险。现在我们必须要考虑集群解决方案了。介绍RebornDB是一个基于代理的分布式Redis集群解决方案。它有点像twemproxy,一个几乎是最早的、最著名的基于代理的Redis集群解决方案。但是twemproxy有它自己的问题,它仅仅支持静态的集群拓扑,因此我们不能动态的添加或者删除redis节点来重新切分数据。如果我们运行着许多的twemproxy并且希望添加一个Redis后端节点,另一个问题是如何让所有的twemproxy安全的更新配置,而这将增加IT操作的复杂性。同时,Twitter目前已经放弃并不再将其应用于生产环境。不同于twemproxy,RebornDB有一个杀手锏:动态的切分数据集,这将非常有用,特别是在你的数据集增长很快,你不得不增加更多的存储节点来扩展集群的情况下。总之,RebornDB将会透明的重新切分数据而不影响目前正在运行的服务。架构我们可以将RebornDB想象成一个黑盒,像一个单节点的Redis服务器一样用任何现有的Redis客户端去和它通信。下面的图片展示了RebornDB的架构。

实现概述

当前FISCO
BCOS对系统代理模块、节点管理模块、机构证书模块、权限管理模块、全网配置模块都做了对应的合约实现。合约源代码目录为systemcontractv2/。下面依次介绍各个合约实现的接口与逻辑。

国家队入场推进区块链底层公用基础设施建设

设计概述

FISCO
BCOS区块链为了满足准入控制、身份认证、配置管理、权限管理等需求,在网络启动之初,会部署一套功能强大、结构灵活且支持自定义扩展的智能合约,统称系统合约。

系统合约原则上由区块链管理员在网络启动之初部署全网生效。若是在网络运行期间重新部署变更升级,则需要在全网所有节点许可的情况下由区块链管理员来执行操作。

当前FISCO
BCOS系统合约主要有五个模块,系统代理模块、节点管理模块、机构证书模块、权限管理模块、全网配置模块。系统合约的模块可以根据需要自定义扩展,它既可以供区块链核心调用也可以对DAPP提供服务。每个模块由一个或多个智能合约来实现。模块结构图如下:

模块图

中国航空报讯:近日,由国家信息中心、中国银联、中国移动等发起的区块链服务网络发展联盟举办首届区块链服务网络合作伙伴大会,会上,微众银行作为首批12家合作伙伴之一参加了区块链服务网络发展联盟入盟仪式,并签署合作协议。

系统代理合约

SystemProxy.sol是系统代理模块的实现合约。它实现了路由到合约地址的命名服务,提供了系统合约的统一入口。内部实现中是通过mapping类型成员变量_routes来维护所有的路由表信息。路由表信息项的数据结构主要是:

struct SystemContract {
        address _addr;      #合约地址
        bool _cache;        #缓存标志位
        uint _blocknumber;  #生效区块高度
    }   

主要接口如下:

接口 输入参数 输出参数 说明
getRoute string key#路由名称 address, bool,uint # 合约地址,缓存标志位,生效区块高度 获取路由信息
setRoute string key, address addr, bool cache# 路由名称,合约地址,缓存标志位,生效区块高度 设置路由信息,若该路由名称已存在,则覆盖

在中国信通院2019年可信区块链评测名单上,FISCO
BCOS以100%通过率获颁功能测试、性能测试两项权威证明。在多个严苛性能测试的环境下,FISCO
BCOS单链TPS均达两万以上,且始终保持零错误运行。同时,FISCO
BCOS针对中国本土国情打造了完整国密算法体系,支持国密SM1、SM2、SM3、SM4等全部标准;构建了全套监管解决方案,实现穿透式监管,所有数据可监管、可审计、可追溯;
支持场景式隐私保护,其一站式隐私保护解决方案,提供全周期敏感数据隐私保障,且支持零知识证明和同态加密算法。

相关文章

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图