title: 区块链技术：架构及进展总结归纳

1 引言

传统数据库

传统的关系型数据库管理系统、NoSQL数据库管理系统
- 单一机构进行管理和维护
- 单一机构对所有数据拥有绝对的控制权
- 其他机构无法完整了解数据更新过程
  - 无法信任数据库中的数据
在多个机构协作模式下，中心化的数据库管理系统始终存在信任问题

区块链

是一种去中心化、不可篡改、可追溯、多方共同维护的分布式数据库
能够将传统单方维护的仅涉及自己业务的多个孤立数据库整合在一起，分布式存储在多方共同维护地多节点上，任何一方都无法完全控制这些数据
- 只按照严格地规则和共识进行更新，从而实现了
  - 可信的多方间的信息共享和监督
  - 避免繁琐的人工对账
  - 提高业务处理效率
  - 降低交易成本
解决数据可信问题所使用的技术
1. P2P技术
2. 非对称加密
3. 共识机制
4. 块链结构
通过应用区块链技术，无需借助任何第三方可信机构，互不了解、互不信任的多方可实现可信、对等的价值传输

比特币 BitCoin

时间：2008年
作者：中本聪(Satoshi Nakamoto)
区块链源自于比特币的底层技术
可以在没有任何权威中介机构统筹的情况下，互不信任的人可以直接用比特币进行支付。

以太坊 Etherenum

时间：2013年12月
作者：Buterin
可基于内置的以太币(Ether)实现数字货币交易
提供图灵完备的编程语言以编写智能合约(smart contract)
- 首次将智能合约应用到区块链
愿景：创建一个永不停止、无审查、自动维护的去中心化的世界计算机

超级账本 Hyperledger

时间：2015年12月
作者：Linux基金会
开源区块链项目
旨在发展跨行业的商业区块链平台
提供
1. Fabric
  - 最受关注
  - 专门针对于企业级区块链应用设计
  - 引入成员管理服务
2. Sawtooth
3. Burrow

Corda

时间：2016年4月
作者: R3公司
- R3联盟：花旗银行、汇丰银行、德意志银行、法国兴业银行等80多家金融机构和监管成员
面向金融机构定制设计的分布式账本平台
受区块链启发的去中心化数据库，而不是一个传统的区块链平台
- 反对区块链中每个结点拥有全部数据
- 注重保障数据仅对交易双方及监管可见的交易隐私性

BigchainDB

时间：2016年2月
作者：BigchainDB公司
可扩展的区块链数据库
- 高吞吐量、低延迟、大容量、丰富的查询和权限等分布式数据优点
- 去中心化、不可篡改、资产传输等区块链特性
被称为在分布式数据库中加入区块链特性
具有分布式数据库的优点
- 底层数据库选用了RethinkDB

ChainSQL

时间：2017年1月
作者：国内的众享比特团队
号称全球首个基于区块链技术的数据库应用平台ChainSQL
基于插件式管理，底层支持SQLite3、MySQL、PostgreSQL等关系数据库

TrustSQL

时间：2017年4月
作者：腾讯
致力于提供企业级区块链基础设施及区块链云服务
支持
- 自适应共识机制
- 4000TPS交易吞吐量
- 秒级交易确认
- Select、Insert两种SQL语句

区块链平台分类(准入机制)

区块链平台可分为公有链、联盟链两类。

公有链
- 所有的节点可自由地加入或退出
- 节点通常是匿名
联盟链
- 节点必须经过授权才可加入
- 需要提供成员管理服务以对节点身份进行审核

表1 区块链平台对比

区块链平台	准入机制	数据模型	共识算法	智能合约语言	底层数据库	数字货币
Bitcoin	公有链	基于交易	PoW	基于栈的脚本	LevelDB	比特币
Ethereum	公有链	基于账户	PoW/PoS	Solidity/Serpent	LevelDB	以太币
Hyeprledger Fabric	联盟链	基于账户	PBFT/SBFT	Go/Java	LevelDB/CouchDB	-
Hyperledger Sawtooth	公有链/联盟链	基于账户	PoET	Python	-	-
Corda	联盟链	基于交易	Raft	Java/Kotlin	常用关系型数据库	-
Ripple	联盟链	基于账户	RPCA	-	RocksDB/SQLite	瑞波币
BigchainDB	联盟链	基于交易	Quorum Voting	Crypto-Conditions	Rethink/MongoDB	-
TrustSQL	联盟链	基于账户	BFT-Raft/PBFT	JS	MySQL/MariaDB	-

数据库概述

数据库最初发展的原点是文件系统，为了满足以银行为代表的金融机构的业务需求，引发关系数据库领域中的关系模型、事务处理、查询优化等三大成就，产生一系列关系数据库产品
随着互联网行业的快速发展，非结构化数据的数据量已经远超结构化数据的数据量，从而引发了NoSQL数据库系统的发展，产生了一系列的NoSQL数据库产品。
如今，随着去中介的共享经济的发展，区块链作为一种去中心化的分布式数据库，解决了可信的价值传输问题，因此将成为共享经济业务的理想数据库平台。

2 区块链体系架构

图１区块链体系架构

区块链平台整体上可划分为五个层次

网络层
共识层
数据层
智能合约层
应用层

层次	比特币	以太坊	Hyperledger Fabric
应用层	比特币交易	Dapp\以太币交易	企业级区块链应用
智能合约层编程语言	Script	Solidity	Serprent
智能合约层沙盒环境	-	EVM	Docker
数据层数据结构	Merkle树/区块链表	Merkle Patricia树/区块链表	Merkle Bucket树/区块链表
数据层数据模型	基于交易	基于账户	基于账户
数据层区块存储	文件存储	LevelDB	文件存储
共识层	PoW	PoW/Pos	PBFT/SBFT
网络层	TCP-based P2P	TCP-based P2P	HTTP/2-head P2P

