2017-04-17 大鱼 区块链参考架构设计的思考（从零开始学区块链 131）
原文：https://zhuanlan.zhihu.com/p/26245232 作者：sQuare (季宙栋)

说明

大鱼：知乎上发现sQuare（季宙栋）的一篇不错的文章，转给朋友们看看，虽然我不太同意文中几个提法，但是本文对于架构设计很有帮助。

为了保障原文的可读性，保留了原文的编号规则和样式，橙色字体是我实在憋不住想说的话，看之前你必须明白区块链的诞生是为了去中心化，但是不去中心化也是可以应用区块链技术的，否则你会被本文搞晕。

原文

近年来，美国在FinTech领域不断实现技术突破和创新，特别是区块链方向，传统IT巨头、金融企业纷纷涉足其中，先后创建了Hyperledger、R3、EEA等著名区块链技术与应用联盟，积极地开展开源项目孵化，并在多个应用领域，包括但不限于 ：
1）金融服务
2）政府治理
3）保险
4）医疗健康
5）物联网
6）供应链
7）信息通信技术（ICT）

在这些领域，都得到广泛的概念验证和试点落地。为了更好地发展区块链技术，防范技术高速发展所孕育的潜在风险，行业标准刻不容缓。在此背景下，工信部中国电子技术标准化研究院牵头组织中国区块链技术和产业发展论坛主要成员，开展了《信息技术区块链和分布式账本技术参考架构》标准的研制工作。笔者作为国内区块链参考架构的编制人员参加了4月3日-5日的ISO/IEC TC307区块链国际标准组第一次会议，下文将对美国提交的区块链参考架构做一个简单分析并思考它的设计理念对我们国内区块链架构设计的借鉴作用。

注：（大鱼）我个人认为一个像样的区块链行业应用都没有的时候搞标准，未免有点空中楼阁了，现在的需要的是乱战，让市场检验出一个方向来

1. 参考架构的定位

（1）使用通俗的语言来描述区块链和分布式账本技术
（2）区块链或分布式账本技术的理想原型结构
（3）描述适用于区块链技术的标准范围

2. 参考架构的视角

可以从业务、法律或技术视角来看待区块链技术：

• 从业务角度来看，区块链是一个在相互认同的参与者之间，促进价值、资产或其他实体转移的交换网络
• 从法律角度来看，区块链账本上的交易是经过验证、不可否认且无法篡改的，它不需要中介或第三方参与。
• 从技术角度来看，区块链是一个引用其他数据存储作为账本数据、全局复制的分布式账本。

3. 参考架构的设计理念

首先，从分布式应用架构师和开发人员角度来设计一种区块链平台参考架构，如下图：

图3.1 区块链平台参考架构设计之一

它包含了6个层次：1）基础设施 2）安全 3）数据 4）账本 5）开发 6）分布式应用 ，我们一一对照解读一下。

注：（大鱼）这是典型的中心化架构图，我已经看过类似的东西不下一百多次了，乍一看很有道理，实际上必须依赖中心化实现，你只要明白这是个中心化结构，可以继续看本文。

（1）基础设施层

即运行分布式账本的一组服务器节点，它应该具有云计算的特性，包括虚拟化和可拓展性。该参考架构特别强调分布式账本不应该依赖于单个基础设施供应商，在联盟链场景下，应该使用来自多个基础设施供应商的云环境；这对国内是较大的挑战，企业往往出于管理便利性和自身数据安全考虑，仅选择一家公有云服务提供商或企业自己的云服务，在未来真正的分布式应用环境下，需要更加开放、高度兼容的IaaS服务。

（2）安全层

安全管理主要包含三部分内容，其中身份管理作为标准化的内容范围。

• 身份管理 – 即为不同角色维护他们在区块链网络中的数字身份
• 权限 – 即访问控制，如基于合约、用户、区块链等级别的权限管理，分级的权限控制符合更高的治理要求，更好适应各个国家监管和审计的要求。
• 可插拔加密服务 - 能够让用户自主选择和使用不同类型的加密算法，作为可升级的模块化组件，以应对未来量子计算机大规模流行对区块链所常用ECDSA等算法的安全性隐患。

（3）数据层

数据层都被纳入标准化的范围，主要包含下面三大服务：

• 安全（可信）数据访问服务 – 即分布式应用程序可以安全地存储和查询数据的能力
• 跨链服务 – 即智能合约在区块链与区块链间数据交互的能力
• 链上-链下服务 – 即安全地访问链下数据的能力，例如使用可信数据源或交叉使用可信认证技术.

（4）账本层

• 分布式账本 – 即在全部节点间共享的经验证、共识的交易记录
• 可插拔共识服务 – 即验证哪些交易可以写入分布式账本的方法，需根据应用场景让用户自主选择合适的共识算法

（5）开发层

• 智能合约服务 - 能够将数据管理逻辑、应用逻辑、业务规则和合同条款集成进分布式应用程序的能力。该服务是可扩展的，所以应该支持不同的开发语言。
• 开发工具 - 用于编写、记录、测试、部署和监控分布式应用的工具
  SDKs、APIs - 简化分布式应用程序访问分布式账本、智能合约等服务的中间代码。
• 编程接口 - 允许外部系统访问智能合约的服务、平台和数据的能力

总结一下，从开发者的角度来理解参考架构的设计思路，其根本目标是支持区块链的互操作性，使得用户、分布式应用和区块链之间能够实施可信数据交换，支持模块化、企业级程序设计、开放的IaaS，便于开发者复用成熟的功能模块和选择任意的开发平台，实现跨平台的可移植性。当前市面上主流的区块链和分布式账本技术普遍使用Go语言、JS语言进行分布式应用的研发，可以看出能够做到通用适配的平台较有优势。

作为一名区块链架构设计师，可以从下面几个维度去设计或者对区块链平台做一个选型：

1. 区块链或分布式账本技术：根据业务特性，在需要增加“信任”的场景下，选择区块链或分布式账本技术解决方案。

• 身份管理：构建一个弱中心的认证中心，使得通过简单的方式就可以访问多个区块链，比如主权身份（身份证、护照等）。
• 安全数据访问服务：存储的数据需要在区块链中全局共享，需参考数据访问层对安全的要求。
• 跨链服务：不同区块链间的智能合约数据交互；这个服务使得区块链之间构建了互操作性，在复杂的业务场景下，可以设计出细粒度运作的独立子链（逻辑/物理），并通过母-子智能合约满足不同的业务需求，提升了全局“臃肿”账本的灵活度。
• 链上-链下数据访问服务：分布式应用程序需要与传统的链下系统进行互操作；在区块链高速发展期，不可避免需要与传统数据库应用系统进行交互，可能会诞生大量区块链中间件服务该需求。
• 智能合约服务：对于开发者，智能合约需要具备可移植性，尽可能支持多个不同的区块链平台，降低跨平台移植的工作量。对于合约开发平台，应该提供一个语法规范，让不同的区块链平台支持该开发语言。
• 编程接口：为了行业应用的爆炸式发展，对于传统的应用开发者，需要提供熟悉的API接口方便调用区块链上的智能合约程序。

结束语：2017年将是区块链技术和应用的关键一年，将会涌现出大量有价值的应用。参考架构作为区块链领域的基础标准，一方面规范区块链技术和应用的研发，另一方面也为后续业务发展提供了引领的作用。