《区块链底层设计Java实战》之第二章区块链架构

第2 章   区块链架构

会当凌绝顶  一览众山小

 

 

正如开篇所言：会当凌绝顶，一览众山小。进入区块链底层开发前，我们需要

了解区块链底层的通用架构是如何设计的，从上而下地审视区块链底层的结构，做

到了然于胸，才能胸有成竹。

 

他山之石，可以攻玉。在介绍区块链底层通用架构之前，我们不妨先从比特币、

以太坊、Hyperledger 的架构解读开始。

 

2.1 比特币架构

根据中本聪的论文“Bitcoin: A Peer-to-Peer Electronic Cash System”中对比特币

系统的描述，我们可以整理出如图2-1 所示的比特币系统架构。

图2-1 比特币系统架构

 

如图2-1 所示，比特币系统分为6 层，由下至上依次是存储层、数据层、网络层、

共识层、RPC 层、应用层。

 

其中，存储层主要用于存储比特币系统运行中的日志数据及区块链元数据，存

储技术主要使用文件系统和LevelDB。

 

数据层主要用于处理比特币交易中的各类数据，如将数据打包成区块，将区块

维护成链式结构，区块中内容的加密与哈希计算，区块内容的数字签名及增加时间

戳印记，将交易数据构建成Merkle 树，并计算Merkle 树根节点的哈希值等。

区块构成的链有可能分叉，在比特币系统中，节点始终都将最长的链条视为正

确的链条，并持续在其后增加新的区块。

 

网络层用于构建比特币底层的P2P 网络，支持多节点动态加入和离开，对网络

连接进行有效管理，为比特币数据传输和共识达成提供基础网络支持服务。

共识层主要采用了PoW（Proof Of Work）共识算法。在比特币系统中，每个节

点都不断地计算一个随机数（Nonce），直到找到符合要求的随机数为止。在一定

的时间段内，第一个找到符合条件的随机数将得到打包区块的权利，这构建了一

个工作量证明机制。从PoW 的角度，是不是发现PoW 和分布式锁有异曲同工之

妙呢？

 

RPC 层实现了RPC 服务，并提供JSON API 供客户端访问区块链底层服务。

应用层主要承载各种比特币的应用，如比特币开源代码中提供了bitcoin client。

该层主要是作为RPC 客户端，通过JSON API 与bitcoin 底层交互。除此之外，比特

币钱包及衍生应用都架设在应用层上。

 

2.2 以太坊架构

根据以太坊白皮书A Next-Generation Smart Contract and Decentralized

Application Platform 的描述，以太坊架构如图2-2 所示。

 

如图2-2 所示，以太坊架构分为7 层，由下至上依次是存储层、数据层、网络层、

协议层、共识层、合约层、应用层。

 

其中存储层主要用于存储以太坊系统运行中的日志数据及区块链元数据，存储

技术主要使用文件系统和LevelDB。

 

数据层主要用于处理以太坊交易中的各类数据，如将数据打包成区块，将区块

维护成链式结构，区块中内容的加密与哈希计算，区块内容的数字签名及增加时间

戳印记，将交易数据构建成Merkle 树，并计算Merkle 树根节点的hash 值等。

 

与比特币的不同之处在于以太坊引入了交易和交易池的概念。交易指的是一个

账户向另一个账户发送被签名的数据包的过程。而交易池则存放通过节点验证的交

易，这些交易会放在矿工挖出的新区块里。

 

以太坊的Event（事件）指的是和以太坊虚拟机提供的日志接口，当事件被调用

时，对应的日志信息被保存在日志文件中。

 

与比特币一样，以太坊的系统也是基于P2P 网络的，在网络中每个节点既有客

户端角色，又有服务端角色。

 

协议层是以太坊提供的供系统各模块相互调用的协议支持，主要有HTTP、RPC

协议、LES、ETH 协议、Whipser 协议等。

 

以太坊基于HTTP Client 实现了对HTTP 的支持，实现了GET、POST 等HTTP

方法。外部程序通过JSON RPC 调用以太坊的API 时需通过RPC（远程过程调用）

协议。

 

Whisper 协议用于DApp 间通信。

 

LES 的全称是轻量级以太坊子协议（Light Ethereum Sub-protocol），允许以太坊

节点同步获取区块时仅下载区块的头部，在需要时再获取区块的其他部分。

共识层在以太坊系统中有PoW（Proof of Work）和PoS（Proof of Stake）两种共

识算法。

 

 

合约层分为两层，底层是EVM（Ethereum Virtual Machine，即以太坊虚拟机），

上层的智能合约运行在EVM 中。智能合约是运行在以太坊上的代码的统称，一个智

能合约往往包含数据和代码两部分。智能合约系统将约定或合同代码化，由特定事

件驱动触发执行。因此，在原理上适用于对安全性、信任性、长期性的约定或合同

场景。在以太坊系统中，智能合约的默认编程语言是Solidity，一般学过 JavaScript

语言的读者很容易上手Solidity。

 

应用层有DApp（Decentralized Application，分布式应用）、以太坊钱包等多种衍

生应用，是目前开发者最活跃的一层。

 

2.3 Hyperledger 架构

超级账本（Hyperledger）是Linux 基金会于2015 年发起的推进区块链数字技术

和交易验证的开源项目，该项目的目标是推进区块链及分布式记账系统的跨行业发

展与协作。

 

目前该项目最著名的子项目是Fabric，由IBM 主导开发。按官方网站描述，