2.1 网络层

2001年，提出将P2P技术与数据库进行联合研究
- 早期P2P数据库没有预定全局模式，不能适应网络变化而查询到完整的结果集，因而不适合企业级应用
基于P2P的区块链
- 可实现数字资产交易类的金融应用
- 区块链网络中没有中心节点，任意两个节点间可直接进行交易，任何时刻每个节点也可自由加入或推出网络
  - 因此，区块链平台通常选择完全分布式且可容忍单点故障的P2P协议作为网路传输协议
  - 区块链网络节点具有平等、自治、分布等特性
  - 所有节点以扁平拓扑结构相互连通，不存在任何中心化的权威节点和层级结构，每个节点均拥有路由发现、广播交易、广播区块、发现新节点等功能
区块链网络的P2P协议主要用于节点间传输交易数据和区块数据
- 比特币和以太坊的P2P协议基于TCP协议实现
- Hyperledger Fabric的P2P协议基于HTTP/2协议实现
在区块链网路中，节点时刻监听网络中广播的数据，当接收到相邻节点发来的新交易和新区快时
- 验证这些交易和区块是否有效
  - 交易中的数字签名
  - 区块中的工作量证明
- 只有验证通过的交易和区块才会被处理和转发，以防止无效数据的继续传播
  - 新交易被加入正在构建的区块，新区块被链接到区块链

2.2 共识层

基于证明机制的共识通常适用于节点自由进出的共有链
- 比特币与以太坊始用PoW机制
基于投票机制的共识通常适用于节点授权加入的联盟链
- Hyperledger Fabri使用PBFT

分布式数据库

主要使用Paxos和Raft算法解决分布式一致性问题
这些数据库都由单一机构管理维护
所有节点都是可信的
算法只支持崩溃容错(Crash Fault-Tolerant, CFT)

区块链共识层

多方共同管理维护
网络节点可由任何一方提供，部分节点可能并不可信，因而需要支持更为复杂的拜占庭容错(Buzantine Fault-Tolerant, BFT)

解决拜占庭将军问题算法

假设在总共n个节点的网络中至多包含f个不可信节点

同步通讯

对于同步通讯且可靠网络，拜占庭问题能够在n≥3f+1的条件下被解决

异步通信

Fisher、Lynch和Paterson证明确定性的共识机制无法容忍任何节点失败
Castro和Loskov提出Practical Byzantine Fault Tolerance(PBFT)
- 将拜占庭协议的复杂度从指数级降低到多项式级别，使拜占庭协议在分布式系统应用成为可能。
Kotla等人提出了Zyzzyva
- 认为网络节点在绝大部分时间都处于正常状态，无需在每个请求都达成一致后再执行，而只需在发生错误后再达成一致
Kwon提出Tendermint
- 在按节点计票的基础上
  - 对每张投票分配了不同的权重，重要节点的投票可分配较高的权重
  - 若投票权重超过2/3，即认为可达成共识
- 仅通过少数重要节点达成共识会显著减少网络中广播的消息数
- 在基于数字货币的应用中，权重也可对应为用户的持币量，从而实现类似权益证明的共识机制
Liu等人提出Cross Fault Tolerance(XFT)
- 认为恶意者很难同时控制整个网络和拜占庭节点
  - 从而简化了BFT消息模式，可在n≥2f+1条件下解决拜占庭将军问题
业界还提出BFT改进算法
- Scalable BFT
- Parallel BFT
- Optimistic BFT
Ripple支付网络提出了基于一组可信认证节点的Ripple Protocol Consensus Algorithm(RPCA)
- 能够在n≥5f+1条件下解决拜占庭将军问题。

PoW

为了解决节点自由进出可能带来的女巫攻击(sybil attack)]问题，比特币应用了工作量证明机制(Proof of Work, PoW)机制

PoW源于Dwork等人的防范垃圾邮件的研究工作
- 即只有完成一定量计算工作并提供证明的邮件才会被接收。
Back提出Hashcash
- 一种基于哈希函数的工作量证明算法
比特币要求只有完成一定计算工作量并提供证明的节点才可以生成区块
- 每个网络节点利用自身计算资源进行哈希运算以竞争区块记账权
  - 只要全网可信节点所控制的计算资源高于51%，即可证明整个网络是安全的

PoS

为了避免高度依赖节点算力所带来的电能消耗，研究者提出一些不依赖算力而能够达成的共识算法

点点币(Peercoin)应用区块链生成难度与节点所占股份成反比的权益证明(Proof of Stake, PoS)

DPoS

比特股(Bitshares)应用了获股东投票数最多的几位代表按既定时间段轮流产生区块的股份授权证明(Delegated Proof of Stake, DPoS)机制

POET

Hyperledger Sawtooth 应用了基于Intel SGX可信硬件的逝去时间证明(Proof of Elapsed Time, POET)机制

2.3 数据层

数据结构的设计

现有区块链平台借鉴了Haber与Stornetta的研究工作，提出

基于文档时间戳的数字公证服务
- 以证明各类电子文档的创建时间
1. 时间戳服务器对新建文档、当前时间及指向之前文档签名的哈希指针进行签名
2. 后续文档又对当前文档签名进行签名
3. 形成一个基于时间戳的证书链
  - 该链反映了文件创建的先后顺序
  - 且链中的时间戳无法篡改
