区块链系统架构图_一张图看懂比特币、以太坊、联盟链等区块链系统架构

我会在山顶，我会看到山和小山。在进入区块链底层开发之前，我们需要了解底层区块链的通用架构是如何设计的，从上到下审视区块链的底层结构。

他山之石可以攻玉。在介绍区块链底层通用架构之前，不妨先从比特币、以太坊、超级账本的架构解读入手。

比特币架构

根据中本聪的论文《Bitcoin: A Peer-to-Peer Electronic Cash System》中对比特币系统的描述，我们可以整理出下图所示的比特币系统架构。

比特币系统架构

如图所示，比特币系统分为6层，从下到上分别是存储层、数据层、网络层、共识层、RPC层、应用层。

其中存储层主要用于存储比特币系统运行中的日志数据和区块链元数据，存储技术主要使用文件系统和LevelDB。

数据层主要用于处理比特币交易中的各类数据，如将数据打包成区块、将区块维护为链式结构、对区块内容进行加密和散列、区块内容的数字签名和加法时间戳、交易数据构建成 Merkle 树、Merkle 树根节点哈希值的计算等。

由块组成的链可能会分叉。在比特币系统中，节点总是将最长的链视为正确的链，并在其后不断添加新的区块。

网络层用于构建比特币底层P2P网络，支持多个节点的动态加入和离开，有效管理网络连接，为比特币数据传输和共识提供基础网络支撑服务。

共识层主要采用PoW（Proof Of Work）共识算法。在比特币系统中，每个节点不断地计算一个随机数（Nonce），直到找到一个满足要求的随机数。在一定时间内，最先找到符合条件的随机数将获得打包区块的权利，从而构建了工作量证明机制。从 PoW 的角度，你发现 PoW 和分布式锁的目的是一样的吗？

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

应用层主要承载各种比特币应用，比如比特币开源代码中提供的比特币客户端。该层主要用作RPC客户端，通过JSON API与比特币底层进行交互。此外，比特币钱包和衍生应用都建立在应用层之上。

以太坊架构

根据以太坊白皮书《A Next-Generation Smart Contract and Decentralized Application Platform》的描述，以太坊架构如下图所示。

以太坊架构

如图所示，以太坊架构分为7层，从下到上分别是存储层、数据层、网络层、协议层、共识层、合约层、应用层。

存储层主要用于存储以太坊系统运行中的日志数据和区块链元数据，存储技术主要使用文件系统和LevelDB。

数据层主要用于处理以太坊交易中的各类数据，如将数据打包成区块、将区块维护为链式结构、对区块内容进行加密和散列、区块内容的数字签名和加法时间戳，将交易数据构造成默克尔树，计算默克尔树根节点的哈希值。

与比特币不同的是，以太坊引入了交易和交易池的概念。交易是指一个帐户向另一个帐户发送签名数据包的过程。交易池存储节点验证的交易，这些交易被放置在矿工挖出的新区块中。

以太坊的Event是指以太坊虚拟机提供的日志接口。当一个事件被调用时，对应的日志信息会保存在日志文件中。

与比特币一样，以太坊的系统也是基于 P2P 网络，其中每个节点都具有客户端角色和服务器角色。

协议层是以太坊为系统各模块相互调用提供的协议支持，主要包括HTTP、RPC协议、LES、ETH协议、Whipser协议等。

以太坊基于 HTTP Client 实现对 HTTP 的支持，并实现了 GET 和 POST 等 HTTP 方法。当外部程序通过 JSON RPC 调用以太坊 API 时以太坊区块能挖出多少个，需要使用 RPC（Remote Procedure Call）协议。

Whisper 协议用于 DApp 间的通信。

LES是Light Ethereum Sub-protocol的全称，它允许以太坊节点通过只下载区块头来同步获取区块，然后在需要的时候获取区块。其他部分。

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

