原题：Design and Implementation on Hyperledger-Based Emission Trading System
作者：PU YUAN, XIONG XIONG, LEI LEI, KAN ZHENG
Abstract
为了缓解环境污染，同时又不能限制发展，政府机构通常会提出排放量交易的政策。制定排放总量，企业通过向政府申请来获取合法排放量。当然，申请得到的排放量也可以在企业之间进行交易，所以这种模式很适合区块链的架构。本文提出了一种基于区块链系统的排放交易系统（HyperETS），并着重于账本结构和智能合约的设计。
System Overview
应用场景
整个应用场景包含了四个实体：Trader、Approver、Environmental Agency和Trading Center。Trader提交申请到Environmental Agency由Approver审核，审核结果提交到Trading Center进行存储。而审核通过的Traders的交易记录都保存在Trading Center。具体步骤如下：
- 步骤1：注册Trader必须向环境机构提交公司申请，其中包含必要材料的清单（例如公司证书）。
- 步骤2：环境机构的Approver检查这些材料的有效性。
- 步骤3：一旦Approver接受了申请，Trader便可以基于该允许的公司身份提交项目申请。 项目申请书包括排放权交易的详细信息（例如，项目类型：购买/出售，交易排放许可的数量）。
- 步骤4：Approver检查项目申请的有效性。
- 步骤5：如果Approver接受了该项目，则可以在交易中心中看到它。
- 步骤6：Trader根据那些经过验证的项目开始相互交易排放许可。
系统架构
整个系统架构包含三个部分：区块链网络、HTTP服务器、客户端应用程序。客户端应用程序和HTTP服务器之间构成了C/S模式，而HTTP服务器与区块链网络构成了接口-存储层模式。
Implementation of HyperETS
区块链网络
分布式账本设计
账本数据以状态划分每个记录。用户下分为两个索引：公司和项目，公司记录着每个申请的公司状态和信息，而项目则保存每个申请项目的状态和信息，而每个项目则索引着在该项目下的每一笔交易。显然，智能合约着重于项目和交易记录上的处理。而公司、项目和交易的字段设计如下表：
智能合约设计
分两个部分：应用合约和交易合约。
应用合约（AC）有三个主要功能：创建、更新和查询。AC主要由Trader调用，来创建区块、查询记录和更新交易状态等。经过分析，查询操作的性能远比创建和更新低。
交易合约（TC）主要包含了排放交易的业务逻辑，主要包含了两个操作：购买和确认。购买即创建交易的过程，使用了算法1：
而确认则是修改项目记录的过程，采用了算法2：
系统结构
整个Fabric包含了：一个Order、一个Channel和两个组织节点。所有的节点都部署在Docker容器中。
客户端和HTTP服务器
采用了Express，一个轻量级Node.js应用来实现web应用和HTTP服务器，并提供了RESTful API。整个交互过程如下：
- 步骤1：使用Fabric CA SDK来注册管理员身份。
- 步骤2：启动HTTP服务器以侦听特定端口并接收来自应用程序的请求。
- 步骤3：根据请求的不同参数，使用Fabric SDK调用目标SC进行一些查询或更新操作。
- 步骤4：以JSON格式将数据返回到应用程序。
Experimental Results and Analysis
本文的实验环境在一个阿里云服务器上：
- CPU：４核 2.5GHz Intel Xeon Platinum 8163
- 内存：8GB
- 操作系统：Ubuntu 16.04(64bit)
作者测试主要使用的每秒请求量（RPS）来表达吞吐量，测试了创建和查询操作。
查询操作的系统吞吐量
创建操作的系统吞吐量
由于共识机制的存在，创建操作远比查询操作消耗的性能多。下表是作者实验时的一些参数：
表(a)显示了不同消息计数下的吞吐量曲线，可以看出，当消息计数到达5时，RPS达到了峰值200。
表(b)显示了不同块大小对吞吐量的影响。当块超过16K之后，吞吐量不再增加。