将多个文档组成块并针对块进行签名，用Merkle树组织块内文档等方案
- 区块链中每个区块包含区块头和区块体两部分
  - 区块体存放批量交易数据
  - 区块头存放Merkle根、前块哈希、时间戳等数据
    - 基于块内交易数据哈希生成的Merkle根实现了块内交易数据的不可篡改性与简单支付验证
    - 基于前一区块生成的前块哈希将孤立的区块链接在一起，形成了区块链
    - 时间戳表明该区块的生成时间
    - 比特币区块头还包含难度目标、Nonce等数据
      - 以支持PoW共识机制中的挖矿运算

数据模型的设计

比特币采用基于交易的数据模型
- 每笔交易由表明交易来源的输入和表明交易去向的输出组成
- 所有交易通过输入与输出链接在一起，使得每一笔交易都可追溯
以太坊和Hyperledger采用基于账户的模型
- 需要支持功能丰富的通用应用
- 可基于账户快速查询到当前余额或状态

数据存储的设计

因为区块链数据类似于创痛数据库的预写式日志，因此通常都按日志文件格式存储

由于系统需要大量基于哈希的键值检索
- 如交易哈希检索交易数据、基于区块哈希检索区块数据
索引数据和状态数据通常存储在Key-Value数据库
- 如比特币、以太坊与Hyperledger Fabric都是以LevelDB数据库存储索引数据库

2.4 智能合约层

智能合约: 一种用算法和程序来编制合同条款、部署在区块链上且可按照规则自动执行的数字化协议

概念最早由Szabo提出
- 最初定义：一套以数字形式定义的承诺，包括合约参与方执行这些承诺所需的协议
- 初衷：将智能合约内置到物理实体以创造各种灵活可控的智能资产。

区块链实现了去中心化存储，智能合约在其基础上实现了去中心化的计算。

比特币脚本

比特币脚本: 嵌在比特币交易上的一组指令

其只能算作智能合约的出行
- 由于指令类型单一、实现功能有限

以太坊智能合约

以太坊提供

图灵完备的脚本语言Solidity、Serpent
- 编写
沙盒环境 Ethereum Virtual Machine(EVM)
- 运行

Chaincode

Fabric的智能合约

选用Docker容器作为沙盒环境
Docker容器中带有一组经过签名的基础磁盘映像与语言环境

2.5 应用层

比特币平台

基于比特币的数字货币交易

以太坊

基于以太坊的数字货币交易
去中心化应用(Decentralized Application, Dapp)

Dapp: 有JS构建的Web前端应用，通过JSON-RPC与运行在以太坊节点上的智能合约进行通信。

Fabric主要面向企业级区块链应用，并没有提供数字货币，基于SDK通过gRPC或REST与运行在Hyperledger Fabric节点上的智能合约进行通信。

3 区块链数据

3.1 区块链数据结构

为了实现数据的不可篡改性，区块链引入了以区块为单位的链式结构。

表2 区块链头部结构

字段	描述	大小
版本	比特币软件/协议的版本	4字节
前块哈希	前一区块的哈希值	32字节
Merkle Root	该区块中所有交易计算出的Merkle根	32字节
时间戳	该区块产生的近似时间	4字节
难度目标	生成该区块的难度目标	4字节
随机数Nonce	使区块头部哈希值小于难度目标的整数	4字节

二叉Merkle

Ralph Merkle 提出的Merkle树原用于生成数字证书目录的摘要，后来提出多种改进
比特币使用最简单的二叉Merkle树.
树上每个节点都是哈希值，每个叶子节点对应块内一笔交易数据的SHA256哈希
- 两个子节点的值连接之后，再经哈希运算可得到父节点的值
- 如此反复执行两两哈希，直至生成根哈希值，即交易Merkle根
通过Merkle根，块内任何交易数据的篡改都回检测到，从而确保交易数据的完整性
无需树上其它结点参与，仅根据交易结点到Merkle根路径上的直接分支，即可基于简单支付验证(Simplified Payment Verification, SPV)确认一个交易是否存在于该块
不需全部全部区块数据即可验证交易，使其非常适合于构建轻客户端和电子钱包

改进Merkle

以太坊和Fabric 块头除含有交易Merkle根外，还含有针对账户状态数据的状态Merkle根(State Root)
以太坊块头还含有针对交易执行日志的收据Merkle 根(Receipts Root)

Merkle Particia

以太坊计算Merkle Root始用的是Merkle Particia 树
虽然区块中的交易数据是不变的，但状态数据经常改变且数量众多，构建新区块时，Merkle Patricia 树仅需计算在新区块种变化的账户状态，状态没有变化的分支可直接引用，而无需重新计算整棵树。
如图3所示
- Merkle Patricia树包含扩展结点、分支结点和叶子结点
  - 扩展结点包含了共同的Key前缀
  - 分支结点通常在扩展结点之后，基于单个16进制字符的Key前缀实现树的分支
  - 叶子结点包含了以太坊账户状态
- Merkle Patricia 树实质上是融合了Merkle树和前缀树，因此具有查找能力。
  - 以一个以太坊账户地址为查找路径，能够快速的从Merkle Patricia树根向下查找到叶子结点中账户的状态数据，这种查找能力是二叉Merkle树所不具备的
  - Merkle Patricia 树还具有深度有限、根值与结点更新顺序无关等特性

Merkle Bucket

Fabric计算状态Merkle根使用的是Merkle Bucket树

Merkle Bukcet树是多叉树，每个叶子结点是一个桶，桶中存放的是Key-Value类型的状态数据集。
为新区块计算状态根时，没有变化的桶可以被跳过，因而可快速计算状态根。
Merkle Bucket树可通过调整桶数和分支数来控制树的深度和宽度，从而可在不同的性能和资源需求间权衡

区块链表

对区块头中的Prev-BlockHash、Nonce、Merkle root 等元数据进行二次SHA256哈希运算即可得到该区块的块哈希。

