1总体介绍

基础模块：P2P、算法库、账本、共识、虚拟机 客户端通过控制器与链交互，客户端发起一笔交易的流程： 1、控制器收到交易调用安全验证模块，交易的合法性校验。 2、调用交易管理模块，对交易进行处理，校验资源使用情况、放进交易池。 3、共识模块将交易池信息进行打包，写进账本。 4、将出块的消息发送出来。

2链控制器

链控制器作为核心，负责协调系统内部的各个模块，并且客户端需要通过链控制器才可以与区块链交互，链控制器主要有以下几个功能：安全验证管理、资源管理、交易管理、交易池管理、块管理、链信息管理。 链控制器结构体如下：

struct controller{
链ID       
链配置信息
    链DB      
安全验证管理//权限验证接口
资源管理 //资源限制接口
交易池管理    //未打包的交易数据和交易收据
    虚拟机接口  //用于执行交易时调用
内置合约接口 //执行内部合约时调用
信号管理  //发送给其他模块信息
}

链ID：链的ID信息 链配置信息：文件的存储目录、账户信息、限制信息（交易执行时间、交易大小、块大小、权限认证深度、黑白名单）等。 链DB：存储链数据。 安全验证管理：安全验证接口，用于交易的安全验证。 资源管理：资源管理模块接口，用于使用资源管理功能。 交易池：交易池接口，用于管理交易池。 虚拟机接口：用于调用虚拟机执行合约。 内置合约接口：用于调用内置合约。 信号管理：用于节点同步数据，P2P模块会订阅消息。 链控制器功能： 控制器本身需要完成很多工作，作为智能合约平台，主要是对收到的交易和块的处理，并且对外提供链信息接口，用于外部访问。

2.1安全验证管理

安全验证主要是对交易的账户权限、交易签名信息、交易的时间等验证，实现交易的安全检查。

2.2资源管理

资源管理实现对交易使用的资源控制，比如cpu、net等资源。

2.3交易管理

交易管理将合法交易进行处理，分两种情况： 普通交易：立即执行，将交易及交易的执行结果写进交易池。 延时交易：缓存到数据库，等时间到了，矿工在打包块时先去执行延时交易再出块。

2.3.1交易结构体

签名交易：主要由交易信息和交易的签名组成。

struct 签名交易{
交易
签名信息
}
struct  交易{
交易头//
交易ID //
action 列表//交易包含的action
}

交易ID：交易的hash值，用于交易处理时识别不同的交易。 action列表：智能合约里面定义的action，可以有多个。

struct 交易头{
交易到期时间
最大net使用
最大cpu使用
延时时间 
}

交易的到期时间：交易的有效期。 最大net使用：该交易能使用的最大带宽。 最大cpu使用：该交易能使用的最大cpu。 延时时间：该交易延时执行时间。

struct action{
合约账号
action名
许可列表
action数据
}

合约账号：智能合约账号。 action名：智能合约的某一个action。 许可列表：执行该action需要的许可信息。 action数据：执行action时外部传入的参数信息。

2.3.2 交易收据

对交易处理完后，会生成交易收据和action收据。

struct 交易收据{
交易收据头
交易数据
}

交易数据：处理前的原始交易。

struct 交易收据头{
状态 //
cpu使用 //
带宽使用 //
}

状态：指明当前交易执行后的状态，执行完成or软失败or硬失败or延时or超时。 cpu使用：该交易使用的cpu。 net使用：该交易使用的net。

struct action收据{
账户   //action所在账户
action执行的次数
}

2.3.3 交易跟踪

交易在执行过程中，会有一个跟踪信息，可以用于其他模块跟踪交易处理的状态。

struct 交易trace{
交易ID
交易收据头
action_trace列表
异常
}

交易ID：当前处理的交易。 交易收据头：上面已经定义，主要是交易的执行状态和cpu、net的使用。 action_trace列表：每一个action执行时都有一个跟踪信息。 异常：交易执行时发生的异常信息，比如cpu、net不够了，交易超时了等异常。

struct action_trace{
交易ID
action收据
action名
}

交易ID：action所属的交易。 action收据：执行action生成的action信息。 action名：当前执行的action的名字

2.3.4 交易上下文

每一个交易在执行前都会创建一个上下文环境，交易执行完后生成一个交易trace，延时交易也会有一个交易trace。

struct 交易上下文{
控制器//
签名交易//
交易ID//
交易trace//
交易起始时间//
交易延时执行时间
交易deadline
action收据// 写进交易池
资源使用//包括资源限制、资源计算账户、资源使用情况等
}

2.3.5 执行上下文

每一个action执行前都会创建一个执行上下文环境，执行上下文会提供API给合约，合约代码可以改变执行的上下文，action执行完生成一个action trace并写进交易上下文的交易trace中。

struct 执行上下文{
控制器
状态DB 
交易上下文
action名
action的账户
action trace
通知的账户列表
}

状态DB：来自控制器，action执行时会改变状态 通知的账户列表：执行该action时可以执行相关账户的action，该列表可以通过合约代码改变。

2.4交易池管理

交易池维护一个待打包的块信息

struct pending{
pending_block //待打包的块
action_receipt 列表 //action执行的结果
状态信息
}

action_receipt列表：action执行后生成的收据信息，一个交易单中的每一个action都会生成一个action_receipt，出块时计算其默克尔根存储在block中。 状态信息：出块时针对不同的状态作相应的处理。

struct pending_block{
    区块头
交易列表//处理前的交易
交易收据//
}

交易列表：收到的交易集合。 交易收据：交易执行后生成的收据信息。

struct 区块头{
时间戳
生产者
前一个块ID
交易默克尔根
action_receipt默克尔根
块ID
块号
签名
公钥
不可逆块号
生产者列表
}

2.5 块管理

根据共识机制获取出块者，实现交易的打包，执行其他节点同步过来的交易和块信息。

2.6 链上信息

提供外部访问区块链的接口，比如获取链ID、交易信息、块信息，矿工信息等。

3 基础模块

3.1 P2P模块

订阅控制器的消息，有块或交易发送时转发，收到交易或块时交给控制器处理。

3.2 共识模块

负责出块，同步信息，会调用控制器写DB。

3.3密码算法库

对称算法：AES HASH算法：SHA-2、SHA-3 非对称算法：ECDSA

3.4数据库

负责存储数据，在控制器中提供一个接口给其他模块使用。

3.5虚拟机

负责执行合约，在控制器中提供一个接口给交易处理使用。