区块链的技术架构

本文重点分析区块链技术通用的技术架构

难得糊涂_清_郑板桥

当前存在各种各样的区块链底层技术架构方案，虽然在具体的实现上面各有不同，但是其整体的架构却存在很多共性，本文将从9个维度逐一分析架构框架。

区块链技术架构图.png

上图，对于9个维度进行了基本的划分。

---

接下来我们详细分析下各个模块的具体内容。

1，基础设施（Infrastructure）

基础设施层提供区块链系统正常运行的操作系统和硬件设施（包括物理服务器，云主机等等）。
具体可细分为3个方面：

• 计算资源（CPU、GPU、ASIC等）
• 存储资源（硬盘）
• 网络资源（带宽）
  这部分和其他的系统并无太大的区别，无非是有的偏重计算，有的偏重存储，有的对于网络的依赖程度高。

2，基础组件（Utility）

基础组件层实现区块链系统中信息的记录、验证和传播。
区块链是建立在传播机制、验证机制和存储机制基础上的一个分布式系统，整个网络没有中心化的硬件或者管理机构，任何节点都有机会参与总账的记录和验证，将计算结果广播发送给其他节点，且任一节点的损坏或者退出都不影响整个系统的运作。
1）网络发现
区块链系统有众多节点通过网络连接构成，特别是在共有链系统中，节点数量往往很大。每个节点都需要通过网络发现协议发现邻居节点，并与邻居节点建立链路。
对于联盟链而言，网络发现协议还需要验证节点身份，以防止各种网络攻击的发生。

2）数据收发
节点通过网络通讯协议连接到邻居节点后，数据收发模块完成与其他节点的数据交换。事物广播，消息共识以及数据同步等都由该模块执行。根据不同区块链的架构，数据收发器的设计需要考虑节点数量，密码学算法等因素。

3）密码库
区块链的多个环节都涉及到密码学算法。
密码库为上层组件提供基本的密码学算法支持，包括各种常用的编码算法、哈希算法、签名算法、隐私保护算法等等。
于此同时，密码库还涉及诸如密钥的维护和存储等方面的功能。

4）数据存储
根据数据类型和系统结构设计，区块链系统中的数据使用不同的数据存储模式。
存储模式包括关系型数据库（比如MySQL）和非关系型数据库（比如LevelDB）。
通常，需要保存的数据包括公共数据（例如：交易数据、事务数据、状态数据等）和本地的私有数据等。

5）消息通知
消息通知模块为区块链中不同组件之间以及不同节点之间提供消息通知服务。
交易成功之后，客户通常需要跟踪交易执行期间的记录和获取交易执行的结果。
消息通知模块可以完成消息的生成、分发、存储和其他功能，以满足区块链系统的需要。

3，账本（Ledger）

账本层负责区块链系统的信息存储，包括收集交易数据，生成数据区块，对本地数据进行合法性校验，以及将校验通过的区块加到链上。
账本层将上一个区块的Hash签名嵌入到下一个区块中组成块链式数据结构，使数据完整性和真实性得到保障，这正是区块链系统防篡改、可追溯特性的来源。
典型的区块链系统数据账本设计，采用了一种按时间顺序存储的块链式数据结构。
账本层有两种数据记录方式：基于资产和基于账户。
基于资产的模型中，首先以资产为核心进行建模，然后记录资产的所有权，即所有权是资产的一个字段。
基于账户的模型中，建立账户作为资产和交易的对象，资产是账户下的一个字段。
优势分析：
基于账户的数据模型：方便记录、查询相关信息
基于资产的数据模型：高并发
为了获取高并发的处理性能，而且及时查询账号相关信息，多个区块链平台正在向两种数据模型的混合模式发展。

下面的表格则记录对比了2种模型的差异分析

	基于资产	基于账户
建模对象	资产	用户
记录内容	记录资产所有权	记录账户操作
系统中心	状态（交易）	事件（操作）
计算重心	计算发生在客户端	计算发生在节点
判断依赖	方便判断交易依赖	较难判断交易依赖
并行	适合并行	较难并行
账户管理	难以管理账户元数据	方便管理账户元数据
适用的查询场景	方便获取资产最终状态	方便获取账号资产余额
客户端	客户端复杂	客户端简单
举例	比特币、R3 Corda	以太坊、超级账本Fabric