如图2所示，PrevBlockHash存放前一区块的块哈希，所有区块按照生成顺序以PrevBlockHash为哈希指针链接在一起,就形成了一条区块链表。
区块头包含交易Merkle根，所以通过块哈希可以验证区块头部和区块中的交易数据是否被篡改
区块头还包含前块哈希PrevBlockHash，所以通过块哈希还可验证该区块之前直至创始区块的所有区块是否被篡改。
当不可信结点下载某块及之前所有块时，基于块哈希可验证各块是否被修改过

3.2 区块链数据模型

基于交易的模型

以数字货币为基础的区块链中的交易。

每个交易由交易输入和交易输出组成，交易输入和输出可以有多项，表示一次可以将先前多个账户中的比特币合并转给另外多个账户。
在基于交易的模型中，所有交易依靠上笔交易哈希指针构成了多条以交易为结点的链表
- 每笔交易可一直向前追溯至源头的Coinbase(即挖矿所得的的比特币)
- 向后可追溯至尚未花费的交易
- 如果一笔交易的输出没有任何另一笔交易的输入与之对应，则说明该输出中的比特币未被花费，通过收集当前所有未花费的交易输出(Unspent Transaction Outputs, UTXO),可快速验证某交易中的比特币是否已花费，针对某一比特币地址，其所有未花费交易的比特币之和，即为该账户的比特币余额。
基于交易的模型可有效防范伪造、双花等针对数字货币的攻击。

比特币交易输入结构

字段	描述	大小
上笔交易哈希	指向上笔交易，该交易包含了需被支付的比特币	32字节
上笔交易输出索引	指出上笔交易的第几个交易输出，从0开始计数	4字节
输入脚本尺寸	以字节为单位	1-9字节
输入脚本	包含了花费比特币所需的证明，如：持有者签名	可变
序列号	未启用，缺省未0xFFFFFFFF	4字节

每个输入的组成

PrevTxHash 上笔交易的哈希
Index 上笔交易的输出索引
ScriptSig 输入脚本

比特币交易输出的结构

字段	描述	大小
转账金额	以聪(10^-8Bitcoin)为单位	8字节
输出脚本尺寸	以字节为单位	1-9字节
输出脚本	定义了比特币被花费的条件，如：接收者的比特币地址	可变

每个输出包括转账金额Value和包含接收者公钥哈希的脚本ScriptPubKey

基于账户的模型

基于交易的模型虽可便利地验证交易，但无法快速查询用户余额
支持更多类型地行业应用，基于账户的的模型方便地查询交易余额或业务状态数据
智能合约更适合在基于账户地模型之上构建，其针对状态数据更易处理复杂的业务逻辑

以太坊的账户分为

外部账户(Externally Owned Account)
- 用于表达一个以太坊普通账户的以太坊余额
合约账户(Contract Account)
- 用于表达一个以太坊智能合约，普通账户中的余额、智能合约中状态变量都属于以太坊状态数据

图5描述了以太坊账户的状态转换过程，状态反应了账户中各属性的当前值，涉及账户的一笔交易发生时，会引起账户状态的变化。

外部账户和合约账户在以太坊下用同一数据结构表示其包含四个属性
- Balance是账户中的以太币余额
- Nonce是对账户发送过的交易的计数，用于防范重放攻击
- 当账户被应用于智能合约时，CodeHash为合约代码的哈希值
- StorageRoot是合约状态数据的Merkle Patricia 树根
以太坊的交易包含7个属性：
- To 接收者的账户地址
- Value 转账的以太币金额
- Nonce 发送者对本次交易的计数
- gasPrice 交易时Gas的以太币单价
- gasLimit gasLimit是执行该交易时所允许的最大Gas数额
- Data 调用智能合约时的消息数据
- 交易签名发送者对交易的ECDSA签名

3.3 区块链数据存储

区块链在磁盘上的存储形式
1. 文件形式
  - 更方便于日志形式的追加操作
2. 数据库形式
  - 更易实现查询和修改
- 举例
  - 比特币、Fabric1.0
    - 区块链以文件形式存储
    - 索引数据存储在LevelDB数据库
  - 以太坊
    - 区块链和索引都存储在LevelDB数据库
- 区块链系统中存在大量哈希计算，交易、区块都依靠哈希值进行标识，所以底层数据库都选择了Key-Value数据库。
存储账户余额或业务状态数据
- 基于LevelDB构建状态数据库(world state)
- 在基于账户模型的区块链平台中，交易数据被打包进区块且经共识算法确认后
  1. 先追加入区块链
  2. 然后再写入状态数据库
- 当新的节点加入区块链网络时
  - 为了和已有节点数据保持一致，新节点需要同步区块链数据以达到全网区块的高度
  - 同时，状态数据库也需要和全网同步
- 从传统数据库来看，区块链数据相当于状态数据的WAL(Write-Ahead Logging)日志
LevelDB
- 轻量级的单机数据库，无需安装部署并且写入性能高效
- 但是基于LevelDB的数据库架构方案显然无法满足企业级的业务需求(如高并发、Non-Key查询等)
  - Fabric 提供了插件化的数据访问机制，其除了支持LevelDB数据库外，还额外支持CouchDB分布式数据库

共识机制

传统分布式数据库主要使用Paxos和Raft算法解决分布式一致性问题，它们假定系统中每个节点都是忠诚、不作恶的，但报文可能发生丢失和延时等问题。当分布式数据库的所有节点由单一机构统一维护时，此假定成立。
在去中心化的区块链网络中，节点由互不了解、互不信任的多方参与者存在欺骗、作恶的可能，因此Paxos和Raft算法不能直接用于区块链的共识。

表5 PoW与PBFT对比

