4.1 技术架构
考虑到商用区块链的稳定性和可扩展性，牛链科技区块链平台基于Hyperledger fabric开源代码并加以优化实现。其逻辑结构为“四横两纵”，包括网络层、数据层、共识层、合约层，以及成员管理和区块链监控服务。
图4-1
其中，网络层提供点对点（peer-to-peer）协议底层组网来传输区块数据，各节点通过P2P协议进行发现与数据传播；数据层提供账本结构的定义、组织和账本执行状态的存储；共识层提供高效的容错算法，在多个节点之间快速形成共识，负责确保底层数据强一致性；合约层可对各类应用进行设计与建模，包括对资产、记录、事务等多种对象的建模和实现。成员与账户管理服务为区块链网络提供节点管理、用户管理、隐私保护和访问控制等基础支撑服务。在带权限的区块链网络中，参与者是需要被授权的，参与者根据授权才能发起交易请求。区块链监控服务提供多种可视化管理工具，底层区块链的健康监控、系统参数配置、数据分析、区块链浏览器等。
账本结构
区块链采用灵活的账本结构，如图所示。
图4-2 区块链账本结构
- C1、C2…Cn表示发布在区块链网络上的链代码（智能合约），对于区块链账本来说，每页账本只记录链代码的操作命令；
- 链代码可以由任何验证结点发布，可执行代码自动同步给网络的所有结点；
- 业务运行的逻辑处理依赖于每个链代码（C1、C2）对应的相互隔离的WorldState(物理上是存在RocksDB里的键值对)动态维护的数据；
- 账本同步共识时校验WorldState的Hash值并记录在账本上，保障所有结点的WorldState值一致。
区块链是由一个区块链表定义的，每个区块包含它在链中前一个区块的哈希。previousBlockHash哈希是通过SHA3 SHAKE256算法来对序列化后的区块消息计算512位的哈希值。区块包含的另外两个重要信息，区块所执行的所有交易列表和全局状态的哈希。区块的主要字段如下：
| 序号 | 字段名 | 字段说明 |
|---|---|---|
| 1 | version | 区块链协议版本号 |
| 2 | timestamp | 区块共识时间戳 |
| 3 | transactionsHash | 区块中交易的merkle root hash |
| 4 | stateHash | 全局状态的merkle root hash |
| 5 | previousBlockHash | 前一个区块的hash值 |
| 7 | consensusMetadata | 共识过程的元数据 |
| 8 | transactions | 交易消息的数组 |
一个完整的区块链包含了自创世块以来的所有交易信息。共有三种不同的交易类型：部署（Deploy），调用（Invoke）和查询（Query），部署交易用于向区块链上安装指定的合约，调用和查询交易会调用部署好的合约。其中，部署和调用这两种类型的交易会被记录在区块链上，查询交易并不改变系统状态，所以并不会记录在区块链中，只是将其记录在系统日志中。交易的主要数据结构如下：
| 序号 | 字段名 | 字段说明 |
|---|---|---|
| 1 | uuid | 交易的唯一ID |
| 2 | chaincodeID | 调用chaincodeID（若为部署交易时，chaincodeID表示代码路径） |
| 3 | type | 交易类型 |
| 4 | metadata | 交易参数 |
| 5 | confidentialityLevel | 保密级别 |
| 6 | secureContext | 交易者安全上下文 |
| 7 | timestamp | 时间戳 |
| 8 | cert | 数字证书 |
| 9 | signature | 数字签名 |
消息结构
节点之间的消息分为4种类型：发现（Discovery）, 交易（Transaction）, 同步(Synchronization)和共识(Consensus)。
发现消息：在启动时，peer就会自动运行发现协议，来发现当前区块链中的全部节点以及新加入的节点。
交易消息：所有的验证节点和非验证节点会将自己收到的交易发送到区块链网络中其他节点。
同步消息：当验证节点知道它自己的区块落后于其它节点或和它们不一样后所发起的消息。
共识消息：用于对每个区块中所包含的交易达成一致共识，目前区块链采用的PBFT（practical Byzantine fault tolerance）的共识协议。
智能合约
智能合约，即在区块链链上执行的计算机代码，通过rest接口部署到区块链上，由用户的交易来触发执行。
智能合约采用docker作为其运行环境，来管理智能合约的整个运行周期。每部署一个智能合约会启动一个相应的docker。智能合约部署后，区块链会为其生成一个全局唯一的id作为标识符，以后每次调用智能合约都需要指明所调用的智能合约id。智能合约当前只支持python语言编写，并需要符合一定的规范。
智能合约由交易触发执行，Transaction存有chaincode执行的相关信息，比如chaincodeID、函数名称、参数等。区块链收到交易并达成共识后会执行交易，将交易发送到智能合约所在的docker去执行。交易的执行的过程是非阻塞的，即用户提交交易后，区块链会生成一个唯一的交易id给用户，在对交易达成共识之后再执行交易。用户可以根据此id向区块链查询，看交易是否执行成功并保存在区块链中。
由于智能合约执行的过程会涉及到应用状态信息的改变，所以在智能合约中有一种机制叫全局状态，用来持久化执行过程中的状态，这些状态信息采用Key-value的形式存储在RocksDB数据库中。智能合约中可以根据业务需要，对全局状态中的数据进行存取，但是在不同的智能合约之间数据是隔离的，不会相互干扰。全局状态信息最终是保存在区块链上的，所以智能合约还需要和区块链进行通讯来存取状态信息。
智能合约提供了查询接口用户查询合约的状态信息，应用可根据需要决定向用户暴露哪些信息。查询信息是同步的接口，结果会立即返回给用户。
数据存储
区块链存储采用RocksDB， RocksDB是一个来自 facebook 的可嵌入式的支持持久化的 key-value 存储系统，也可作为 C/S 模式下的存储数据库。该数据库能够充分利用闪存的性能，大大提升应用服务器的速度。RocksDB 基于 Google 的 leveldb 1.5 版本, 做了许多优化, 性能相对 leveldb 有了很大的提升。
RocksDB相对于LevelDB有了很多改进，包括：
- RocksDB支持一次获取多个K-V，还支持Key范围查找。LevelDB只能获取单个Key。
- RocksDB支持多线程合并，而LevelDB是单线程合并的。LSM型的数据结构，最大的性能问题就出现在其合并的时间损耗上，在多CPU的环境下，多线程合并带来的优势是LevelDB所无法比拟的。
- 增加了column family，这样有利于多个不相关的数据集存储在同一个DB中。
数据库中主要存储信息区块（Block）信息，和状态信息（World State）信息。其中，每个区块中包含有交易信息，上一个区块的Hash值，时间戳等信息。
世界状态是所有部署在区块链上的链码（chaincode）的状态集合。链码的状态由键值对集合来表示。所以，逻辑上说，peer 的世界状态也是键值对的集合。其中键由元组{chaincodeID, ckey}组成，使用cKey来标识链码中的唯一键。
成员管理服务
成员管理服务用于管理区块链系统中的全部实体，这些实体包括节点的认证信息，用户的身份信息，管理员信息。成员管理提供用户注册、用户和节点信息认证、颁布证书等服务。整套成员管理服务采用的是公开密钥体系（Public Key Infrastructure，PKI），典型的PKI有包含证书颁发机构（CA），一个登记机构（RA），一个证书数据库。RA是对用户进行身份验证，校验数据的合法性。CA根据RA的建议为特定的用户发布证书。
系统中主要包含两种证书，注册证书和交易证书。注册证书是长期证书。它们是颁发给所有角色的，如用户，非验证 peer，验证 peer。交易证书是每个交易的短期证书，它们是由CA根据授权的用户请求颁发的，用于保障每次交易的安全。
交易在客户端，通过它们的创建者的证书签名，并发送给验证器网络。 验证器接受私密交易，并通过下列阶段传递它们：
- 预验证阶段，验证器根据根证书颁发机构来验证交易证书，验证交易中包含交易的证书签名。
- 共识阶段， 验证器把这笔交易加入到交易的全序列表中（最终包含在总账中）
- 预执行阶段， 进行解密交易（如果交易是加密的），并验证交易明文是否正确（即是否符合交易格式的规范）。
- 执行阶段， 链码和相关的代码元数据被传递给容器，并执行。
- 提交阶段，更新的链码的状态和交易本身被提交到总账中。
区块链环境和性能
区块链环境建议部署在linux环境（如CentOS）中，同时需要安装docker的运行环境。区块链运行所依赖的其他的环境如数据库、代码等，都被打包在docker镜像中。一个最小的区块链系统至少需要4个验证节点和一个成员管理服务。可以根据应用需要增添验证节点或非验证节点。
区块链的平台性能跟很多因素都有关系，特别在实际应用中，根据应用场景的不同和系统设计和使用的不同，可能同一套平台最终在业务体现上会有较大差异。
一般评测系统性能指标包括吞吐量（throughput）和延迟（latency）。对于区块链平台系统来说，实际交易延迟包括客户端到系统延迟（往往经过互联网），再加上系统处理反馈延迟（跟不同 consensus 算法关系很大）。本文档中仅给出交易吞吐量（tps）测试数据。所有给出指标和结果仅供参考，由于评测环境和方案不同，不保证结果的一致性。
机器环境
类型 操作系统 内核版本 CPU（GHz） 内存 物理机 CentOS 7.0 3.10.0-327.36.1.el7.x86_64 32core - 2.10GHz 16G 测试结果
客户端数量 验证节点数量 区块交易数量上限 tps 1 4 500 2000