4，共识（Consensus）

共识层负责协调保障全网各个节点数据记录的一致性。
区块链系统中的数据由所有节点独立存储，在共识机制的协调下，共识层同步各节点的账本，从而实现节点选举、数据一致性验证和数据同步控制等功能。
数据同步和一致性协调使得区块链系统具有信息透明、数据共享的特性。
下表是常见的2种共识机制的对比

	第一类共识机制	第二类共识机制
写入顺序	先写入后共识	先共识后写入
算法代表	Pow,PoS,DPos	PBFT,BFT变种
共识过程	大概率一致就共识 工程学最后确认	确认一致性再共识 共识即确认
复杂性	计算复杂度高	网络复杂度高
仲裁机制	如果共识出现多个记账节点， 就产生分叉， 最终以最长链为准	法定人数投票， 各节点间P2P广播 沟通达成一致
是否分叉	由分叉	无分叉
安全阈值	作恶节点不超过1/2	作恶节点不炒作1/3总节点
节点数量	节点数量随意改变 节点数越多越稳定	节点数不能随笔改变 节点数越多，性能下降
应用场景	多用于非许可链	用于许可链

上述的两种共识机制，主要是根据数据的写入顺序先后来判定。
从业务应用需求看，共识算法的实现应该综合考虑应用环境、性能等诸多要求。
一般来说，许可链采用节点投票的共识机制，以降低安全性为代价，提升系统性能。
非许可链采用基于工作量或者权益证明等算法，主要强调系统安全性，但是性能较差。
为了鼓励各节点参与进来，维护区块链系统的安全运行，非许可链采用发行Token的方式，作为参与方的酬劳和激励机制，即通过经济平衡的手段来防止对总账本内容进行篡改。因此，根据运行环境和信任分级，选择适用的共识机制是区块链应用落地应当考虑的重要因素之一。

下面我们列举下几种共识算法的对比

特性	PoW	PoS	DPoS	PBFT	VRF
节点管理	无许可	无许可	无许可	需许可	需许可
交易延迟	高（分）	低（秒）	低（秒）	低（毫秒）	低（毫秒）
吞吐量	低	高	高	高	高
节能	否	是	是	是	是
安全边界	恶意算力 <1/2	恶意权益 <1/2	恶意权益 <1/2	恶意节点 <1/3	恶意节点 <1/3
代表应用	Bitcoin,Ethereum	Peercoin	Bitshare	Fabric	Algorand
扩展性	好	好	好	差	差

根据实际应用的类型，选择合适的共识算法非常关键。

5，智能合约（Smart Contract）

智能合约层负责将区块链系统的业务逻辑以代码的形式实现、编译并部署，完成既定规则的条件触发和自动执行，最大限度的减少人工干预。
智能合约的操作对象大多为数字资产，数据上链后难以修改、触发条件强等特性决定了智能合约的适用具有高价值和高风险，如何规避风险并发挥价值是当前智能合约大范围应用的难点。
智能合约根据图灵完备与否分成两类：图灵完备和非图灵完备。
影响实现图灵完备的常见原因包括：循环或递归受限、无法实现数组或更复杂的数据结构等。
图灵完备的智能合约有较强的适应性，可以对逻辑较复杂的业务操作进行编程，但有陷入死循环的可能。
对比而言，图灵不完备的智能合约虽然不能进行复杂逻辑操作，但是更加简单、高效和安全。

下面对比下主流平台的智能合约特性

区块链平台	是否图灵完备	开发语言
比特币	不完备	Bitcoin Script
以太坊	完备	Solidity
EOS	完备	C++
Hyperledger Fabric	完备	Go
Hyperledger Sawtooth	完备	Python
R3 Corda	完备	Kotlin/Java

当前智能合约的应用仍然处于比较初级的阶段，智能合约成为区块链安全的“重灾区”。从历次智能合约漏洞引发的安全时间看，合约便携存在较多安全漏洞，对其安全性带来了巨大挑战。
目前，提升智能合约安全性一般有几个思路：