-	Pow	PBFT
节点准入机制	公有链	联盟链
交易吞吐量	7TPS(比特币) 20-30TPS(以太坊)	200-300TPS(Fabric 0.6)
交易确认时间	60min(比特币) 3min(以太坊)	毫秒级(Fabric 0.6)
可扩展性	节点数<100 000	节点数<100
拜占庭容错	<50%的算力	<33%的投票
资源消耗	哈希消耗计算资源	广播消耗网络资源
分叉可能性	有	无
最终一致性	否	是

4.1 PoW

公有链中每个节点身份匿名且可自由进出，使得基于节点投票机制的共识算法不适合公有链，因为恶意攻击者可创建任意多节点以增加投票权，从而发动女巫攻击并误导系统。

PoW机制可有效应对女巫攻击，其依靠分布式节点间的算力竞争来保证全网区块链数据的一致性和安全性。
PoW机制要求每个节点基于自身算力解决求解复杂但验证容易的SHA256计算难题，即寻找一个合适的随机数Nonce，使得区块头部元数据的SHA256小于区块头中难度目标的设定值 $H(n||h)\le{t}$
- H为SHA256哈希函数
- n为随机数Nonce
- h为区块头部数据
- t为难度目标，t值越小，n值越难找到
- 最先寻找到的节点可获得新区块的记账权
PoW在区块链网络中的共识流程如下：
1. 每笔新交易被广播到区块链网络的所有节点
2. 为了构建新的区块，每个节点收集前一区块生成以来接收到的所有交易，并根据这些交易及手段计算出区块头部的Merkle根。将区块头部的随机数Nonce从0开始递增到1，直至区块头的两次SHA256哈希值小于或等于难度目标的设定值为止。
3. 全网节点同时参与运算，若某节点先找到正确的随机数，则该节点将获得新区块的记账权及奖励,并将该区块向全网广播
  - 奖励包括新区块中的区块奖励及每笔交易的交易费用
4. 其他节点接收到新区块后，验证区块中的交易和随机数Nonce的有效性，如果正确，就将该区块加入本地的区块链中，并基于该块开始构建下一区块。
Pow机制将经济激励与公式机制相融合，促使更多节点参与挖矿并保持诚信，从而主动增强了网络的可靠性与安全性，这是其他算法所不具备的。
挖矿实质是寻找由多个前导零构成的区块头哈希值，当难度目标的设定值越小，区块头哈希值的前导零就越多，寻找到合适随机数的概率就越低，挖矿的难度就越大。
- 为了适应硬件技术的快速发展及计算能力的不断提升，比特币每2016块就会调整一次难度目标，以控制区块的平均生成时间(10 min)始终保持不变。
- 对于PoW机制来说，若要篡改和伪造链中某一区块，就必须针对该区块及其后每个区块重新寻找块头的随机数Nonce，并且计算速度还要超过主链，这需要至少掌握全网51%以上的算力，才能使攻击成为可能，因此攻击的难度和成本非常高。
- PoW机制实质上是以牺牲性能换取数据的一致性和安全性，所以基于PoW机制的区块链平台的性能相对较低。
- 目前比特币平均每10min产生一个区块，区块尺寸上限为1MB，普通交易（包含一个输入与两个输出）的尺寸约为250B，可计算出交易吞吐量约为7TPS；以太坊平均每12-15s产生一个区块，交易吞吐量约为20-30TPS
决定交易吞吐量的关键参数
1. 区块尺寸
  - 大区块能容纳更多交易，但在网络中传播需要更长时间，会增加分叉风险
  - 大区快需要更强有力的矿机，会增加中心化的风险
2. 出块间隔
  - 减小出块间隔，就需降低挖矿难度，其会使网络中同时挖矿成功的节点增多，若多个区块同时被创建就会引起分叉
分叉
- 当发生分叉时，最长的链即花费了最多算力的链被认为是主链，其他则被认为是分支，分支中的所有交易会被忽略
- 分叉不但增加了有效块中的作废率，还易引起双花攻击。
- 比特币将分支节点上的区块称为孤块，并会将其作为废块而丢弃
- 为保证挖矿的公平性及避免挖矿算力的浪费，以太坊引入了GHOST(Greedy Heaviest-Observed Sub-Tree)协议来处理分叉
  - GHOST协议认为分支上的有效区块对确认主链上的交易也有贡献，因而没有丢弃该区块，
    - 而是将该区块作为叔块并给予相当于主块87.5%的奖励
    - 给予叔块的直接子块相当于主块12，5%的奖励
    - 矿工每引用一个叔块给予相当主块3%的奖励
- 分叉会带来交易的不确定性，，目前比特币假定６个区块之后，交易已基本不可逆，所以其交易确认时间为60min；以太坊假定12个区块之后，交易已基本不可逆，所以其交易确认时间为3min；但理论上这些交易并未最终确认

PoS机制

针对PoW机制抵消、耗能的缺陷，PoS机制无需矿工购买矿机、消耗电力及进行无意义的计算，而是根据矿工在区块链中拥有的股权(即数字货币量)来决定其挖矿的难度： $H(n||h)\le{s(M).t}\quad\quad(2)$
- M为某矿工；
- 函数s返回该矿工拥有的股权
- 当矿工M拥有的股权越多，挖矿的整体难度就会越低，其越容易找到合适的n
以太坊基于PoS机制提出了Casper共识
- 需要矿工购买以太币并注入以太坊作为抵押
- Casper以智能合约的方式实现，根据抵押的以太币和时间，成比例的分配区块的记账权和奖励
- 与PoS机制不同，Casper还引入惩罚机制，一旦发现某个矿工作弊，其抵押的所有以太币将全部罚没，参与共识和出块的权利也会被取消
- Casper虚拟了比特币挖矿过程，可使出块时间减少到4秒，且无需进行挖矿及消耗额外的电力

