选择擅长的领域继续答题？
{@each tagList as item}
${item.tagName}
{@/each}
手机回答更方便，互动更有趣，下载APP
提交成功是否继续回答问题？
手机回答更方便，互动更有趣，下载APP
已赞过已踩过你对这个回答的评价是？评论
收起
展开全部区块链是一个信息技术领域的术语。从本质上讲，它是一个共享数据库，存储于其中的数据或信息，具有“不可伪造”“全程留痕”“可以追溯”“公开透明”“集体维护”等特征。展开全部区块链是一个信息技术领域的术语.从本质上讲,它是一个共享数据库,存储于其中的数据或信息,具有"不可伪造""全程留痕""可以追溯""公开透明""集体维护"等特征.基于这些特征,区块链技术奠定了坚实的"信任"基础,创造了可靠的"合作"机制
收起
更多回答（7）
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
为你推荐：
下载百度知道APP，抢鲜体验使用百度知道APP，立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。扫描二维码下载
×个人、企业类侵权投诉
违法有害信息,请在下方选择后提交
类别色情低俗
涉嫌违法犯罪
时政信息不实
垃圾广告
低质灌水
我们会通过消息、邮箱等方式尽快将举报结果通知您。说明
做任务开宝箱累计完成0
个任务
10任务
50任务
100任务
200任务
任务列表加载中...
}

