精华内容
下载资源
问答
  • Fabric 架构 总体架构核心部分由成员管理(Membership services)、共识服务(Consensus services)和智能合约(Chain-code Services)三部分, 加上安全和加密服务(Security and Crypto Services)贯穿于其他各个...
  • 参考《区块链技术 架构与发展》、《区块链以及区块链技术总结》、《区块链技术原理、应用领域及挑战》,对当下区块链系统架构进行细致梳理与补充,区块链技术入门友好。

    在这里插入图片描述

    区块链系统架构梳理 & Fabric应用开发流程

    一. 从数据库角度看

    传统的多方数据库在解决信任问题时存在繁琐的人工对账和争议,区块链(去中心化 不可篡改 多方共同维护的分布式数据库),在无第三方的情况下实现可信数据共享和p2p价值传输。

    1. 关系数据库管理系统、NoSQL数据库管理系统
      1. 单一机构管理和维护
      2. 全部数据的控制权由单一机构掌握
      3. 中心化无法解决信任问题,导致参与方需单独维护自己业务数据的数据库
      4. 各自维护数据库导致:信息孤岛,清结算需耗费大量人工对账成本
    2. 传统分布式数据库
      1. 节点之间需要是相互信任的(不作恶)
      2. ※共识层:使用CFT共识算法进行数据一致化。(决定了两者上层应用的差别)
    3. 区块链系统
      1. 将传统的信息孤岛数据库进行整合后,分布式的存储在多方共同维护的多个节点,参与方只能按照共识和规则进行更新,从而实现可信的多方信息共享。

    CFT类(Crash Fault Tolerance):是非拜占庭问题(指分布式的系统中存在故障,但不存在恶意节点的场景(即可能消息丢失或重复,但无错误消息)下的共识达成问题,是分布式共识领域最为常见的问题。)的容错技术。----解决算法:Paxos算法和Raft算法

    拜占庭将军问题:是对现实世界的模型化,由于硬件错误、网络拥塞或中断以及遭到恶意攻击等原因,计算机和网络可能出现不可预料的行为。

    二. 区块链系统的体系架构

    集成技术: P2P 协议、非对称加密、共识机制、块链结 构等多种技术
    在这里插入图片描述

    网络层:

    • ~平台通常选择完全分布式且可容忍单点故障的 P2P 协议作为网络传输协议

      早期P2P网络没有预定的全局模式不能适应网络变化而查询到完整的结果集

    • ~网络节点具有平等、自治、分布等特性,所有节点以扁平拓扑结构相互连通,不存在任何中心化的权威节点和层级结构,每个节点均拥有路由发现、广播交易、广播区块、发现新节点等功能

    • 通过P2P协议传输交易和区块数据,接收到广播的数据后验证:交易中的数字签名(和区块中的工作量证明)等

    共识层:

    共识算法的核心是在正常的节点间形成对网络状态的共识。

    • 公有链中,为解决节点自由进出带来的女巫攻击问题,BTC和ETH使用PoW共识机制,为了解决对能源的消耗,peercoin应用PoS、比特股(bitshares)应用股份授权证明机制(Delegated Proof of Stake,DPoS)

      女巫攻击(sybil attack):攻击者通过创建多个身份,从而在网络中获得与自身实体不对称的影响力或网络控制权。一种解决方法----采用一个信任的代理来认证实体,即可信第三方。

      • PoW机制的共识流程:新交易全网广播——“埋矿”——“挖矿”——全网广播新区块——验证交易与随机数的正确性。
        • 埋矿:收集前一区块生成后就收到的全部交易并计算出对应的Merkle根,将M根放入区块头并从0开始凑随机数,直至区块头的两次hash值≤难度目标设定值。
        • 挖矿:全网节点同时参与“计算”(凑数),先找到正确随机数的节点获得新区块的记账权及奖励(coinbase创世币与记账手续费)
    • 联盟链中,节点加入需要授权的HYF使用基于投票机制的共识PBFT算法

      • PBFT算法的共识流程:全网选举一个主节点(负责新区块的生成)——新交易全网广播——主节点收集新交易排序后存入列表——全网广播有序交易列表——每个节点依据排序模拟执行交易,完成后基于交易结果计算新区块的hash摘要(?块哈希?)——全网广播新区块哈希摘要——若一节点收到2f(f为可容忍恶意节点数)条摘要与自己相同则——全网广播一条commit消息——若有节点收到2f+1条commit消息——提交新区块及其交易到本地区块链和状态数据库

        • 去除不必要的能源和算力消耗更适合联盟链,算法可容忍恶意节点不超过全网节点的1/3。

        • 存在网络开销大的问题:N节点网络中,存在两个阶段需要传输的网络信息为O(N²),并造成很大的网络开销。

        • fabric1.0不能很好支持共识节点的动态加入与退出——基于插件化开发的BFT-SMART、SBFT和HoneyBadgerBFT等共识模块

          名称 特性
          BFT-SMART——强实用性、可靠性与模块化的BFT软件库 多核感知、节点动态进出可配置
          SBFT——主节点可靠前提下,构建类似Raft的消息模式 减少网络中的广播通信
          HoneyBadgerBFT——首个异步BFT协议 不依赖任何时间假设就可保证网络有效性,在广域网中也可容错

          SBFT取消了相互全网广播的信息确认方式,而是通过选举leader进行信息收集后统一分发验证。同时通过使用门限签名(threshold signatures)可以将消息长度从线性降低到常数。

    数据层(数据结构、数据模型、数据存储)

    1. 数据结构

      时间戳服务器:对新建文档、当前时间及指向之前文档签名的哈希指针进行签名,如此形成一个基于时间戳等数据。

      • Merkle根:基于块内交易数据哈希生产的Merkle根实现了块内交易数据的不可篡改性与简单支付验证。
        • ETH和HYF的块头含有:交易Merkle根和状态Merkle根,以太坊还有针对交易执行日志的收据Merkle根。BTC使用二叉Merkle树
        • ETH使用Merkle Patricia 树计算Merkle根(构建新区块时,仅需计算在新区块中变化的账户状态,未变分支直接引用)
        • HYF使用Merkle Bucket 树,Merkle Bucket 树是多叉树,每个叶子结点是一个桶,桶中存放的是Key-Value 类型的状态数据集。为新区块计算状态根时,没有变化的桶可以被跳过,因而可快速计算状态根。Merkle Bucket 树可通过调整桶数和分支数来控制树的深度和宽度,从而可在不同的性能和资源需求间权衡。
      • 链块结构:基于前一区块生成的前块哈希将孤立的区块链接在一起形成区块链。
        • 块哈希——对区块头中的前块哈希、随机数和Merkle根等数据进行两次哈希运算,基于块哈希可验证各块是否被修改过
        • 所有区块按照生成顺序以前块哈希为哈希指针链接在一起形成一条区块链表
    2. 数据模型

      • BTC——基于交易,每笔交易由表明交易来源的输入和表明交易取向的输出组成,所有交易通过输入与输出链接在一起,从而实现每笔交易都可以追溯。
      • ETH和HYF——基于账户,可基于账户快速查询到当前余额或状态。
    3. 数据存储

      • 既可以文件形式存储(便于日志形式的追加操作),也可以数据库形式存储(易实现查询与修改)。
      • 由于区块链系统中村在大量哈希计算,交易、区块都依靠哈希值进行标识,故底层数据库选择Key-Value数据库(如LevelDB)。
      • BTC、HYF区块链以文件形式存储,索引数据存储在LevelDB数据库,ETH则全部存储在LevelDB数据库。另ETH、HYF基于LevelDB构建了状态数据库用于存储账户余额或业务状态数据。
      • 在基于账户模型的区块链平台中,交易数据被打包进区块且经共识算法确认后,先追加如区块链,而后在写入区块链状态数据库。
      • 另外LevelDB数据库的架构方案无法满足企业级业务的高并发访问、Non-Key查询等业务需求,HYF提供了CouchDB插口。

    “智能”合约(Smart Contract)层

    • 智能合约是由算法和程序编写的,部署在区块链上且可按照规则自动执行的数字化协议,在预定条件满足时,能够自动强制执行合同条款。

    • 区块链的去中心化使得智能合约在没有中心管理者参与时,同时在全部节点上运行,无法被强行停止。

    • 智能合约作机制
      在这里插入图片描述

      • 外部应用通过调用智能合约来实现各种交易,若调用涉及修改操作,则需要先在全网达成共识,之后修改操作会被记录在区块链上,修改结果被存在状态数据库。
      • 调用仅是查询操作时,无需共识与记录上链。
      • 智能合约的支持合约内部事件的注册与通知机制,从而可主动向外部应用通知合约内部发生的关键事件
    • SC无法主动监听并相应链外数据,对于链外事件无法监听并响应。

    • SC定义了交易逻辑及访问状态数据的业务规则,外部应用需要调用合约,并依照合约执行交易和访问状态数据。——外部应用&智能合约≈数据库应用&存储过程:

      • 存储过程运行于数据库管理系统中,访问数据库数据
      • 合约运行于区块链系统中,访问区块和状态数据
    • SC需要运行在隔离的沙箱环境中,避免合约中存在漏洞或恶意代码威胁区块链节点的安全。——合约|宿主|合约|…之间被沙箱执行环境有效隔离、互补隔离

      平台 沙盒策略
      ETH 自定义以太坊虚拟机(EVM),使用Solidity等语言编译生成
      HYF 轻量级Docker容器,基于Docker自身的隔离性与安全性
    • 各平台智能合约使用情况:

      • BTC——比特币脚本,一组嵌在比特币交易上的指令

      • ETH——提供图灵完备的脚本语言Solidity、Serpent和沙盒环境 Ethereum Virtual Machine (EVM),以供用户编写和运行智能合约

        部署后的智能合约存放在区块链上,每次被调用时才被以太坊虚拟机(EVM)加载运行。

      • HYF——通过Go等语言编写Chaincode(智能合约),Docker容器作为沙盒环境,容器中带有一组经过签名的基础磁盘映像以及Go和Java语言运行时使用的SDK

        部署后合约被打包成Dovker镜像,每个节点基于镜像启动一个新的Docker容器并执行合约中的初始化方法,然后等待被调用。

    应用层

    • BTC——比特币交易
    • ETH——数字货币交易和Dapp由Javascript构建的Web前端应用,通过JSON-RPC与运行在以太坊节点上的智能合约进行通信。
    • HYF——通过Go、Java等语言的SDK构建应用,并通过gPRC或REST与运行在HYF节点上的智能合约进行通信。

    三. 其他特性

    可扩展性

    1. 横向扩展性:可使分布式数据库的整体性能随着集群节点数的增加而线性提升。

    2. 现有三大平台均采用全网节点共享一条链的单链方案,就该方案来说网络上每个节点都需要处理、存储全网的所有交易和数据,因此整个区块链系统的处理能力受限于单个计算节点的处理能力。并且考虑到共识机制,节点数的增加会进一步降低系统处理能力。

    3. 实现动态的可扩展性:

      系统实现单链扩展为多链,在多链上可同时并发的处理多笔交易,突破全网处理能力受限于单个节点,从而提升系统性能。

      • ETH——分片(sharding)——>>系统吞吐量和存储容量问题

        • 从ETH2.0开始以太坊依据账户地址将全网划分为多个相对独立的分片,每个分片内维护一条独立子链。
        • 用户可自行选择执行自己的交易的分片;
        • 节点可根据自身计算和存储能力选择加入(≥1)分片并处理和存储这些分片上的交易。
        • 全网节点分工配合以覆盖全部分片,节点通过轻客户端技术从其他分片节点读取本节点为存储的交易数据。
        • 由于采用分片技术导致的全网算力分散,单片内攻击者可轻易突破51%算力,所以PoW共识机制不再适用,改用基于权益证明机制的Casper共识算法。
      • HYF——多通道(multichannel)——>>系统扩展性与交易隐私性问题

        • 将区块链网络划分为多个逻辑上的通道,节点根据自身需要参加的交易加入相应的通道

        • 每个节点可以在多个链上同时接受和处理区块,多个链上的交易可以独立、并发地执行。相比单链,全网吞吐量显著提升。

        • Ordering服务节点提供插件化的共识服务,可基于Kafka消息系统或SBFT共识对所有链上的每个交易进行统一排序。

          当其由可信方或监管机构组成时,不涉及交易隐私问题;

          但希望对Ordering服务节点保密时,可利用加密来隐藏交易数据。

        • HYF采用的PBFT算法要求所有节点数目已知且静态不变,为此HYF1.0将节点分为共识节点(orderer)与记账节点(committer),解耦了共识服务和记账服务,从而实现记账节点的动态加入或退出。

    安全性

    1. 传统数据库——完善的用户管理和存取控制,用户管理需要在中心化节点上实现,而存取控制则使的数据非公开透明。
    2. 区块链——基于数字签名与验证以确保数字货币的所有权以及交易的可信与不可伪造,并通过在交易中使用不同的数字证书与账户地址以保证交易隐私性。
      1. 公有链:
        • 公钥作为用户的唯一标识
        • 签名与验证——使用椭圆曲线数字签名算法(ECDSA)
          • 接收者将比特币地址(pubKeyHash)提供给发送者——
          • 在ETH中,交易数据只包含发送者的ECDSA签名,接收者基于ECDSA签名、交易数据和椭圆曲线参数可以恢复出发送者的公钥,通过SHA3(公钥)可计算出发送者的账户地址。
      2. 联盟链
        • 所有节点与用户的加入需经过认证和授权
        • HYF提供成员管理服务——主要是基于CA中心提供ECert)、TCert和 TLSCert三种类型的数字证书
          • ECert (Enrollment Cert):身份认证,登录时确认节点或用户的身份
          • TCert(Transaction Cert):交易签名与验证,为避免第三方回溯交易发送者,每次交易可使用不同TCert证书
          • TLSCert(Transport Layer Security Cert):用于系统组件间的SSL/TLS通讯

    隐私性

    1. 公有链:
      • 一般通过将公钥地址与用户真实身份隔断,实现一定程度的匿名性
      • 每次使用新的地址,地址之间无关联,实现多个交易间的不可关联性
      • 缺陷
        • 钱包或交易所的认证
        • 同比交易中的多个输入间的关联关系
        • 网络报文中IP地址与比特币地址的对应关系
      • 现有隐私保护(掩盖交易细节、验证交易的正确性)方案
        • 混币(CoinJoin):多笔交易合一
        • 环签名(ring signature):用发送者私钥和多名无关者公钥加密交易数据,再用所有人的公钥解密,以隐藏发送者
        • 零知识证明(Zero-Knowledge Proof):在无需执行且无需知道输入的前提下,验证计算的正确性。(ETH)
        • (?)同态加密(homomorphic encryption)基于同态映射保证了先运算后加密与先加密后运算的结果相同,使得可基于加密数据实现交易验证。
        • HYF:通过节点之间可根据隐私需求建立专用通道(单链),通过将不同的交易分配到相互隔离的多条区块链上,实现私密交易,保障交易数据的隐私性。

    四. 区块链的优势、劣势及发展趋势

    优势

    1. 去中心化——全网数据由多方参与者共同管理维护,完全分布式的多方信息共享
    2. 不可篡改——哈希指针与Merkle树,少数节点非法篡改不影响全网共识结果
    3. 可追溯——区块链上存储自系统运行以来的全部交易数据(不可篡改的日志类型数据),便于还原与追溯历史操作,便于监管机构的审计与监督
    4. (?)高可信——交易可信任,参与者在区块链系统中无需可信第三方就可以完成交易,交易通过数字签名、全网共识的方式实现可信(无篡改、不可否认)。
    5. 高可用——相比传统分布式数据库的主备模式,~系统中无主备节点之分,所有节点都是一个异地多活节点,少部分节点故障不影响系统运行。

    劣势:

    1. 吞吐量:BTC-7TPS \ ETH-25TPS \ HYF-2000TPS,牺牲性能换系统安全。每笔交易的签名验证、每个区块的哈希运算以及共识过程等都涉及大量的系统开销。
    2. 事务处理:依赖底层数据库提供事务处理,而KV数据库无事务处理能力。
      • LevelDB不支持严格的事务,单个节点上的智能合约执行失败会导致数据库数据不一致,需从其他节点同步数据实现数据一致。
    3. 并发处理?
    4. 查询统计:KV数据库在Non-Key查询和历史数据查询上不方便,更难以实现复合查询与统计。
      • 实现插件化的数据访问机制,以支持包括关系数据库在内的多种数据库。(HYF支持CouchDB可以根据不同应用场景实现复杂查询)
    5. (?)访问控制:公有链公开透明地将全量数据存储在每个节点,仅依靠交易的签名与验证去确定资产的所有权和保证交易的不可伪造。
    6. 可扩展性:与传统数据库相反,当前区块链系统的性能(吞吐量、并发访问量和存储容量)会随着节点增加而下降。

    五. 发展趋势

    1. 共识机制:提高系统吞吐率的共识机制

    2. 隐私保护:能够隐藏交易内容的零知识证明(应用领域受限)与同态加密(计算效率底)方案。

    3. 部分存储:部分存储取代全量存储模式,提升系统性能与隐私性。(HYF、ETH、Corda)

    4. 链外交易:雷电网络(ETH)、闪电网络(BTC)将小额高频的交易放在链外,提高交易速度,主链只处理最终的交易及作为争议仲裁的最后手段。

    5. 多链与侧链:多链使互不相关的交易实现分片存储和并发执行,提高系统扩展性,链间隔离提升隐私性。侧链通过与主链互相锚定,实现对主链的功能扩展。(元素链)

    6. 跨链:实现不同区块链平台之间的链条之间的互联互通互信。(Polkadot——通用的跨链通信、Cosmos——跨链的数字资产交易)

      • Polkadot以ETH为主实现与各平行链的互连,实现以太坊直接与任何链进行通讯。
      • Cosmos通过在主干网络Cosmos Hub上运行的IBC(Inter-Blockchain Communication)协议实现不同区块链子网之间的互联
    7. 区块树与区块图:采用树(ETH)和图来组织区块,以节点权重计算最长链作为主链。

    8. SQL on Blockchain:现有的数据分析工具基本基于SQL构建,区块链数据分析需要基于SQL的查询引擎,便于现有数据分析工具可接入

    9. BlockchainDB:从底层到上层都直接支持现有区块链特性的数据库。其设想的架构参照图在这里插入图片描述

      • 网络层基于P2P协议,便于实现各种节点的动态加入与退出,从网络底层支持去中心化的架构

      • 共识层上支持具有拜占庭容错的共识算法,以支持公有链、联盟链的不同应用场景,其应该既提供证明机制,又支持投票机制。

      • 数据层为了便于存储和检索,BlockchainDB在数据层上可直接借鉴现有数据库的存储与索引技术处理区块链中的状态数据与索引数据。

        区块数据和传统数据库的预写式日志非常类似,它们都维护了所有的历史操作记录,都是在表数据之前写入,都是追加形式的写且支持数据重放,只不过预写日志不具备不可篡改性且不支持查询,但预写日志在高速写入方面的研究可用于区块数据。另外,区块中的交易 数据具有可追溯的特性,但不论在基于交易还是基于账户的模型中,目前的追溯查询并不高效,因此可借鉴数据仓库和科学数据管理领域的数据溯源(data provenance)来解决,数据溯源的查询表达具有严格的代数学基础,且可在关系数据库上实现。

      • 智能合约层:借鉴存储过程和触发器的设计经验,实现类似 PL/SQL 或 TSQL 编写的智 能合约。

      • 应用层原生支持SQL,提供支持访问区块数据、交易数据、状态数据的SQL语句,使应用程序获得与访问传统数据库相同的接口。

    六. Fabric应用开发流程

    开发范围

    1. chaincode:搭建Fabric网络,在此之上开发chaincode
    2. application:基于SDK进行业务应用开发,与Fabric网络进行业务连接,应用通过Fabric-CA签发证书
    3. chaincode接口:core/chaincode/shim/interfaces.go

    开发步骤

    1. 确定应用场景:

      • 节点
      • 功能(节点间交互)
      • 网络连接方式
    2. 数据的生命周期

      ​ 以票据为例:发行票据-票据状态1.0-购买交易-票据状态2.0-兑现交易-票据状态3.0…

    3. 数据结构——根据业务需求设计对应的value结构,根据查询需求实际key值的前缀。

    在这里插入图片描述

    1. Chaincode

    2. Application——确定应用如何通过SDK与Chaincode交互

    3. 其他:Chaincode namespace、Endorsement policies、Connection Profile、Identities等

    展开全文
  • Fabric区块链架构说明

    2019-08-06 14:55:12
    目录 ...2. 区块链系统架构................................. 4 3. 核心概念与组件................................. 7 3.1. 网络层相关组件........................... 8 3.2. 共识机制......

    目录

    1. 区块链核心特性................................. 3

    2. 区块链系统架构................................. 4

    3. 核心概念与组件................................. 7

    3.1. 网络层相关组件........................... 8

    3.2. 共识机制................................ 11

    3.3. 权限管理................................ 12

    1. 区块链核心特性

    区块链核心特性有如下:

    1. 解耦了原子排序环节与其他复杂处理环节,消除了网络处理瓶颈,提高可扩展性;
    2. 解耦交易处理节点的逻辑角色为背书节点、确认节点,排序节点,CA节点,可以根据负载进行灵活部署;
    3. 支持身份证书管理服务,有单独的区块链CA中心服务,提供更多证书功能;
    4. 支持多通道特性,不同通道之间的数据彼此隔离,提高隔离安全性;
    5. 支持可拔插的架构,包括共识、权限管理、加解密、账本机制都模块,支持多种类型;
    6. 支持系统链码管理应用链码的区块链系统的处理,并且支持可编程和第三方实现。
    1. 区块链系统架构

    区块链整体架构

    区块链为应用提供了gRPC API,以及封装API的SDK供应用调用。应用可以通过SDK访问区块链网络中的多种资源,包括账本、交易、链码、事件、权限管理等。应用开发者只需要跟这些资源打交道即可,无需关心如何实现。其中,账本是最核心的结构,记录应用信息,应用则通过发起交易来向账本中记录数据。交易执行的逻辑通过链码来承载。整个网络运行中发生的事件可以被应用访问,以触发外部流程甚至其他系统。权限管理则负责整个过程中的访问控制。账本和交易进一步地依赖核心的区块链结构、数据库、共识机制等技术;链码则依赖容器、状态机等技术;权限管理利用了已有的PKI体系、数字证书、加解密算法等诸多安全技术。底层由多个节点组成P2P网络,通过gRPC通道进行交互,利用Gossip协议进行同步。

    层次化结构提高了架构的可扩展和可插拔性,方便开发者以模块为单位进行开发。

    区块链根据交易过程中不同环节的功能,在逻辑上将节点角色解耦为背书节点(Endorser)和确认节点(Committer)、排序节点(Orderer),让不同类型节点可以关注处理不同类型的工作负载。区块链的交易处理过程如下图所示。

    区块链的交易处理过程

    在整个交易过程中,各个组件的功能主要为:

    客户端(App):客户端应用使用SDK接口与区块链网络打交道。首先,客户端从CA节点获取合法的身份证书来加入到网络内的应用通道。发起正式交易前,需要先构造交易提案(Proposal)提交给背书节点(Endorser)进行背书;客户端收集到足够(背书策略决定)的背书支持后可以利用背书构造一个合法的交易请求,发给排序节点(Orderer)进行排序处理。客户端还可以通过事件机制来监听网络中消息,来获知交易是否被成功接收。

    背书节点(Endorser):完成对交易提案的背书(目前主要是签名)处理。收到来自客户端的交易提案后,首先进行合法性和权限检查,检查通过则模拟运行交易,对交易导致的状态变化(以读写集形式记录,包括所读状态的键和版本,所写状态的键值)进行背书并返回结果给客户端。注意网络中可以只有部分节点担任背书节点(Endorser)角色。

    确认节点(Committer):负责维护区块链和账本结构(包括状态数据库、历史数据库、索引数据库等)。该节点会定期地从排序节点(Orderer)获取排序后的批量交易区块结构,对这些交易进行写入账本前的最终检查(包括交易消息结构、签名完整性、是否重复、读写集合版本是否匹配等)。检查通过后执行合法的交易,将结果写入账本,同时构造新的区块,更新区块中记录交易是否合法等信息。同一个物理节点可以仅作为确认节点(Committer)角色运行,也可以同时担任背书节点(Endorser)和确认节点(Committer)这两种角色。

    排序节点(Orderer):仅负责排序。为网络中所有合法交易进行全局排序,并将一批排序后的交易组合生成区块结构。排序节点(Orderer)一般不需要跟账本和交易内容直接打交道。

    CA节点:负责网络中所有证书的管理(分发、撤销等),实现标准的PKI架构。主要代码在单独的区块链CA中心项目中。CA节点在签发证书后,自身不参与到网络中的交易过程。

    1. 核心概念与组件

    区块链采用了模块化功能设计,整体的功能模块结构如下图所示:

    区块链核心组件

    区块链面向不同的开发人员提供了不同层面的功能,自下而上可以分为三层:

    1. 网络层:面向系统管理人员。实现P2P网络,提供底层构建区块链网络的基本能力,包括代表不同角色的节点和服务;
    2. 共识机制和权限管理:面向联盟和组织的管理人员。基于网络层的连通,实现共识机制和权限管理,提供分布式账本的基础;
    3. 业务层:面向业务应用开发人员。基于分布式账本,支持链码、交易等跟业务相关的功能模块,提供更高一层的应用开发支持。

    下面介绍网络层相关组件的功能和作用。

      1. 网络层相关组件

    网络层通过软、硬件设备,实现了对分布式账本结构的连通支持,包括节点、排序者、客户端等参与角色,还包括成员身份管理、Gossip协议等支持组件。

    节点(Peer)的概念最早来自P2P分布式网络,意味着在网络中担任一定职能的服务或软件。节点功能可能是对等一致的,也可能是分工合作的。在区块链网络中,节点(Peer)意味着在网络中负责接受交易请求、维护一致账本的各个节点实例。这些实例可能运行在裸机、虚拟机甚至容器中。节点之间彼此通过gRPC消息进行通信。按照功能角色划分,节点(Peer)可以包括两种类型:

    背书节点(Endorser):负责对来自客户端的交易提案进行检查和背书;

    确认节点(Committer):负责检查交易请求,执行交易并维护区块链和账本结构;

    这些角色是功能上的划分,彼此并不相互排斥。一般情况下,网络中所有节点都具备确认(Committer)功能;部分节点具有背书(Endorser)功能。

    排序节点(Orderer),负责对所收到的交易在网络中进行全局排序,维持了一个gRPC的双向通道。排序节点(Orderer)可以支持多通道。不同通道之间彼此隔离,通道内交易相关信息将仅发往加入到通道内的节点,从而提高隐私性和安全性。在目前的设计中,所有的交易信息都会从排序节点(Orderer)经过,因此,排序节点(Orderer)在网络中必须处于可靠、可信的地位。

    从功能上看,排序节点(Orderer)的目的是对网络中的交易分配全局唯一的序号,实际上并不需要交易相关的具体数据内容。因此为了进一步提高隐私性,发往排序节点(Orderer)的可以不是完整的交易数据,而是部分信息,比如交易加密处理后的结果,或者仅仅是交易的Hash值、Id信息等。这些改进设计会降低对排序节点(Orderer)可靠性和安全性的需求。

    客户端是用户和应用跟区块链网络打交道的桥梁。客户端主要包括两大职能:

    1. 操作区块链网络:包括更新网络配置、启停节点等;
    2. 操作运行在网络中的链码:包括安装、实例化、发起交易调用链码等。

    这些操作需要跟节点和排序节点打交道。特别是链码实例化、交易等涉及到共识的操作,需要跟排序节点交互。网络中的节点和排序节点等节点则对应提供了gRPC远程服务访问接口,供客户端进行调用。

    CA节点负责对区块链网络中的成员身份进行管理。区块链网络目前采用数字证书机制来实现对身份的鉴别和权限控制,CA节点则实现了PKI服务,主要负责对身份证书进行管理,包括生成、撤销等。需要注意的是,CA节点可以提前签发身份证书,发送给对应的成员实体,这些实体在部署证书后即可访问网络中的各项资源。后续访问过程中,实体无须再次向CA节点进行请求。因此,CA节点的处理过程跟网络中交易的处理过程是完全解耦开的,不会造成性能瓶颈。

    区块链网络中的节点之间通过Gossip协议来进行状态同步和数据分发。Gossip协议是P2P领域的常见协议,用于进行网络内多个节点之间的数据分发或信息交换。由于其设计简单,容易实现,同时容错性比较高,而被广泛应用到了许多分布式系统。Gossip协议的基本思想十分简单,数据发送方从网络中随机选取若干节点,将数据发送过去;接收方重复这一过程(往往只选择发送方之外节点进行传播)。这一过程持续下去,网络中所有节点最终(时间复杂度为节点总个数的对数)都会达到一致。数据传输的方向可以是发送方发送或获取方拉取。

    在区块链网络中,节点会定期地利用Gossip协议发送它看到的账本的最新的数据,并对发送消息进行签名认证。通过使用该协议,主要实现如下功能:

    1. 通道内成员的探测:新加入通道的节点可以获知其他节点的信息,并发送信息宣布在线;离线节点经过一段时间后可以被其他节点感知。
    2. 节点之间同步数据:多个节点之间彼此同步数据,保持一致性。另外,Leader节点从排序节点拉取区块数据后,也可以通过Gossip传播给通道内其他、节点,Leader节点是某一组织里负责与排序节点交互的节点。
      1. 共识机制

    区块链共识的过程如下:

    第一步,客户端Client构造交易提案

    客户端利用SDK接口构造一个交易提案,该交易提案包含调用智能合约功能函数请求,用来确认哪些数据可以读取或者写入账本,客户端将交易提案发送给一个或多个节点,交易提案包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等。

    SDK将交易提案打包为可识别的格式,并使用用户的加密凭证为该交易提案生成唯一的签名。

    第二步,背书节点模拟执行交易

    背书节点收到交易提案后,验证签名并确定提交者是否有权执行操作。背书节点将交易提案的参数作为输入,在当前状态KV数据库上执行交易,生成包含执行返回值、读操作集合和写操作集合的交易结果(此时不会更新账本),这些值的集合、背书节点的签名和背书结果(YES / NO)作为提案的结果返回给客户端SDK,SDK解析这些信息判断是否应用于后续的交易。

    第三步,客户端把交易发送到共识服务节点

    应用程序(SDK)验证背书节点签名,并比较各节点返回的提案结果,判断提案结果是否一致以及是否参照指定的背书策略执行。客户端收到各个背书节点的应答后,打包到一起组成一个交易并签名,发送给排序节点。

    第四步,排序节点共识排序,生成新区块,提交交易

    排序节点对接收到的交易进行共识排序,然后按照区块生成策略,将一批交易打包到一起,生成新的区块,调用投递消息,发送给确认节点。

    确认节点收到区块后,会对区块中的每笔交易进行校验,检查交易依赖的输入输出是否符合当前区块链的状态,完成后将区块追加到本地的区块链,并修改K-V状态数据库。

      1. 权限管理

    成员必须被许可才能加入网络,通过证书,加密,签名等手段保证安全。通过多通道功能,保证只有参与交易的节点能访问到数据,其他的节点看不到。满足数据保护方面的法律法规要求。

     

     

    展开全文
  • Fabric区块链架构分析

    2020-05-24 16:29:24
    Fabric是一种开源区块链实现,部署环境可以是私有服务器,也可以直接部署在公有云上,部署方式可传统可docker化,共识算法插件化,支持用Go和JavaScript开发智能合约,尤以企业级的安全机制和CA机制为特色。Fabric之...

    Fabric是一种开源区块链实现,部署环境可以是私有服务器,也可以直接部署在公有云上,部署方式可传统可docker化,共识算法插件化,支持用Go和JavaScript开发智能合约,尤以企业级的安全机制和CA机制为特色。Fabric之于区块链,很可能正如Hadoop之于大数据。经过在Hyperledger超级账本将近一年的孵化,社区计划在3月发布1.0的预览版本。本文将重点对Fabric 1.0(alpha&beta)的重点架构升级 - 1)账本 2)数据库 整体的设计思路进行一些介绍。

    一、设计目标

     

    总体的思路是1)提升性能 2)提升可拓展性 3)提供更丰富的查询功能 4)更多模块的可插拔

     

    二、账本的组成

     

    最大的不同是增加了对基于文件系统的区块链账本的支持,可以更好地支持不可篡改的特性。

     

    三、完整交易步骤

     

    鉴于Consenter部分还没完全完工,从目前的交易执行过程来看,对节点角色的功能拆分,解决了Fabric0.6的拓展性问题。

     

    四、交易流程图

    五、传递的消息结构

    六、使用智能合约数据的方式

     

    依托可插拔特性引入的CouchDB数据库,提供了基于JSON数据格式的多种数据查询能力,丰富了合约代码可以实现的功能。

     

    未完待续,下一部分更新数据库的具体改变。

    最后,为了实现Fabric V1.0 的设计目标,依然有大量Todo工作需要广大技术人士支持,感兴趣的可关注如下JIRA未关闭问题,对代码进行开源贡献。

    展开全文
  • 区块链hyperledger fabric架构详解

    千次阅读 2018-08-20 14:26:46
    hyperledger fabric区块链中联盟链的优秀实现,主要代码由IBM、Intel、各大银行等贡献,目前v1.1版的kafka共识方式可达到1000/s次的吞吐量。本文中我们依次讨论:区块链的共通特性、fabric核心概念、fabric的交易...

    hyperledger fabric是区块链中联盟链的优秀实现,主要代码由IBM、Intel、各大银行等贡献,目前v1.1版的kafka共识方式可达到1000/s次的吞吐量。本文中我们依次讨论:区块链的共通特性、fabric核心概念、fabric的交易执行流程。本文来源于笔者欲对公司部分业务上链而进行培训的PPT,故图多文字少,不要怕太长。

    1、区块链解决方案的特性

    1.1 分布式帐本

    区块链核心概念是分布式帐本,就像下面的图1所示,同样的帐本(全量的交易数据,详见下节)在任意一台节点(不包括客户端)上都有。所以,其优点是数据很难造假,造假后也可以通过追溯记录来追究法律责任。而缺点就是极大的浪费,传统服务每份数据都尽量少存几份,即使存了三份拷贝都已经考虑到诸多异常,并使服务可用性达到N个9了。而区块链这种特性,同时造成的另一个问题是帐本不能太大,至少不能超过区块链网络中最小结点的存储以及处理能力。所以,这制约了总交易数据(下文为方便概念介绍,统称为帐本ledger)的条数,进而也影响了能写入区块链的单条交易数据的大小。

    图1 区块链分布式帐本示意图

    什么是区块链呢?我很喜欢《区块链技术进阶与实战》一书中对它的定义:区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构。如果觉得有点抽象,那么我们再来看看下面的图2。

    图2-区块链数据结构示意

    图2中就是账本,它由多个区块构成了一个有时序的链表,而每个区块里含有多条交易trasaction(缩写为tx)构成的链表。图2下方有一个WorldState世界状态,这其实是为了提升性能用的。比如,key1共交易了10000次,为了获取它的当前状态值,需要正向执行这10000次交易,这就得不偿失了。如果这1万次交易里,每次新交易执行完,都同步更新一个数据库(在fabric里用的是levelDB),这样查询当前状态时,只需要查询该数据库即可,如图3所示。

    图3-fabric levelDB状态数据库

    图3中,区块链帐本是在FileSystem文件系统中保存的,而Level DB存放世界状态。

    1.2 智能合约smart contract

    区块链的发展过程中,一般1.0时代就是数字货币时代,代表是比特币,而2.0时代就是智能合约(现在是3.0时代,各种联盟链即为代表)。

    智能合约是运行在区块链上的模块化、可重用的自动执行脚本,有了它我们就可以完成复杂的业务逻辑,例如同一个区块链上有多份合约,而每份合约可以约定不同的参与者(企业或者相关方)。也可以指定每份合约里每个子命令做一批特定的事,大家可以把它想象成关系数据库里的事务。如图4所示,我们可以在合约里指定允许哪些企业的节点可以参与到交易流程中来(在fabric里这叫共识策略)。

    图4-智能合约图示

    在fabric中,智能合约叫做chaincode,它有6个状态,如下所示:

    • Install → Instantiate → invocable → Upgrade → Deinstantiate → Uninstall.

    实际上智能合约就是一段代码,fabric官方认可的是GO语言。首先我们需要把合约代码上传到区块链上,这一步的状态就叫Install。

    接着,需要做初始化操作。比如,现在的数据是存放在mysql中的,那么上线时需要用Instantiate把数据迁移至链上,这也算初始化。初始化后,chaincode就进入invocable可调用状态了。

    通用我们可以通过CLI命令行或者程序里用SDK调用合约(v1.1前还有RestApi调用,现已放弃)。

    联盟链由于跨多家企业、多个地区甚至国家,很难使得合约保持一致的版本,因此,每个合约都有版本号。而版本升级时,就是Upgrade状态。

    最后两个状态对应着合约下链。

    智能合约可以在供应链等较复杂的业务场景下起到很大的作用,如下面的图5所示:

    图5-智能合约技术的应用示意

    1.3 数据一致性(共识算法)

    既然区块链是一个去中心化的分布式系统,那么自然只能通过投票来决定一致性了:少数服从多数。当然,多少算多数呢?不同的共识算法下,结果并不相同。比如paxos算法(参见笔者的《paxos算法如何容错的–讲述五虎将的实践》)就是超过一半,而PBFT则需要三分之二以上。

    这里有一个拜占庭将军问题需要注意,如何理解该问题可以参见这份翻译过的The_Part-Time_Parliament(Paxos算法中文翻译)文档。简言之,就是投票的拜占庭将军(服务器)们有2种不可靠的形式。第一是迟钝(数据包延迟)、失忆(数据包丢失以及数据包重发)、失踪(服务器宕机)等不含背叛的行为,第二则是有将军是间谍(服务器被攻破)。如paxos这样的算法属于第一种,Fault-tolerance,它不能容忍服务器上有恶意代码;而如PBFT(Practical Byzantine Fault Tolerance)这样的算法是第二类,Byzantine-Fault-tolerance,它能够容忍一定数量的拜占庭将军节点存在,如PBFT、SBFT、RBFT算法等。

    第二类Byzantine-Fault-tolerance共识算法虽然看上去很美,但并不成熟,特别是性能低下,比如PBFT是一个多项式复杂度的算法O(N^2),节点过多时(大于100)性能急骤下降。第一类通常是O(N)复杂度,在某些场景下使用效果还不错,比如fabric v1.1的kafka共识机制就是这样的算法,下文我们会详述。

    像比特币、以太坊等采用的共识算法又有所不同,例如比特币的POW工作量证明算法,它定义一小时内(通过调整运算难度实现,比如调整近似程度)有一个lucky node节点,该节点是通过证明自身的努力(hash值逆解)而幸运选出,选出后它就可以为这段时间的交易做决定(似乎挺像总统选举^_^)。详情参见我这篇文章:《区块链技术学习笔记》

    1.4 非对称加密

    区块链通过非对称加密技术实现身份验证与数据加密。其实就是我们日常在用的SSL技术。

    为了方便理解,我们需要先介绍PKI(Public Key Infrastructure),它是一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。有一个CA(Certificate Authority)权威机构负责向用户(包括服务提供者与使用者)提供数字证书,包括公钥与私钥,同时CA机构还需要提供一个CRL(Certificate Revocation List)证书吊销列表,如下面的图6所示。

    图6-CA机构颁发数字证书以及提供CAL

    这样,区块链可以通过PKI体系实现安全认证。PKI有三个关键点,我们下面详述。

    1.4.1 数字证书 Digital Certificate

    比如Mary Morris符合X.509规范的数字证书里,其Subject属性里就含有她的信息,包括国家C=US、所属的州或者省份ST=Michigan、所在城市L=Detroit、所属单位O=Mitchesll Cars、其他信息OU=Manufacturing、公用信息CN=Mary Morris/UID=123456等,也含有其他信息,如下面的图7所示。

    图7-PKI数字证书

    1.4.2 公钥与私钥

    CA颁发了两个证书:公钥与私钥,其中,私钥仅服务提供者保存,而公钥则可被所有人(服务使用者)保存。

    所谓非对称加密,就是公钥加密的消息仅私钥可以解密;同理,私钥加密的消息,仅公钥可以解密。对应于前者,可以实现客户端访问服务器时加密消息,例如访问安全级别高的页面时提交的表单信息都需要用公钥加密,确保只有服务器才能解密网络报文。对应于后者,则可实现签名功能,如下面的图8所示。

    图8-PKI中私钥签名后用公钥验签名

    图8中Mary Morris用私钥对一段信息的内容(若内容过大则可先HASH后获得小点的字符串)加密后,生成签名附加在消息中。接收者可从CA机构获取到公钥,用公钥解密签名后,再与内容比对,以确定消息是否来自MaryMorris及内容是否被篡改。对于文件来说也是一样,小文件直接加密,大文件先生成hash再对hash加密,如下面的图9所示。

     

    图9-对文件的签名

    1.4.3 证书信任链

    CA证书分为两类:RCA(Root CA)根证书以及ICA(Intermediate CA)中间证书。这些证书由RCA开始构成一个证书信任链,如下面的图10所示。

    图10-CA证书信任链条

    有许多CA证书权威机构,各自有其RCA。如果RCA得不到信任,那么其下的ICA也无法认证通过。

    当然,自己的服务器也可以生成RCA。

    在Fabric里,允许不同的企业使用不同的RCA,也可以使用相同的RCA和不同的ICA。这与下文中的MSP密切相关。

    1.5 小结

    我们来总结下区块链,它主要是为了解决社会上的信任问题而存在的,为此,它付出了沉重的性能、可用性代价。它怎么做到的呢?通过4点实现:1、数据到处存放;2、操作记录不可更改;3、传输数据可信;4、业务脚本约束。

    那么,这个信任问题的解决,带来了2个非功能性的约束:数据一致性和可用性。其中可用性包括两点:1、交易在可接受的时间内达成。比如比特币的分叉就会造成严重问题。2、吞吐量达标。而比特币每秒只能有7次交易,这显然太低了。

    2、fabric核心概念

    hyperledger fabric符合上面说过的区块链的所有特性。我们必须先了解它的一些概念,才能进一步理解其架构设计。由于英文资料居多,所以这些概念我都以英文描述为准:

    • chaincode:智能合约,上文已提到。每个chaincode可提供多个不同的调用命令。
    • transaction:交易,每条指令都是一次交易。
    • world state:对同一个key的多次交易形成的最终value,就是世界状态。
    • endorse:背书。金融上的意义为:指持票人为将票据权利转让给他人或者将一定的票据权利授予他人行使,而在票据背面或者粘单上记载有关事项并签章的行为。通常我们引申为对某个事情负责。在我们的共识机制的投票环节里,背书意味着参与投票。
    • endorsement policy:背书策略。由智能合约chaincode选择哪些peer节点参与到背书环节来。
    • peer:存放区块链数据的结点,同时还有endorse和commit功能。
    • channel:私有的子网络,事实上是为了隔离不同的应用,一个channel可含有一批chaincode。
    • PKI:Public Key Infrastructure,一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。
    • MSP:Membership Service Provider,联盟链成员的证书管理,它定义了哪些RCA以及ICA在链里是可信任的,包括定义了channel上的合作者。
    • org:orginazation,管理一系列合作企业的组织。

    2.1 开发概念

    fabric联盟链的开发人员主要分为三类:底层是系统运维,负责系统的部署与维护;其次是组织管理人员,负责证书、MSP权限管理、共识机制等;最后是业务开发人员,他们负责编写chaincode、创建维护channel、执行transaction交易等,如下面的图11所示。

    图11-fabric技术人员的分层

    fabric大致分为底层的网络层、权限管理模块、区块链应用模块,通过SDK和CLI对应用开发者提供服务,如下面的图12所示。

    图12-fabric开发模块图

    我们的开发流程主要包括写智能合约,以及通过SDK调用智能合约,及订阅各类事件,如图13所示。

    图13-开发环节

    2.2 MSP

    每个管理协作企业的ORG组织都可以拥有自己的MSP。如下图14所示,组织ORG1拥有的MSP叫ORG1.MSP,而组织ORG2业务复杂,所以维护了3个MSP。

    图14-ORG可管理自己的MSP

    MSP出现在两个地方:在channel上有一个全局的MSP,而每个peer、orderer、client等角色上都维护有本地的局部MSP,如图15所示。

    图15-在channel上的Global MSP以及在参与角色上的Local MSP

    本地MSP只保存有Global MSP上的子集,内容保存在本地文件系统上,而全局MSP可在逻辑上认为是配置在系统上的,它实际也在每个参与者上保存一份拷贝,但会维持一致性。

    MSP也分级,如图16中所示,底层的network MSP负责网络层的准入,其MSP由ORG1拥有,而上面的某个channel的MSP则由ORG1和ORG2共同管理。

    图16-MSP是分级的

    一个MSP下含有以下结构,如图17所示。

    图17-MSP结构

    可见,MSP结构包括:

    • RCA根证书
    • ICA中间证书
    • OU组织单位
    • 管理员证书
    • RCL吊销证书列表
    • 结点上的具体证书
    • 存储私钥的keystore
    • TLS的根证书与中间证书

    3、fabric交易提交流程

     

    3.1 peer结点的部署

    peer结点上保存有账本ledger以及智能合约,如下图所示:

    channel是一个逻辑概念,可以通过MSP隔离全网不同组织的参与者,如下图所示:

    当有多方参与者时,例如4个org组织、8个peer结点时,其中channel连接了P1、P3、P5、P7、P8这五个节点,其他3个节点加入了其他channel,其部署图如下所示:

    加入MSP来管理身份时,如P1和P2由ORG1.MSP管理,而P3和P4的证书则由ORG2.MSP管理,他们共同使用一个channel,则如下图所示:

    3.2 交易的执行流程

    去中心化的设计,必然需要通过投票(多数大于少数)来维持数据一致性,而任何投票都必须经历以下三个过程:

    1. 有一方先提出议案proposal,该议案有对应的一批投票者需要对该结果背书,这些投票者依据各自的习惯投票,并将结果反馈;
    2. 统计投票结果,若获得多数同意,才能进行下一步;
    3. 将获得多数同意的议案记录下来,且公之于众。

    而这三步fabric当然也少不了,当然它的称法就有所不同,其对应的三步如下:

    1. 由client上的CLI或者SDK进行proposal议案的提出。client会依据智能合约chaincode根据背书策略endorse policy决定把proposal发往哪些背书的peer节点,而peer节点进行投票,client汇总各背书节点的结果;
    2. client将获得多数同意的议案连同各peer的背书(包括其投票结果以及背书签名)交给orderring service,而orderer会汇总各client递交过来的trasaction交易,排序、打包。
    3. orderer将交易打包成区块block,然后通知所有commit peer,各peer各自验证结果,最后将区块block记录到自己的ledger账本中。

    我们看一个具体的例子,若channel上有三个peer背书者,client提交流程如下图所示:

    详细解释下上图的流程:

    1. 首先,client发起一个transaction交易,含有<clientID, chaincodeID, txPayLoad, timestamp, clientSig>等信息,指明了3W要素:消息是谁who在什么时间when发送了什么what。该消息根据chaincode中的背书策略,发向EP1、EP2、EP3这三个peer节点。
    2. 这三个peer节点模拟执行智能合约,并将结果及其各自的CA证书签名发还client。client收集到足够数量的结果后再进行下一步。
    3. client将含背书结果的tx交易发向ordering service。
    4. ordering service将打包好的block交给committing peer CP1以及EP1、EP2、EP3这三个背书者,背书者此时会校验结果并写入世界状态以及账本中。同时,client由于订阅了消息,也会收到通知。
      如果我们从编程的角度来看,则流程会更清楚:

    参见上图,A是我们的应用程序,其步骤如下:

    1. A首先连接到peer。
    2. A调用chaincode发起proposal;与此同时,P1收到后先模拟执行,再产生结果返回给A。
    3. A收到各peer返回的结果。
    4. A向O1发起交易;与此同时,O1产生区块后会通知peer,而peer会更新其账本。
    5. 最后通过订阅事件A收到了结果。

    最后再细看下这三个阶段。

    3.2.1 proposal提案阶段

    可以看到,A1发出的<T1, P>,收到了<T1, R1, E1>和<T1, R2, E2>两个结果。

    3.2.2 package打包阶段

    O1在一个channel上会收到许多T交易,它会将T排序,在达到block的最大大小(一般应配1M以下,否则性能下降严重,kafka擅长处理小点的消息)或者达到超时时间后,打成区块P2。

    3.2.3 验证阶段

    O1将含有多条交易T打成区块的B2发往各peer节点,而P1和P2将B2加入各自的L账本中。

    4、小结

    本文偏重于概念的解释,由于篇幅所限,未涉及fabric的系统搭建(请参考笔者的这篇文章《区块链开源实现fabric快速部署及CLI体验》),也未描述共识算法在异常情况下如何维持一致性,这留待下一篇文章解决。fabric的许多思想是值得我们进一步研究的,其优秀的实现可以帮助我们通过fabric获得区块链在信任创新上的思路。

    出处 陶辉笔记

    展开全文
  • 该文结合比特币、以太坊和 Hyperledger Fabric区块链平台,提出了区块链系统的体系架构;从区块链数据、共识机制、智能合约、可扩展性、安全性几个方面阐述了区块链的原理与技术;通过与传统...
  • 区块链开源实现hyperledger fabric架构详解

    万次阅读 多人点赞 2018-05-26 10:34:44
    hyperledger fabric区块链中联盟链的优秀实现,主要代码由IBM、Intel、各大银行等贡献,目前v1.1版的kafka共识方式可达到1000/s次的吞吐量。本文中我们依次讨论:区块链的共通特性、fabric核心概念、fabric的交易...
  • Hyperledger Fabric是目前主流的...纵观Fabric的发布历程,在v0.6.1-preview版本至v1.0.0的版本迁移过程中架构发生了明显的变化,在v1.0.0之后每个小版本中加入了一些新的feature,来支持不同的业务场景以及完善相应...
  • 区块链架构与交易流程区块链系统架构节点网络拓扑交易流程1、 提交交易提案2、 模拟执行提案并签名3、 返回模拟执行结果4、 提交交易5、 交易排序并结块6、 广播区块7、 保存区块状态并更新世界状态8、 同步区块9、 ...
  • Hyperledger Fabric channel是两个或多个特定网络成员之间进行通信的专用“子网”,目的是进行专用和机密交易。渠道由成员(组织),每个成员的锚点,共享账本,链码应用程序和排序服务节点定义。网络上的每个事务都...
  • 包含内容:fabric系统结构,网络拓扑结构,交易流程,first-network实例,fabcar实例 系统架构 整个图分为上下两部分,上面是应用程序,下面是底层架构 应用程序: 使用grpc结构开发,在API基础上,官方针对不同语言...
  • - state全部翻译为状态,这个状态是一个特定的概念,可理解为区块链某一时刻的快照。 - valid和invalid分别翻译成有效的和无效的,也可以理解为合法的和不合法的。 - replay翻译为重播,我觉得比较形象,也可以...
  • 该图出自区块链技术指南一书,架构解释也主要出自于本书,有兴趣的同学可以去自行找一找资源。 如图所示:fabric的底层主要由四种服务构成,分别是:身份服务、策略服务、区块链服务、智能合约服务。在这些基础服务...
  • Fabric架构与智能合约开发视频教程,本次课程全面介绍Fabric的组成和工作原理,并介绍如何开发Fabric智能合约。Fabric是超级账本(Hyperledger)最早也是最成熟的项目,目前国内腾讯、阿里、百度、华为,国外亚马逊...
  • 一、源码类型 当前区块链源码主要以C++为主,辅之以Go,而对于国内庞大的Java开发者来说来说,又出现Java区块链。个人认为C++会在未来继续占大头,毕竟效率最高,而Go... fabric Go IPFS Go 以太坊...
  • 今天看了一篇讲解fabric架构的文章,感觉还不错,将fabric里的MSP和交易流程都讲的明明白白,遂将文章在此分享。各位也可以直接看原文,也可以看我的,中间穿插了些本人拙见。 文章转载自...
  • hyperledger fabric区块链中联盟链的优秀实现,主要代码由IBM、Intel、各大银行等贡献,目前v1.1版的kafka共识方式可达到1000/s次的吞吐量。本文中我们依次讨论:区块链的共通特性、fabric核心概念、fabric的交易...
  • 翻译自:http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html 边学习边翻译,很多地方还不明白,请对照原文...- state全部翻译为状态,这个状态是一个特定的概念,可理解为区块链某一时刻的快...
  • Fabric是一种开源区块链实现,部署环境可以是私有服务器,也可以直接部署在公有云上,部署方式可传统可docker化,共识算法插件化,支持用Go和JavaScript开发智能合约,尤以企业级的安全机制和CA机制为特色。Fabric之...
  • hyperledger fabric区块链中联盟链的优秀实现,主要代码由IBM、Intel、各大银行等贡献,目前v1.1版的kafka共识方式可达到1000/s次的吞吐量。本文中我们依次讨论:区块链的共通特性、fabric核心概念、fabric的交易...

空空如也

空空如也

1 2 3 4 5 ... 18
收藏数 342
精华内容 136
关键字:

区块链fabric架构