4.2 PBFT

PoW机制依靠算力竞争来保障区块链数据的一致性及安全性，但算力竞争消耗大量计算资源和电力能源，并不适合于针对企业级应用的联盟链。联盟链更适合无需消耗计算资源和电力资源的PBFT算法。

PBFT算法可容忍恶意节点不超过全网节点数量的1/3。
- 即如果超过2/3正常节点，就可保障数据的一致性和安全性
PBFT在区块链网络中的共识流程
1. 从全网节点中选出一个主节点，新区块由主节点负责生成
2. 每个节点把新交易向全网广播，主节点把从网络收集到的需放在新区块的多个交易排序后存入列表，并将该列表向全网传播。
3. 每个节点接收到交易列表后，依据排序模拟执行交易。所有交易执行完后，基于交易结果计算新区块哈希摘要，并向全网广播
4. 如果一个节点收到的 $2f(f为可容忍的恶意节点数)$ 条其他节点发来的摘要都和自己相同，就向全网广播一条commit消息
5. 如果一个节点收到 $2f+1$ 条commit消息，即可正式提交新区块及其交易到本地的区块链和状态数据库。
PBFT共识过程中的每个区块都由唯一的主节点生成，所以不存在分叉的可能，但在节点数为N的网络中，该算法由两个阶段需要传输的网络消息为 $O(N^2)$ ,，其会造成很大的网络开销。
- 因此，目前基于PBFT算法的区块链的系统性并不高。
如何支持共识节点的动态加入和退出也是待解决的问题。
目前，Fabric 1.0正在基于插件化开发
1. BFT-SMART
  - 强调实用性、可靠性、模块化的BFT软件库
  - 具有多核感知、节点动态进出可配置等特性
2. Simplified Byzantine Fault Torlerance(SBFT)
  - 假设主节点不会成为恶意节点，从而构建类似于Raft的消息模式，减少了网络中的广播通信
3. HoneyBadgerBFT
  - 首个实用的异步BFT协议
  - 不依赖任何时间假设就可保证网络有效性，即使在网络行为无法预测的广域网中也可容错

智能合约

智能合约: 用程序语言编写的商业合约，在预定条件满足时，能够自动强制的执行合同条款，实现“代码即法律”的目标。

区块链的去中心化使得智能合约在没有中心管理者参与的情况下，可同时运行在全网所有节点，任何机构和个人都无法将其强行停止。

比特币平台并不支持智能合约

5.1 运作机制

按照商业逻辑编写完智能合约代码后，需要将其发布到区块链网络节点上。
- 在以太坊中，部署后的合约存放在区块链上，每次被调用时才被以太坊虚拟机(EVM)加载运行
在Fabric中，部署后得合约被打包成Docker镜像，每个节点基于该镜像启动一个新的Docker容器并执行合约中的初始化方法，然后等待被调用
外部应用应通过调用智能合约来实现各种交易，
- 如果涉及到修改操作，需要现在全网的达成共识，之后修改记录会被记录在区块链中，修改结果会被存在状态数据库中
  - 例如，转账交易的转账金额会被记录到区块链，账户余额的增减会被应用到状态数据库。
- 如果调用仅包含查询操作，则无需共识，也不需被记录在区块链上。
智能合约支持合约内部事件的注册与通知机制，从而可主动向外部应用通知合约内部发生的关键事件。
智能合约目前只能访问链内数据，无法主动监听并响应链外事件
智能合约定义了交易逻辑及访问状态数据的业务规则，外部应用(如以太坊中的去中心化应用Dapp)需要调用智能合约，并依照合约执行交易和访问状态数据.
- 外部应用与智能合约间的关系非常类似于传统数据库应用与存储过程间的关系
  - 存储过程运行于数据库管理系统之上，访问关系数据库数据
  - 智能合约运行于区块链系统之上，访问区块和状态数据

5.2 编程语言

比特币平台提供处理交易的简单脚本，这些脚本是基于栈的一组指令，为了避免可能的漏洞与攻击，所以没有设计循环指令和系统函数。
- 因而比特币不是图灵完备的程序语言，比特币平台不存在严格意义上的智能合约
以太坊自定义了Solidity、Serpent等图灵完备的脚本语言以开发智能合约，自定义脚本语言是为了实现特殊的合约功能。
- 内置了表示“账户地址”的address数据类型，倾向于支持基于数字货币的支付应用
- 以太坊的合约账户和外部账户共享同一地址空间，合约地址能被看作一个外部账户地址，可通过向合约地址发送交易来调用智能合约。
- 合约执行过程中依据占用的CPU和内存会消耗Gas,Gas由以太币兑换而来，一旦Gas耗尽，合约就会终止执行，消耗掉的费用不会退回，从而防范了垃圾交易或含有死循环的智能合约
- Solidity、Serpent等图灵完备的编程语言在增强合约逻辑、降低合约编写难度的同时，也会带来潜在的安全风险。
  - Solidity团队正在考虑整合形式化验证以保障智能合约代码的正确性
Fabric可基于Go语言开发智能合约。
- 其智能合约被称为Chaincode，倾向于支持通用的企业级应用，其是与区块链交互的唯一渠道和生成交易的唯一来源
- 编写合约实质上是实现Chaincode接口中的Init、Invoke和Query三个函数
  - 用于实现状态数据的初始化、修改和查询

5.3 沙箱环境

智能合约不能直接运行在区块链节点上，因为合约中若含有漏洞或恶意代码，就会直接威胁到区块链节点的安全，所以智能合约必须运行在隔离的沙箱环境中。合约和宿主系统之间、合约与合约之间被沙箱执行环境有效隔离、互不干扰，这就限定了漏洞或恶意代码的影响范围。