title: 区块链技术：架构及进展 总结归纳传统数据库传统的关系型数据库管理系统、NoSQL数据库管理系统 单一机构进行管理和维护单一机构对所有数据拥有绝对的控制权其他机构无法完整了解数据更新过程 无法信任数据库中的数据在多个机构协作模式下，中心化的数据库管理系统始终存在信任问题区块链是一种去中心化、不可篡改、可追溯、多方共同维护的分布式数据库能够将传统单方维护的仅涉及自己业务的多个孤立数据库整合在一起，分布式存储在多方共同维护地多节点上，任何一方都无法完全控制这些数据 只按照严格地规则和共识进行更新，从而实现了 可信的多方间的信息共享和监督避免繁琐的人工对账提高业务处理效率降低交易成本解决数据可信问题所使用的技术 P2P技术非对称加密共识机制块链结构通过应用区块链技术，无需借助任何第三方可信机构，互不了解、互不信任的多方可实现可信、对等的价值传输比特币 BitCoin时间：2008年作者：中本聪(Satoshi Nakamoto)区块链源自于比特币的底层技术可以在没有任何权威中介机构统筹的情况下，互不信任的人可以直接用比特币进行支付。以太坊 Etherenum时间：2013年12月作者：Buterin可基于内置的以太币(Ether)实现数字货币交易提供图灵完备的编程语言以编写智能合约(smart contract) 首次将智能合约应用到区块链愿景：创建一个永不停止、无审查、自动维护的去中心化的世界计算机超级账本 Hyperledger时间：2015年12月作者：Linux基金会开源区块链项目旨在发展跨行业的商业区块链平台提供 Fabric 最受关注专门针对于企业级区块链应用设计引入成员管理服务SawtoothBurrowCorda时间：2016年4月作者: R3公司 R3联盟：花旗银行、汇丰银行、德意志银行、法国兴业银行等80多家金融机构和监管成员面向金融机构定制设计的分布式账本平台受区块链启发的去中心化数据库，而不是一个传统的区块链平台 反对区块链中每个结点拥有全部数据注重保障数据仅对交易双方及监管可见的交易隐私性BigchainDB时间：2016年2月作者：BigchainDB公司可扩展的区块链数据库 高吞吐量、低延迟、大容量、丰富的查询和权限等分布式数据优点去中心化、不可篡改、资产传输等区块链特性被称为在分布式数据库中加入区块链特性具有分布式数据库的优点 底层数据库选用了RethinkDBChainSQL时间：2017年1月作者：国内的众享比特团队号称全球首个基于区块链技术的数据库应用平台ChainSQL基于插件式管理，底层支持SQLite3、MySQL、PostgreSQL等关系数据库TrustSQL时间：2017年4月作者：腾讯致力于提供企业级区块链基础设施及区块链云服务支持 自适应共识机制4000TPS交易吞吐量秒级交易确认Select、Insert两种SQL语句区块链平台分类(准入机制)区块链平台可分为公有链、联盟链两类。公有链 所有的节点可自由地加入或退出节点通常是匿名联盟链 节点必须经过授权才可加入需要提供成员管理服务以对节点身份进行审核表1 区块链平台对比区块链平台准入机制数据模型共识算法智能合约语言底层数据库数字货币Bitcoin公有链基于交易PoW基于栈的脚本LevelDB比特币Ethereum公有链基于账户PoW/PoSSolidity/SerpentLevelDB以太币Hyeprledger Fabric联盟链基于账户PBFT/SBFTGo/JavaLevelDB/CouchDB-Hyperledger Sawtooth公有链/联盟链基于账户PoETPython--Corda联盟链基于交易RaftJava/Kotlin常用关系型数据库-Ripple联盟链基于账户RPCA-RocksDB/SQLite瑞波币BigchainDB联盟链基于交易Quorum VotingCrypto-ConditionsRethink/MongoDB-TrustSQL联盟链基于账户BFT-Raft/PBFTJSMySQL/MariaDB-数据库概述数据库最初发展的原点是文件系统，为了满足以银行为代表的金融机构的业务需求，引发关系数据库领域中的关系模型、事务处理、查询优化等三大成就，产生一系列关系数据库产品随着互联网行业的快速发展，非结构化数据的数据量已经远超结构化数据的数据量，从而引发了NoSQL数据库系统的发展，产生了一系列的NoSQL数据库产品。如今，随着去中介的共享经济的发展，区块链作为一种去中心化的分布式数据库，解决了可信的价值传输问题，因此将成为共享经济业务的理想数据库平台。图１ 区块链体系架构区块链平台整体上可划分为五个层次网络层共识层数据层智能合约层应用层层次比特币以太坊Hyperledger Fabric应用层比特币交易Dapp\以太币交易企业级区块链应用智能合约层编程语言ScriptSoliditySerprent智能合约层沙盒环境-EVMDocker数据层数据结构Merkle树/区块链表Merkle Patricia树/区块链表Merkle Bucket树/区块链表数据层数据模型基于交易基于账户基于账户数据层区块存储文件存储LevelDB文件存储共识层PoWPoW/PosPBFT/SBFT网络层TCP-based P2PTCP-based P2PHTTP/2-head P2P2.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 BFTParallel BFTOptimistic BFTRipple支付网络提出了基于一组可信认证节点的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)机制POETHyperledger Sawtooth 应用了基于Intel SGX可信硬件的逝去时间证明(Proof of Elapsed Time, POET)机制2.3 数据层数据结构的设计现有区块链平台借鉴了Haber与Stornetta的研究工作，提出基于文档时间戳的数字公证服务 以证明各类电子文档的创建时间时间戳服务器对新建文档、当前时间及指向之前文档签名的哈希指针进行签名后续文档又对当前文档签名进行签名形成一个基于时间戳的证书链 该链反映了文件创建的先后顺序且链中的时间戳无法篡改将多个文档组成块并针对块进行签名，用Merkle树组织块内文档等方案 区块链中每个区块包含区块头和区块体两部分 区块体存放批量交易数据区块头存放Merkle根、前块哈希、时间戳等数据 基于块内交易数据哈希生成的Merkle根实现了块内交易数据的不可篡改性与简单支付验证基于前一区块生成的前块哈希将孤立的区块链接在一起，形成了区块链时间戳表明该区块的生成时间比特币区块头还包含难度目标、Nonce等数据 以支持PoW共识机制中的挖矿运算数据模型的设计比特币采用基于交易的数据模型 每笔交易由表明交易来源的输入和表明交易去向的输出组成所有交易通过输入与输出链接在一起，使得每一笔交易都可追溯以太坊和Hyperledger采用基于账户的模型 需要支持功能丰富的通用应用可基于账户快速查询到当前余额或状态数据存储的设计因为区块链数据类似于创痛数据库的预写式日志，因此通常都按日志文件格式存储由于系统需要大量基于哈希的键值检索 如交易哈希检索交易数据、基于区块哈希检索区块数据索引数据和状态数据通常存储在Key-Value数据库 如比特币、以太坊与Hyperledger Fabric都是以LevelDB数据库存储索引数据库2.4 智能合约层 智能合约 一种用算法和程序来编制合同条款、部署在区块链上且可按照规则自动执行的数字化协议
概念最早由Szabo提出 最初定义：一套以数字形式定义的承诺，包括合约参与方执行这些承诺所需的协议初衷：将智能合约内置到物理实体以创造各种灵活可控的智能资产。区块链实现了去中心化存储，智能合约在其基础上实现了去中心化的计算。比特币脚本 比特币脚本 嵌在比特币交易上的一组指令
其只能算作智能合约的出行 由于指令类型单一、实现功能有限以太坊智能合约以太坊提供图灵完备的脚本语言Solidity、Serpent 编写沙盒环境 Ethereum Virtual Machine(EVM) 运行ChaincodeFabric的智能合约选用Docker容器作为沙盒环境Docker容器中带有一组经过签名的基础磁盘映像与语言环境2.5 应用层比特币平台基于比特币的数字货币交易以太坊基于以太坊的数字货币交易去中心化应用(Decentralized Application, Dapp) Dapp 有JS构建的Web前端应用，通过JSON-RPC与运行在以太坊节点上的智能合约进行通信。
Fabric主要面向企业级区块链应用，并没有提供数字货币，基于SDK通过gRPC或REST与运行在Hyperledger Fabric节点上的智能合约进行通信。3.1 区块链数据结构为了实现数据的不可篡改性，区块链引入了以区块为单位的链式结构。表2 区块链头部结构字段描述大小版本比特币软件/协议的版本4字节前块哈希前一区块的哈希值32字节Merkle Root该区块中所有交易计算出的Merkle根32字节时间戳该区块产生的近似时间4字节难度目标生成该区块的难度目标4字节随机数Nonce使区块头部哈希值小于难度目标的整数4字节二叉MerkleRalph 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 BucketFabric计算状态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字节输入脚本包含了花费比特币所需的证明，如：持有者签名可变序列号未启用，缺省未0xFFFFFFFF4字节每个输入的组成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 区块链数据存储区块链在磁盘上的存储形式 文件形式 更方便于日志形式的追加操作数据库形式 更易实现查询和修改举例 比特币、Fabric1.0 区块链以文件形式存储索引数据存储在LevelDB数据库以太坊 区块链和索引都存储在LevelDB数据库区块链系统中存在大量哈希计算，交易、区块都依靠哈希值进行标识，所以底层数据库都选择了Key-Value数据库。存储账户余额或业务状态数据 基于LevelDB构建状态数据库(world state)在基于账户模型的区块链平台中，交易数据被打包进区块且经共识算法确认后 先追加入区块链然后再写入状态数据库当新的节点加入区块链网络时 为了和已有节点数据保持一致，新节点需要同步区块链数据以达到全网区块的高度同时，状态数据库也需要和全网同步从传统数据库来看，区块链数据相当于状态数据的WAL(Write-Ahead Logging)日志LevelDB 轻量级的单机数据库，无需安装部署并且写入性能高效但是基于LevelDB的数据库架构方案显然无法满足企业级的业务需求(如高并发、Non-Key查询等) Fabric 提供了插件化的数据访问机制，其除了支持LevelDB数据库外，还额外支持CouchDB分布式数据库传统分布式数据库主要使用Paxos和Raft算法解决分布式一致性问题，它们假定系统中每个节点都是忠诚、不作恶的，但报文可能发生丢失和延时等问题。当分布式数据库的所有节点由单一机构统一维护时，此假定成立。在去中心化的区块链网络中，节点由互不了解、互不信任的多方参与者存在欺骗、作恶的可能，因此Paxos和Raft算法不能直接用于区块链的共识。表5 PoW与PBFT对比-PowPBFT节点准入机制公有链联盟链交易吞吐量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 ) ≤ t H(n
h)\le{t} H(n∣∣h)≤t H为SHA256哈希函数n为随机数Nonceh为区块头部数据t为难度目标，t值越小，n值越难找到最先寻找到的节点可获得新区块的记账权 PoW在区块链网络中的共识流程如下： 每笔新交易被广播到区块链网络的所有节点为了构建新的区块，每个节点收集前一区块生成以来接收到的所有交易，并根据这些交易及手段计算出区块头部的Merkle根。将区块头部的随机数Nonce从0开始递增到1，直至区块头的两次SHA256哈希值小于或等于难度目标的设定值为止。全网节点同时参与运算，若某节点先找到正确的随机数，则该节点将获得新区块的记账权及奖励,并将该区块向全网广播 奖励包括新区块中的区块奖励及每笔交易的交易费用其他节点接收到新区块后，验证区块中的交易和随机数Nonce的有效性，如果正确，就将该区块加入本地的区块链中，并基于该块开始构建下一区块。 Pow机制将经济激励与公式机制相融合，促使更多节点参与挖矿并保持诚信，从而主动增强了网络的可靠性与安全性，这是其他算法所不具备的。
挖矿实质是寻找由多个前导零构成的区块头哈希值，当难度目标的设定值越小，区块头哈希值的前导零就越多，寻找到合适随机数的概率就越低，挖矿的难度就越大。 为了适应硬件技术的快速发展及计算能力的不断提升，比特币每2016块就会调整一次难度目标，以控制区块的平均生成时间(10 min)始终保持不变。对于PoW机制来说，若要篡改和伪造链中某一区块，就必须针对该区块及其后每个区块重新寻找块头的随机数Nonce，并且计算速度还要超过主链，这需要至少掌握全网51%以上的算力，才能使攻击成为可能，因此攻击的难度和成本非常高。PoW机制实质上是以牺牲性能换取数据的一致性和安全性，所以基于PoW机制的区块链平台的性能相对较低。目前比特币平均每10min产生一个区块，区块尺寸上限为1MB，普通交易（包含一个输入与两个输出）的尺寸约为250B，可计算出交易吞吐量约为7TPS；以太坊平均每12-15s产生一个区块，交易吞吐量约为20-30TPS 决定交易吞吐量的关键参数 区块尺寸 大区块能容纳更多交易，但在网络中传播需要更长时间，会增加分叉风险大区快需要更强有力的矿机，会增加中心化的风险出块间隔 减小出块间隔，就需降低挖矿难度，其会使网络中同时挖矿成功的节点增多，若多个区块同时被创建就会引起分叉 分叉 当发生分叉时，最长的链即花费了最多算力的链被认为是主链，其他则被认为是分支，分支中的所有交易会被忽略分叉不但增加了有效块中的作废率，还易引起双花攻击。比特币将分支节点上的区块称为孤块，并会将其作为废块而丢弃为保证挖矿的公平性及避免挖矿算力的浪费，以太坊引入了GHOST(Greedy Heaviest-Observed Sub-Tree)协议来处理分叉 GHOST协议认为分支上的有效区块对确认主链上的交易也有贡献，因而没有丢弃该区块， 而是将该区块作为叔块并给予相当于主块87.5%的奖励给予叔块的直接子块相当于主块12，5%的奖励矿工每引用一个叔块给予相当主块3%的奖励分叉会带来交易的不确定性，，目前比特币假定６个区块之后，交易已基本不可逆，所以其交易确认时间为60min；以太坊假定12个区块之后，交易已基本不 可逆，所以其交易确认时间为3min；但理论上这些交易并未最终确认PoS机制针对PoW机制抵消、耗能的缺陷，PoS机制无需矿工购买矿机、消耗电力及进行无意义的计算，而是根据矿工在区块链中拥有的股权(即数字货币量)来决定其挖矿的难度： H ( n ∣ ∣ h ) ≤ s ( M ) . t ( 2 ) H(n
h)\le{s(M).t}\quad\quad(2) H(n∣∣h)≤s(M).t(2) M为某矿工；函数s返回该矿工拥有的股权当矿工M拥有的股权越多，挖矿的整体难度就会越低，其越容易找到合适的n以太坊基于PoS机制提出了Casper共识 需要矿工购买以太币并注入以太坊作为抵押Casper以智能合约的方式实现，根据抵押的以太币和时间，成比例的分配区块的记账权和奖励与PoS机制不同，Casper还引入惩罚机制，一旦发现某个矿工作弊，其抵押的所有以太币将全部罚没，参与共识和出块的权利也会被取消Casper虚拟了比特币挖矿过程，可使出块时间减少到4秒，且无需进行挖矿及消耗额外的电力4.2 PBFTPoW机制依靠算力竞争来保障区块链数据的一致性及安全性，但算力竞争消耗大量计算资源和电力能源，并不适合于针对企业级应用的联盟链。联盟链更适合无需消耗计算资源和电力资源的PBFT算法。PBFT算法可容忍恶意节点不超过全网节点数量的1/3。 即如果超过2/3正常节点，就可保障数据的一致性和安全性PBFT在区块链网络中的共识流程 从全网节点中选出一个主节点，新区块由主节点负责生成每个节点把新交易向全网广播，主节点把从网络收集到的需放在新区块的多个交易排序后存入列表，并将该列表向全网传播。每个节点接收到交易列表后，依据排序模拟执行交易。所有交易执行完后，基于交易结果计算新区块哈希摘要，并向全网广播如果一个节点收到的 2 f ( f 为 可 容 忍 的 恶 意 节 点 数 ) 2f(f为可容忍的恶意节点数) 2f(f为可容忍的恶意节点数)条其他节点发来的摘要都和自己相同，就向全网广播一条commit消息如果一个节点收到 2 f + 1 2f+1 2f+1条commit消息，即可正式提交新区块及其交易到本地的区块链和状态数据库。PBFT共识过程中的每个区块都由唯一的主节点生成，所以不存在分叉的可能，但在节点数为N的网络中，该算法由两个阶段需要传输的网络消息为 O ( N 2 ) O(N^2) O(N2),，其会造成很大的网络开销。 因此，目前基于PBFT算法的区块链的系统性并不高。如何支持共识节点的动态加入和退出也是待解决的问题。目前，Fabric 1.0正在基于插件化开发 BFT-SMART 强调实用性、可靠性、模块化的BFT软件库具有多核感知、节点动态进出可配置等特性Simplified Byzantine Fault Torlerance(SBFT) 假设主节点不会成为恶意节点，从而构建类似于Raft的消息模式，减少了网络中的广播通信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自身提供的隔离性和安全性，保护了宿主机不受容器中恶意合约的攻击，也防止了容器之间的相互影响横向扩展性使得分布式数据库的整体性能随着集群节点数的增加而线性提升。比特币、以太坊、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.1 签名与验证基于公有链的比特币和以太坊没有提供用户管理服务 公钥是标志和区分一个用户的唯一方法为了保障交易安全性，需要对每笔交易进行签名与验证，签名算法使用了椭圆曲线数字签名算法(ECDSA)图8反映了比特币的签名与验证 每当需要进行一笔转账交易时，接收者需要将其公钥的SHA256与RIPEMD160的双哈希结果pubKeyHash，即比特币地址提供给发送者pubKeyHash会被放在交易的输出脚本ScriptPubKey中以OP开头的语句是比特币脚本中的操作指令<>语句代表比特币脚本中的数据指令为了完成一笔交易，发送者需要对该笔交易数据进行签名，并把签名sig和其公钥pubKey放在输入脚本ScriptSig中 签名sig表明比特币持有者本人承认该交易并亲自发出了前一笔交易中获得的比特币公钥pubKey 用于验证签名sig的有效性用于验证其哈希值是否和前一笔交易脚本中的比特币地址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.1 区块链的优势去中心化不可篡改可追溯高可信高可用8.2 区块链的劣势吞吐量事务处理 目前的区块链平台主要依赖底层数据库来提供事务处理，而底层数据库大多是没有事务处理能力的Key-Value数据库。单个节点上的智能合约执行失败会导致数据库数据不一致，必须从其他节点同步数据才能使本机数据恢复到一致状态并发处理查询统计访问控制可扩展性 传统数据库通过横向扩展增加节点数，线性提高系统吞吐量、并发访问量和存储容量8.3 区块链的发展趋势共识机制隐私保护部分存储链外交易多链与侧链跨链区块树和区块图SQL on BlockchainBlockchainDB}