• 一是形式化验证，通过严密的数学证明来确保合约代码所表达的逻辑符合意图。此法逻辑严密，但是难度较大，一般需要委托第三方专业机构进行审计。
• 二是智能合约加密。智能合约不能被第三方明文读取，以此减少智能合约因为逻辑上的安全漏洞而被攻击。此法成本较低，但无法开源。
• 三是严格规范合约语言的语法格式。总结智能合约优秀模式，开发标准智能合约模版，以一定的标准规范智能合约的编写可以提高智能合约的质量，提高合约的安全性。

6，系统管理（System Management）

系统管理层负责对区块链体系结构中其他部分进行管理，主要包括权限管理和节点管理两大类功能。
权限管理是区块链技术的关键部分，尤其对于数据访问有更多要求的许可链而言。
权限管理可以通过以下几种方式实现：

• 将权限列表提交给账本层，实现分散权限控制
• 使用访问控制列表
• 使用权限控制，例如评分/子系统
  通过权限管理，可以确保数据和函数调用只能由响应的操作员操作。
  节点管理的核心是节点标识的识别，通常有以下技术实现：
• CA认证，集中式颁发CA证书给系统中的各个应用程序，身份和权限由这些证书进行认证和确认
• PKI认证，身份由基于PKI的地址确认
• 第三方身份验证，身份由第三方提供的认证信息确认
  由于各种区块链具有不同的应用场景，因此节点管理具有更多差异。现有的业务扩展，可以与现有的身份验证和权限管理进行交互。

7，接口（Interface）

接口层主要用于完成功能模块的封装，为应用层提供简洁的调用方式。
应用层通过调用RPC接口与其他节点进行通信，通过调用SDK工具包对本地账本数据进行访问、写入等操作。
同时，RPC和SDK应遵守以下规则：

• 一是功能齐全，能够完成交易和维护分布式账本，有完善的干预策略和权限管理机制
• 二是可移植性好，可以用于多种环境中的多种应用，而不仅限于某些绝对的软件或者硬件平台
• 三是可扩展和兼容，应尽可能向前和向后兼容，并在设计中考虑可扩展性
• 易于使用，应使用结构化设计和良好的命名方法方便开发人员使用。常见的实现技术包括调用控制和序列化对象等。

8，上层应用（Application）

应用层作为最终呈现给用户的部分，主要作用是调用智能合约层的接口，适配区块链的各类应用场景，为用户提供各种服务和应用。
由于区块链具有数据确权属性以及价值网络特征，目前产品应用中很多工作都可以交由底层的区块链平台处理。
在开发区块链应用的过程中，前期工作必须非常谨慎，应当合理选择去中心化的公有链、高效的联盟链或者安全的私有链作为底层架构，以确保在设计阶段核心算法无致命错误问题。
因此，合理封装底层区块链技术，并提供一站式区块链开发平台将是应用层发展的必然趋势。同时，跨链技术的成熟可以让应用层选择系统架构时增加一定的灵活性。
根据实现方式和作用目的的不用，当前基于区块链技术的应用可以划分为三大类场景，如下表所示：

类型	价值转移类	存证类	授权管理
政府		电子发票 电子证照 精准扶贫	数据共享
金融	数字票据 跨境支付 应收账款 供应链金融	现钞冠字号 溯源 供应链金融	征信
工业	能源交易	防伪溯源
医疗	医疗保险	电子病例 药品溯源	健康数据共享
法律		公证 电子存证 网络仲裁
版权		版权确认	版权管理

9，运维管理（Maintenance）

运维管理层主要负责区块链系统的日常运维工作，包括日志、监控、管理和扩展等。
在统一的架构之下，各主流平台根据自身需求和定位不同，其区块链体系中存储模块、数据模型、数据结构、编程语言、沙盒环境等也都存在很大的差异。
下表将要针对各体系架构差异进行对比

平台差异	比特币	以太坊	Fabric	R3 Corda
编程语言	Script	Solidity	Go/Java	Java/Kotlin
沙盒环境	无	EVM	Docker	JVM
共识算法	PoW	PoS	PBFT/Kafka	Raft
数据类型	资产	账户	账户	资产
区块存储	文件存储	LevelDB	LevelDB/CouchDB	关系数据库

---

随时交流沟通