主流区块链对沙箱的支持分为虚拟机和容器两种，作用都是保证合约代码在沙箱中执行，以对合约使用的资源进行隔离和限制
以太坊使用自定义的EVM作为沙箱，运行由Solidity、Serpent等语言编译生成的字节码，这些字节码不能访问EVM宿主机的网络系统、文件系统和其他进程，合约之间也只有有限的调用。
Fabric使用轻量级的Docker容器作为沙箱，基于Docker自身提供的隔离性和安全性，保护了宿主机不受容器中恶意合约的攻击，也防止了容器之间的相互影响

6 可扩展性

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

比特币、以太坊、Fabric目前都采用全网节点共享一条区块链的单链方案，网络上每个节点需要处理、存储全网的所有交易和全部数据，整个区块链系统的处理能力实际上受限于单个计算节点的处理能力。
受到共识算法的影响，随着节点数的增加，系统整体处理能力不但未随之上升，甚至还会降低
为了实现动态的可扩展性
- 以太坊应用了分片(sharing)的解决方案
- Fabric使用多通道(multichannel)d的解决方案
- 这些方案使得全网由原来的单链扩展到了多链(multi-chain),在多链上可同时并发的处理多笔交易，突破全网处理能力受限于单个节点的限制，从而提升系统整体性能

6.1 分片

为了解决以太坊系统吞吐量和存储容量的问题、支持全球范围内的高频次交易。

2016年，提出分片处理交易解决方案。

以太坊依据账户地址将全网划分为多个相对独立的分片
- 每个分片内维护一条独立子链，用户可以自行选择在哪个分片执行自己的交易
- 每个节点根据自身的计算和存储能力选择加入一个或多个分片，并处理和存储这些分片上的交易
- 全网节点分工配合以覆盖到所有分片，如果需要访问本节点没有的交易数据，则利用轻客户端技术从其他分片节点读取。
- 全网节点可并行的处理和存储不同的交易数据，使得全网交易处理能力不再受限于单一节点，单一节点也不需处理、存储全部数据
- 应用分片技术后，以太坊不再适宜使用PoW共识机制
  - 因为分片会将全网算力分散，在单个分片内攻击者很容易突破51%的算力
  - 因此应用分片技术的以太坊2.0使用基于权限证明机制的Casper共识算法

6.2 多通道

为了解决Fabric的系统扩展性和交易隐私性问题，Fabric提出了多通道解决方案。

以太坊的分片技术从资源均衡的角度将整个区块链网络划分为大小相同的多个分片
Fabric的通道技术则基于交易规则将整个区块链网络划分为多个逻辑上的通道，每个结点根据自己需要参与的交易来选择加入相应的通道

如图7所示，每个结点可以在多个链上同时接收和处理区块，多个链上的交易可以独立、并发地执行。
- 相对于原来的单链结构，全网吞吐量将显著提升。
Ordering服务节点提供插件化的共识服务，可基于Kafka消息系统或SBFT共识对所有链上的每个交易进行统一排序
- 当其由可信方或监管机构构成时，就不涉及交易隐私的问题
- 不希望Ordering服务节点获得交易的具体内容时，可利用加密来隐藏交易数据
在基于PoW共识机制的比特币和以太币中，节点在任意时刻都可自由加入或退出
Fabric采用的PBFT算法要求所有节点数目已知且静态不变，这就不利于区块链网络的动态扩展
- 为此 Fabric1.0 将网络节点分为共识节点(orderer)和记账节点(committer),解耦了共识服务和记账服务，从而实现了记账节点的动态加入或退出

7 安全性

区块链系统无法直接应用传统数据库的安全机制，

为了保障数据的安全性，传统数据库系统都设计了完善的用户管理和存取控制。
- 用户管理通常需要运行在中心化的节点上
  - 这就和区块链所强调的去中心化相矛盾
- 存取控制与公有链所强调的数据公开性和透明性相矛盾
目前，区块链系统主要基于数字签名与验证来确保数字货币的所有权以及交易的不可伪造、不可否认的特性
- 依靠每次交易使用不同的数字证书和账户地址来保障交易的隐私性

7.1 签名与验证

基于公有链的比特币和以太坊没有提供用户管理服务
- 公钥是标志和区分一个用户的唯一方法
- 为了保障交易安全性，需要对每笔交易进行签名与验证，签名算法使用了椭圆曲线数字签名算法(ECDSA)
图8反映了比特币的签名与验证
1. 每当需要进行一笔转账交易时，接收者需要将其公钥的SHA256与RIPEMD160的双哈希结果pubKeyHash，即比特币地址提供给发送者
2. pubKeyHash会被放在交易的输出脚本ScriptPubKey中
- 以OP开头的语句是比特币脚本中的操作指令
- <>语句代表比特币脚本中的数据指令
- 为了完成一笔交易，发送者需要对该笔交易数据进行签名，并把签名sig和其公钥pubKey放在输入脚本ScriptSig中
  - 签名sig表明比特币持有者本人承认该交易并亲自发出了前一笔交易中获得的比特币
  - 公钥pubKey
    1. 用于验证签名sig的有效性
    2. 用于验证其哈希值是否和前一笔交易脚本中的比特币地址pubKeyHash一致
    - 保证发送者确实拥有这些比特币
- 以上所有签名和验证过程都是基于输入、输出脚本自动完成的

图9 以太坊的签名与验证
- 以太坊的交易数据中只包含了发送者的ECDSA签名，并不包含发送者的公钥和发送者的地址
  - 因为基于ECDSA签名、原始交易数据和椭圆曲线参数可以恢复出发送者的公钥，然后对公钥进行SHA3哈希运算，即可计算除发送者的账户地址
  - 如此设计可减少每笔交易的字节数，从而减小交易数据在存储和网络方面的开销
