区块链系统架构梳理 & 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插口。

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

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

• 智能合约作机制
  

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

• 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语句，使应用程序获得与访问传统数据库相同的接口。

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值的前缀。

4. Chaincode

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

6. 其他：Chaincode namespace、Endorsement policies、Connection Profile、Identities等