Hyperledger Fabric 是分布式记账解决方案的平台，以模块化体系结构为基础，提供

高度的弹性、灵活性和可扩展性。它旨在支持不同组件的可插拔实现，并适应整个

经济生态系统中存在的复杂性。

 

Hyperledger Fabric 提供了一种独特的弹性和可扩展的体系结构，使其不同于其

他区块链解决方案。我们必须在经过充分审查的开源架构之上对区块链企业的未来

进行规划。超级账本是企业级应用快速构建的起点。

 

目前，Hyperledger Fabric 经历了两大版本架构的迭代，分别是0.6 版和1.0 版。

其中，0.6 版的架构相对简单，Peer 节点集众多功能于一身，模块化和可拓展性较差。

1.0 版对0.6 版的Peer 节点功能进行了模块化分解。目前最新的1.1 版本处于Alpha

阶段。

 

在1.0 版中，Peer 节点可分为peers 节点和orderers 节点。peers 节点用于维护状

态（State）和账本（Ledger），orderers 节点负责对账本中的各条交易达成共识。

系统中还引入了认证节点（Endorsing Peers），认证节点是一类特殊的peers 节点，

负责同时执行链码（Chaincode）和交易的认证（Endorsing Transactions）。

 

Hyperledger Fabric 的分层架构设计如图2-3 所示。

 

Hyperledger Fabric 可以分为7 层，分别是存储层、数据层、通道层、网络层、

共识层、合约层、应用层。

 

其中存储层主要对账本和交易状态进行存储。账本状态存储在数据库中，存储

的内容是所有交易过程中出现的键值对信息。比如，在交易处理过程中，调用链码

执行交易可以改变状态数据。状态存储的数据库可以使用 LevelDB 或者 CouchDB。

LevelDB 是系统默认的内置的数据库，CouchDB 是可选的第三方数据库。区块链的

账本则在文件系统中保存。

 

数据层主要由交易（Transaction）、状态（State）和账本（Ledger）三部分组成。

其中，交易有两种类型：

 部署交易：以程序作为参数来创建新的交易。部署交易成功执行后, 链码就

被安装到区块链上。

调用交易：在上一步部署好的链码上执行操作。链码执行特定的函数，这

个函数可能会修改状态数据，并返回结果。

 

状态对应了交易数据的变化。在Hyperledger Fabric 中，区块链的状态是版本化

的，用 key/value store（KVS）表示。其中key 是名字，value 是任意的文本内容，版

本号标识这条记录的版本。这些数据内容由链码通过PUT 和GET 操作来管理。如存

储层的描述，状态是持久化存储到数据库的，对状态的更新是被文件系统记录的。

账本提供了所有成功状态数据的改变及不成功的尝试改变的历史。

 

账本是由Ordering Service 构建的一个完全有序的交易块组成的区块哈希链

（Hash Chain）。

 

账本既可以存储在所有的peers 节点上，又可以选择存储在几个orderers 节点上。

此外，账本允许重做所有交易的历史记录，并且重建状态数据。

 

通道层指的是通道（Channel），通道是一种Hyperledger Fabric 数据隔离机制，

用于保证交易信息只有交易参与方可见。每个通道都是一个独立的区块链，因此多

个用户可以共用同一个区块链系统，而不用担心信息泄漏问题。

网络层用于给区块链网络中各个通信节点提供P2P 网络支持，是保障区块链账

本一致性的基础服务之一。

 

在Hyperledger Fabric 中，Node 是区块链的通信实体。Node 仅仅是一个逻辑上

的功能，多个不同类型的Node 可以运行在同一个物理服务器中。Node 有三种类型，

分别是客户端、peers 节点和Ordering Service。

其中，客户端用于把用户的交易请求发送到区块链网络中。

 

peers 节点负责维护区块链账本，peers 节点可以分为endoring peers 和committing

peers 两种。endoring peers 为交易作认证，认证的逻辑包含验证交易的有效性，并对

交易进行签名；committing peers 接收打包好的区块，并写入区块链中。与Node 类似，

peers 节点也是逻辑概念，endoring peers 和committing peers 可以同时部署在一台物

理机上。

 

Ordering Service 会接收交易信息，并将其排序后打包成区块，然后，写入区块

链中，最后将结果返回给committing peers。

 

共识层基于Kafka、SBTF 等共识算法实现。Hyperledger Fabric 利用Kafka 对交

易信息进行排序处理，提供高吞吐、低延时的处理能力，并且在集群内部支持节点

故障容错。相比于Kafka，SBFT（简单拜占庭算法）能提供更加可靠的排序算法，

包括容忍节点故障以及一定数量的恶意节点。

 

合约层是Hyperledger Fabric 的智能合约层Blockchain，Blockchain 默认由Go 语

言实现。Blockchain 运行的程序叫作链码，持有状态和账本数据，并负责执行交易。

在Hyperledger Fabric 中，只有被认可的交易才能被提交。而交易是对链码上的操作

的调用，因此链码是核心内容。同时还有一类称之为系统链码的特殊链码，用于管

理函数和参数。

应用层是Hyperledger Fabric 的各个应用程序。

 

此外，既然是联盟链，在Hyperledger Fabric 中还有一个模块专门用于对联盟内

的成员进行管理，即Membership Service Provider（MSP），MSP 用于管理成员认证

信息，为客户端和peers 节点提供成员授权服务。