Fabric是针对联盟链而设计的，这就要求所有节点和用户必须经过认证和授权才可加入。
- Fabric提供专门的成员管理服务Membership，并基于CA中心分别提供了三种类型数字证，不同环节需要使用不同类型的证书
  - Ecert(Enrollment Cert)
    - 用于身份认证
    - 在登陆系统时可确认节点和用户的身份
  - Tcert（Transaction Cert)
    - 用于交易的签名与验证
    - Fabric的每笔交易都包含发送者的签名和交易证书，为确保第三方无法由交易证书追溯到具体的发送者，每次交易可使用不同的Tcert证书。
  - TLScert(Transport Layer Security Cert)
    - TLS证书用于系统组件间的SLL/TLS通讯

7.2 隐私性

所有交易数据公开、透明地全量存储在全网每个节点上，虽可防范数据伪造和篡改，但却带来了数据隐私问题。

比特币地址和以太坊地址都是公钥的哈希值
- 其与用户真实身份之间没有直接地对应关系，依靠隔断地址和用户真实身份之间的关联，实现一定程度的匿名性
- 每次交易都使用全新地址，不同地址之间没有任何关联，其实实现了多个交易间的不可关联性
- 但这些方案无法保障绝对的隐私性
  - 例如，电子钱包或比特币交易所的实名认证、同笔交易中多个输入间的关联关系、网络报文中IP地址与比特币地址的对应关系都可能泄露用户真实身份

区块链隐私保护既需要掩盖交易细节，又需验证交易的正确性。区块链目前的隐私保护方案包括

混币CoinJoin
- dash 达世币
- 将多笔交易凑成一笔交易一起执行，以打断发送地址和接收地址之间的联系
环签名ring signature
- monero 门罗币
- 用发送者的私钥和多个无关者的公钥加密交易数据，再用所有人的公钥解密数据，以此隐藏交易的发送者
零知识证明Zero-Knowledge Proof
- Zerocash
- 可在无需泄露交易数据、无任何额外信息的前提下，向验证者证明某个交易是正确的
- 实现了特定交易的隐私保护
- 通过扩展Zerocash，Hawk实现了具有隐私保护的智能合约，可支持任意交易的隐私保护。
- zkSNARKs是应用于Zerocahs的零知识证明实现方案，其可在无需执行且无需知道输入的前提下验证一个计算的正确性。
  - Zerocash使用zkSNARKs隐藏了交易关联性和转账金额，在无需泄露交易数据的前提下，完成交易的确认和验证
  - 以太坊正在扩展智能合约语言，计划在EVM中增加SNAKE验证指令以高效支持zkSNARKs证明的验证
同态加密homo-morphic encryption
- 基于同台映射保证了先运算后加密和先加密后运算的结果相同，从而可基于加密数据实现交易验证

Fabric1.0采用多通道方案，任何需要交易的双方或多方可建立链接彼此的通道，其后所有交易都可在该通道上完成，通道上的所有交易数据会存储在单独的区块链上，只有通道上的用户可访问链上的数据，没有加入通道的用户将无权访问。

8 区块链的优劣势与发展趋势

8.1 区块链的优势

去中心化
不可篡改
可追溯
高可信
高可用

8.2 区块链的劣势

吞吐量
事务处理
- 目前的区块链平台主要依赖底层数据库来提供事务处理，而底层数据库大多是没有事务处理能力的Key-Value数据库。
- 单个节点上的智能合约执行失败会导致数据库数据不一致，必须从其他节点同步数据才能使本机数据恢复到一致状态
并发处理
查询统计
访问控制
可扩展性
- 传统数据库通过横向扩展增加节点数，线性提高系统吞吐量、并发访问量和存储容量

8.3 区块链的发展趋势

共识机制
隐私保护
部分存储
链外交易
多链与侧链
跨链
区块树和区块图
SQL on Blockchain
BlockchainDB

来源：CSDN

作者：小鸟打字

链接：https://blog.csdn.net/qq_20101209/article/details/84023587

标签

区块链

比特币交易

网络节点

以太坊

区块链技术：架构及进展

1 引言

传统数据库

区块链

比特币 BitCoin

以太坊 Etherenum

超级账本 Hyperledger

Corda

BigchainDB

ChainSQL

TrustSQL

区块链平台分类(准入机制)

表1 区块链平台对比

数据库概述

2 区块链体系架构

图１ 区块链体系架构

2.1 网络层

2.2 共识层

分布式数据库

区块链共识层

解决拜占庭将军问题算法

同步通讯

异步通信

PoW

PoS

DPoS

POET

2.3 数据层

数据结构的设计

数据模型的设计

数据存储的设计

2.4 智能合约层

比特币脚本

以太坊智能合约

Chaincode

2.5 应用层

比特币平台

以太坊

3 区块链数据

3.1 区块链数据结构

表2 区块链头部结构

二叉Merkle

改进Merkle

Merkle Particia

Merkle Bucket

区块链表

3.2 区块链数据模型

基于交易的模型

比特币交易输入结构

比特币交易输出的结构

基于账户的模型

3.3 区块链数据存储

共识机制

表5 PoW与PBFT对比

4.1 PoW

PoS机制

4.2 PBFT

智能合约

5.1 运作机制

5.2 编程语言

5.3 沙箱环境

6 可扩展性

6.1 分片

6.2 多通道

7 安全性

7.1 签名与验证

7.2 隐私性

8 区块链的优劣势与发展趋势

8.1 区块链的优势

8.2 区块链的劣势

8.3 区块链的发展趋势

图１区块链体系架构