合约层分为两层，底层是EVM（Ethereum Virtual Machine，以太坊虚拟机），上层智能合约运行在EVM中。智能合约是运行在以太坊上的代码的总称。智能合约通常包含两部分：数据和代码。智能合约系统对协议或合约进行编码，由特定事件触发和执行。因此，原则上适用于安全、信任、长期协议或合约的场景。在以太坊系统中，智能合约的默认编程语言是 Solidity，一般学过 JavaScript 语言的读者可以轻松上手 Solidity。

应用层包括DApp（去中心化应用，分布式应用）、以太坊钱包等衍生应用，是目前开发者最活跃的层。

超级账本架构

Hyperledger 是 Linux 基金会于 2015 年推出的一个开源项目，旨在推动区块链数字技术和交易验证。区块链和分布式账本系统的跨行业开发与协作。

目前这个项目最著名的子项目是IBM牵头的Fabric。如官网所述，Hyperledger Fabric 是一个分布式记账解决方案平台，基于模块化架构，提供高度的弹性、灵活性和可扩展性。它旨在支持不同组件的可插拔实现，并适应整个经济生态系统中存在的复杂性。

Hyperledger Fabric 提供独特的弹性和可扩展架构，使其有别于其他区块链解决方案。我们必须在经过严格审查的开源架构之上规划区块链企业的未来。 Hyperledger 是企业级应用快速构建的起点。

目前，Hyperledger Fabric 经历了两次架构的主要迭代，0.6 版和1.0 版。其中0.6版本的架构比较简单，Peer节点集成了很多功能，模块化和扩展性较差。 1.0 版本具有对等节点功能的 0.6 版本的模块化分解。最新的 1.1 版本目前处于 Alpha 阶段。

在1.0版本中，peer节点可以分为peer节点和orderers节点。 peers节点用于维护状态（State）和账本（Ledger），orderers节点负责对账本中的每一笔交易达成共识。

系统中还引入了Endorsing Peers，这是一种特殊的Peer，同时负责执行Chaincode和Endorsing Transactions。

Hyperledger Fabric的分层架构设计如下图所示。

Hyperledger Fabric 分层架构设计

Hyperledger Fabric可以分为7层，分别是存储层、数据层、通道层、网络层、共识层、合约层、应用层。

存储层主要存储账本和交易状态。账本状态存储在数据库中，存储的内容是出现在所有交易中的键值对信息。例如，在交易处理过程中，调用链码执行交易可以改变状态数据。用于状态存储的数据库可以使用 LevelDB 或 CouchDB。 LevelDB是系统默认的内置数据库，CouchDB是可选的第三方数据库。区块链的账本存储在文件系统中。

数据层主要由三部分组成：Transaction、State和Ledger。

有两种类型的事务： 部署事务：以程序作为参数创建新事务。部署事务成功执行后，链码安装在区块链上。

调用事务：对上一步部署的链码进行操作。 Chaincode 执行一个特定的函数，该函数可能会修改状态数据，并返回一个结果。

状态对应于交易数据的变化。在 Hyperledger Fabric 中，区块链的状态由键/值存储 (KVS) 进行版本控制和表示。键是名称，值是任何文本内容，版本号标识记录的版本。这些数据内容由链码通过 PUT 和 GET 操作进行管理。如存储层所述，状态持久存储在数据库中，状态更新由文件系统记录。

分类帐提供所有成功的状态数据更改和不成功的更改尝试的历史记录。

账本是由Ordering Service构造的完全有序的交易区块组成的区块哈希链（Hash Chain）。

账本可以存储在所有对等节点上，也可以选择存储在多个排序节点上。此外，账本允许重做所有交易的历史记录并重建状态数据。

通道层是指通道，是一种Hyperledger Fabric数据隔离机制，用于保证交易信息只对交易参与者可见。每个通道都是一个独立的区块链，因此多个用户可以共享同一个区块链系统，无需担心信息泄露。

网络层用于为区块链网络中的各个通信节点提供P2P网络支持，是保证区块链账本一致性的基础服务之一。

在 Hyperledger Fabric 中，Node 是区块链的通信实体。 Node只是一个逻辑功能，多个不同类型的Node可以运行在同一个物理服务器上。 Node分为三种类型，分别是Client、Peers Node和Ordering Service。

客户端用于将用户的交易请求发送到区块链网络。

节点负责维护区块链账本。 Peers 可以分为两种类型：endoring peer 和committing peer。 Endoring peers 验证交易。认证逻辑包括验证交易的有效性和签署交易；提交节点接收打包的块并将其写入区块链。与 Node 类似，对等点也是逻辑概念。 Endoring peers 和 committing peers 可以同时部署在一台物理机器上。

Ordering Service 会接收到交易信息，排序打包成区块，然后写入区块链，最后将结果返回给提交节点。

共识层基于Kafka、SBTF等共识算法实现。 Hyperledger Fabric 使用 Kafka 对交易信息进行排序和处理，提供高吞吐量、低延迟的处理能力，并支持集群内的节点容错。与Kafka相比，SBFT（Simple Byzantine Algorithm）可以提供更可靠的排序算法，包括对节点故障的容忍度和一定数量的恶意节点。

合约层是Hyperledger Fabric的智能合约层Blockchain。区块链默认由 Go 语言实现。区块链运行称为链码的程序，这些程序保存状态和分类帐数据并负责执行交易。在 Hyperledger Fabric 中，只能提交已批准的交易。交易是对链码操作的调用，因此链码是核心内容。还有一类特殊的链码，称为系统链码，用于管理函数和参数。

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

另外，由于是联盟链，Hyperledger Fabric中还有一个模块专门用于管理联盟中的成员，即Membership Service Provider（MSP）。 MSP用于管理成员认证信息。客户端和对等节点提供会员授权服务。

区块链的一般架构

到目前为止，我们已经了解了比特币、以太坊和 Hyperledger 的架构设计。三者根据不同的使用场景有不同的设计，但还是可以抽象出一些共通点，我们可以根据这些共通点设计企业级联盟链的底层架构。

本文提供的联盟链底层架构如下图所示。

联盟链底层结构

我们将区块链底层分为6层，从下到上分别是存储层、数据层、网络层、共识层、激励层和应用层。

存储层主要存储事务日志和事务相关内容。其中，事务日志是基于LogBack实现的。事务内容由内置SQLite数据库存储，可基于JPA实现读写SQLite数据库；交易的链上元数据信息由 RocksDB 或 LevelDB 存储。

数据层由块和块“链”（块的链式结构）组成。其中，区块还会涉及交易列表在默克尔树中的存储以及根节点哈希值的计算。交易的内容也需要加密。由于联盟链中存在多个节点，为了有效管理节点数据，保证数据安全，建议将不同的公私钥分配给不同的节点进行加密使用。

网络层主要为共识和数据通信提供底层支持。在区块链中，每个节点都是数据的发送者和接收者。可以说每个节点既是客户端又是服务器，所以需要基于长连接来实现。我们可以基于WebSocket以原生方式建立长连接，也可以基于第三方长连接工具包实现。

共识层采用PBFT（Practical Byzantine Fault Tolerance）共识算法。与公链的挖矿机制不同，联盟链更注重各节点信息的统一，因此可以省略挖矿，达到共识的目的。

激励层主要是Coin和Tokens的发行和流通。在公链中，激励是公链的灵魂；但在联盟链中则不需要。

应用层主要是联盟链中各个产品的落地。总联盟链应用层面向行业，解决行业问题。

联盟链Java版部署架构如下图所示。

联盟链Java版部署架构

联盟链由一个超级节点和几个普通节点组成。超级节点除了具有普通节点的功能外以太坊区块能挖出多少个，还具有在联盟中实现成员管理、权限管理、数据监控等的能力。因此，与完全去中心化的公链相比，联盟链是部分去中心化的，或者说联盟的“链”是去中心化的，但联盟链的管理是中心化的。

整个开发环境建议基于Spring Boot2.0实现。基于Spring Boot开发，可以省去大量xml配置文件的编写，可以大大简化项目中POM文件配置的复杂依赖。 Spring Boot还提供了各种starter，可以实现自动配置，提高开发效率。