基于模块化设计的区块链方案

技术领域

本发明属于区块链技术领域，具体涉及一种基于模块化设计的区块链系统。

背景技术

区块链中存在着著名的三难困境，很多区块链为了高吞吐而向中心化妥协，而另一些则优先考虑安全性和去中心化导致忽略了可扩展性。

关于扩展性，为了使得整体系统的稳定性不变，在设计最新的区块链共识机制时，会根据实际的应用场景以及结合各个方面的特征进行取舍，而在同一链中如果出现多种应用场景则往往无法兼顾多方需求。例如最近的以太坊的共识机制的修改。就是因为其原先的共识机制对环境资源造成了大量浪费。

随着区块链的发展，区块链的底层数据必然是不断膨胀的，全节点的运行成本也将会越来越高，以至于越来越多的节点只能选择运行轻量节点。这些轻量节点没有全部的数据不能对交易和区块进行验证，它们只能无条件去相信全节点，也因此它们所提供的能力十分有限。在这种情况下，如何处理好节点之间的关系和作用就显得十分重要，也因此在节点之间的关系和作用上还值得做进一步的扩展和研究。

类似以太坊、比特币这样的区块链是在一个基础共识层同时实现执行、结算、共识和数据可用性四个功能，而基于模块化设计的区块链则分为多个模块负责这些功能实现。各个模块可以分开在多个节点中运行，在保持相对独立的同时保证模块之间保证完整的区块链系统的正常运行。

实现的模块化设计的区块链中不同的模块均可以当作是一个节点在网络中运行。且每个节点都将设置成其需要的多维度属性在区块链中主要，可以将其主要分成，数据层、网络层、共识层、合约层以及应用层。借助模块化架构，区块链可以通过关注点分离的原则，着手解决区块链可扩展性的三难困境。通过模块化执行和数据可用性层，区块链能够扩展吞吐量，同时通过打破计算和验证成本之间的相关性来保持使网络去信任和去中心化的特性。这就是我们如何在最小化信任的同时扩展吞吐量：允许计算变得集中，同时保持对计算的验证去中心化。

发明内容

本发明针对区块链中单一节点功能确定以及在运行中难以实现功能快速切换、对于不同场景要求的共识不一致、当前主流区块链的TPS不高的问题，提出了一种基于模块化设计的区块链系统，将区块链系统中不同的功能作用划分成不同的模块。

本发明将区块链中的数据层、共识层、合约层、网络层进行拆分，分别部署在不同的容器中数据层和共识层以及合约层通过网络层进行通信，这样做完成了各个模块之间的独立性，在保证整体区块链去中心化的同时我们也可以更加关注每个模块可以更加关注其主要实现的功能。在网络节点中也不必单一节点拥有所有模块才能参与到整个区块链中，它可以选择自己想要的模块运行即可。

本发明包括了模块化设计的基础设施组件、数据库事务管理组件、智能合约引擎组件、可插拔共识组件。基础设施组件包括了提供其他模块调用的加解密算法、用于负责其他各个模块部署的容器管理、各个模块之间相互调用的网络代理，以及给应用层使用的负载均衡器。数据库事务管理组件用于负责整体区块链的数据存储智能合约引擎组件。智能合约引擎组件以及可插拔共识组件分别实现了可以快速更改的满足用户需求的智能合约模块和共识模块。本发明将系统不同的功能作用划分成不同的模块。在链中的每一个具体的节点可以选择指定的多个组件运行，可以选择提供其想要提供的服务，不再拘泥于原先传统区块链的轻重节点的设定。

本发明设计的系统方案如图2所示

应用模块是在区块链节点之上的，负责提供的外部API调用。

数据模块作为整个结构的中心部分，负责和各个模块交接。数据模块将会响应应用模块的调用并执行调用的函数，调用函数可以是请求数据：例如请求账户、余额、历史交易等信息，也可以是交易或者是部署合约(以交易的形式)。

合约模块负责虚拟机智能合约运行环境，支持智能合约的创建、调用及执行等功能。该模块将执行数据模块中关于智能合约的相关请求并将其返回。

共识模块是作为整个区块链核心安全模块，将读取数据模块中的待执行的交易并通过其节点设置的属性将交易进行共识出块返回给数据模块。

各个模块之间及其内部的子模块之间的通信则是通过本发明实现的网络基础设施进行通信的。下面将介绍各个模块中具体的组件。

(1)基础设施组件

a)网络基础设施：为了实现容器化、可插拔的模块，本项目基于TCP/IP协议设计和实现了网络基础设施，提供了模块间RPC通信的能力。其具体模型如图3所示模块A对模块B调用，我们不会设计成A对B的直接调用，而是设计成A请求RPC代理器，具体为向RPC代理器的容器的某个端口(port_1)发送序列化数据，判断相同请求在本PRC通行代理器下有没有可用服务如果没有就有由代理器解析并使用Kad算法发现未知服务，对B做服务发现，并把请求打上标识ID，从port_2把请求内容发送到B，透传函数名、参数表等。在B响应完成后，它会把返回内容发送到port_1，RPC代理器根据ID获知这个响应对应了什么请求，并发送给A。代理可以冗余部署，以缓解服务压力。网络部分主要具有三个特性实现跨机器通信、高内聚低耦合、高性能。跨机器通信是通过支持将不同模块部署在不同物理机或虚拟机上，避免了单实例处理能力受资源限制的问题，同时分布式部署提升了系统吞吐量高内聚低耦合是指不同模块不关心其他模块的具体实现，只关注它能提供的数据和解决的问题，这将会降低开发和维护成本而高性能使用自定义TCP报文，网络负载比HTTP小，在Thrift的基础上，能够更高效地进行二进制的传输，序列化时间更短。

b)容器管理基础设施：而在分布式系统基础设施中，一致性与可用性是最重要的评价标准。容器基础设施为区块链服务提供了存储能力，承载了多节点、可插拔加密组件、世界状态数据库等基础组件，稳定性要求高。在区块链服务中，容器基础设施不仅承载着区块链，还为其提供了基础设施服务。本项目设计与实现的区块链即服务将对外暴露服务，也依赖网络服务实现基于内部数据交换。容器基础设施将依赖自身能力提供高效的网络传输。容器基础设施软件的基础设施如上图4所示，本发明所提出的基于模块化区块链每个可运行的服务都是在容器之中的。服务发布的流程是从容器服务部署引擎中构建或者拉取镜像构建基础的服务镜像然后在容器中启动基础的服务镜像，将服务各个接口暴露在容器的端口上再映射到宿主机的端口中。在同一个宿主机中各个容器都在其自身的内网之中，他们之间是不能直接通信的，是需要通过映射的主机端口暴露出来，通过网络基础设施去相互调用的。在一个宿主机内设立了一个容器状态注册机构并通过调度器轮询端口占用情况将容器分配给对应的端口。

c)服务发现基础设施：其主要包括两块，一块是应用模块对底层区块链的服务发现，另一块是区块链内部的服务发现。应用模块对底层区块链的服务发现如下图4所示。应用模块对底层的服务发现主要是通过服务负载均衡器去实现。这里的服务负载均衡器是把整个下游的底层链当作是一个整体，对于同一个接口对外应用层暴露的是一致的。一般在区块链中发起的API请求大部分都是查询请求，由于查询链上数据在一次出块前无论多少次结果都是相同的，故服务负载均衡器除了负责将查询均匀地打到底层的全部节点上，内部还会加上一层高可用方案。具体结构如图5所示，请求类的服务打到负载均衡器时首先会查询Cache上的数据，然后如果Cache上的数据没有的话将会去查询负载均衡器上的持久化存储的数据，如果持久化存储的数据还没有的话将会把流量最后通过负载均衡的方式打到链上查询，在链上查询完将查询结果缓存到本地的MySQL和Cache中。模块化区块链底层的服务发现则是由Kad路由算法实现的。每个底层服务模块维护一个K桶保证其查询性能的同时预防DDoS攻击。

(2)数据库事务组件：数据存储主要涉及三个方面，区块数据库、世界状态数据库、交易池。区块数据库，存储区块链的每个块的信息的数据库。世界状态数据库，存储区块链中所有账户信息的数据库。交易池，存储区块链当前未执行的交易的数据库。每个块的信息和当前账户信息是紧密关联的，其实当前存储在区块链中所有账户的信息是可以通过从创世区块出发一直到最新的区块计算得出的。而区块中存储的信息是包括将未执行交易拿去执行得出的。世界状态数据库需要从区块数据库获取当前世界状态的根，交易池则是需要获取世界状态数据库中的账户信息，其中存储着一些未被执行的交易，这些交易将会被共识节点读取然后共识节点完成验证后写出新块广播给全网，更新区块链。

a)世界状态数据库组件：世界状态数据库是用于存储整个区块链中的节点中的数据的。世界状态数据库保存的是整个区块链中的所有的账本，本发明将MPT作为世界状态数据库中的数据结构。其主要的架构图如下图6所示。第一层StateDB是用于对外的，用于上层调用并返回结果的。第二层CacheDB是用于快速缓存能够快速地读取，也是如果状态发生修改最先改动的一层。第三层TrieDB则是在第二层CacheDB获取数据没有命中的通过内存向下读取我们内存中的MPT中的账户信息。第四层LevelDB则是用于持久化存储全部的世界状态数据库的信息。如果第三层TrieDB依旧没有命中则会读取底层的KV型数据库LevelDB中的信息。通过上面的描述我们不难发现在我们的世界状态数据库中按照功能划分一共有两种节点类型，一种是用于存放余额直接当作类似钱包方式的账户，而另一种是专门用来存放合约的节点。

b)交易池组件：交易池主要是用于保存应用层发起的交易和从合约模块产出的交易以及其他节点同步的交易。总结一下主要为三个功能：缓存功能、惩罚恶意账号、清理交易。缓存功能是指作为存放交易的缓冲区，大量交易到来时现将未能及时被下游共识模块打包的交易缓存住。惩罚恶意账号为了防止恶意账户发起大量垃圾交易对恶意账号进行惩罚，减少其交易进入交易池。清理交易是指将不符合条件的交易从交易池中移除。具体结构如图7所示。过滤器将会将从合约模块或者应用模块或者其他交易节点同步过来的交易进行过滤，将不符合条件的交易，例如已存在交易池中的或者不符合条件的恶意交易或者余额不足的交易或者不符合当前节点设置的属性的交易移除。同时它也会定时读取暂不执行交易队列、待执行交易队列查看其中的交易是否满足条件，如果不满足则会将交易剔除。同时也会将交易目的地址为合约地址的交易请求到合约模块，由合约模块运行并最终返回到交易池中。暂不执行交易队列是用于存放未来可能会满足执行条件的交易。用于加快交易的执行，保证一些暂时无法执行但是未来可能会执行的交易在进入交易池后被缓存，在未来的某一个时间点能快速转化为可执行交易并进入待执行交易队列中。以此提高交易池的运行效率。待执行交易队列用于存放满足执行条件可以立即被共识节点读取并放到新的块中的交易。从暂不可执行交易队列到待执行交易队列的过程为交易升级，而从代执行交易队列到暂不执行交易队列的过程为交易降级。

c)区块数据库是用来存储每一个块的信息的，在本方案中区块也将如下图分为两部分区块体和区块头两部分区块头应当包含哈希指针以及区块属性世界状态树的哈希以及区块体中所有交易的出交易Merkel值以及出块信息。区块体中主要包含叔父块的哈希指针以及交易信息，为满足DAG结构的区块设计的区块数据库应当是可以允许多个父哈希指针的，所以本发明将在DAG结构的时候将Body中的叔父块的哈希指针也认为是哈希指针，将它们的地位与Header中的父区块计算得出的哈希指针地位等同。具体BlockDB结构如上图8所示分三层第一层BlockDB是用于对外的，用于上层调用并返回结果的。第二层CacheDB是用于对数据进行缓冲，提升读取性能。第三层则是LevelDB作为持久化存储区块信息的底层数据库。

(3)智能合约引擎组件：虚拟机智能合约运行的环境支持智能合约的创建、调用及执行等功能。而将交易中包含的合约字节码提交到区块链作进一步的部署是完成创建的关键步骤。智能合约一旦部署后将无法更改。虚拟机智能合约运行环境支持智能合约的创建，并生成合约地址。智能合约的调用包含在交易当中被提交至区块链，随后在虚拟机运行环境中根据调用的智能合约及方法执行对应的代码。智能合约在交互流程上，首先是开发者在链下通过交易部署到链上，然后用户是通过链下的应用层发起交易向合约地址发送代币去完成智能合约的调用，最后合约与合约之间完成相互调用。通过可插拔式的处理，每次针对不同的智能合约虚拟机，只需要调用其API接口去调用就可以实现对应的虚拟机，如图9所示。

(4)可插拔公式组件：本发明提出的模块化区块链中的共识模块主要负责对区块上的各个世界状态数据库和区块数据库进行同步，保证整个网络上的世界状态数据库和区块数据库保持一致，其具体的架构图如下图10所示。在理论方面，共识算法与数据无关，它是保证节点之间的一致性。但是当落实到实际的操作中，因为共识算法和逻辑过程是紧密相关的，而不同的共识算法想要各个节点达到共识也需要一个逻辑过程，因此这种难以直接解耦的现象给区块链项目的可插拔改造造成了一定的阻碍。尽管想要把共识模块彻底拉出来实现单独的任意的共识是难以实现的，但是对于工作流程比较接近的共识算法，其中单个块为共识对象的算法的更换是可以顺利完成的。本发明提出的基于模块化设计的区块链方案中共识算法的可插拔架构分为三层，第一层为接口层，用于读取共识配置和上游交互；第二层为共识算法框架，指的是主框架可以在不同的独立共识算法中调用统一标准的接口；第三层为共识算法的组合功能模块，如共识对象校验模块、生成区块模块、提案接受模块等。为了保证本发明提出的方案区块在DAG的模式下可以正常运行并保证在共识层不会出现双花的现象，在可插拔共识配置算法中加入了Spectre协议，在每次生成区块后将会进行Spectre共识算法，将原有区块数据库中的一些冲突区块进行舍弃。

附图说明

图1为方案整体模型图示。

图2为方案模块交互模型图示。

图3为网络基础设施图示。

图4为容器基础设施软件流程图图示。

图5服务发现基础设施图示。

图6世界状态数据库组件图示。

图7交易池组件图示。

图8区块数据库组件图示。

图9智能合约引擎组件图示。

图10可插拔式共识组件图示。

具体实施方式

首先系统整体是去实现一个模块化形式的区块链，也就是区块链中的各个组件进行分布式部署，某一个节点可以仅包含整个链中的一个组件，也可以包含链中的多个组件。节点是可以根据需求配置不同的组件参与到整个区块链网络中的。也因为采用模块化的思维，整个区块链网络中区块之间的组织形式、共识方式、智能合约引擎是可以快速切换的、可插拔的。有了模块化的执行层和数据可用性层，区块链可以扩大计算规模，同时通过打破吞吐量和验证成本之间的相关性，保持让网络去中心化的特质。在性能上，在切换成吞吐量最大的配置的时候，也就是使用DAG结构的时候，理论性能应当与目前市面上的DAG结构的区块链的性能看齐达到千级的TPS。其他场景下能够兼容多种智能合约的引擎。

该系统在区块链上是可以实现共识可插拔、智能合约引擎可插拔并且可以切换区块链的链式结构为DAG结构，可按照节点属性进行划分，不同属性的交易进入不同的节点去完成合约执行和共识出块。在看板系统上我们可以通过浏览器对区块链上的资产进行查阅，也可以发起交易、部署合约、执行合约。由于最终实现范例系统为看板，故我们将整个项目命名为KanBan，所使用的区块链命名为KChain。

(1)基础设施：首先实现我们模块化数据库的底层通用组件KBB(KanBan Base)，这一块包括对后续其他模块会使用到的加密模块的Krypto以及用于各个模块之间的RPC调用的KPS以及用于部署各个模块的容器调度器Kether。

Krypto对于后续的各个具体模块的加解密提供SDK调用，本发明使用Golang实现了Krypto SDK库，Krypto由KanBan和Crypto两个字取前后拼接而成，意为KanBan系统的加密算法。实现了国密SM2加密算法，用于加密、解密、签名、验签以及KECCAK256用于哈希加密。

使用Golang实现了KChain的底层RPC通行组件命名为KanBan Proxy Server简称KPS，意为看板系统的远程代理服务器，主要就是实现3.5.1中的RPC通行代理以及Kad服务发现算法。

KPS作为KanBan系统中的区块链各个模块之间的通行KPS与KPS之间和KPS与下层模块之间均使用了高性能使用自定义TCP报文，网络负载比HTTP小，在Thrift的基础上，能够更高效地进行二进制的传输，从而使得序列化的时间缩短。

Kether使用Golang实现的供本发明的KChain的基础区块链基础组件使用的容器基础设施，并使用Redis用于调度和管理Docker容器，名为Kether。

由于使用Redis部署管理单一主机内的容器，所以理论上性能肯定是能满足任何服务之间调用的需求的。

Kether的使用步骤。

1.拉取Kether源代码

2.在使用Kether的主机端口部署Redis

3.创建Kether网络，查询网关IP并填充YAML文件关于网络套接字映射

4.在拉取容器镜像，在容器中部署服务

KLB本发明使用Golang实现了一个负载均衡器KLB(KanBan Load Balance)，负载均衡器是在链外使用供外部API请求的。

其内部为一个Redis数据库作为Cache来供外部请求数据的请求直接读取，在Redis后是一个MySQL用于存储访问过的请求。由于负载均衡器需要扛住大的并发流量，所以网络通行上没有采用KPS的Kad路由算法，而是采用中心注册机制，在Redis中新建了注册机器，每个新建的KPS服务都会在KLB中注册，由KPS均匀分发外界的请求到各个KPS中再由各个KPS进行服务的转发。最终KLB内部的分散算法采用源地址取哈希然后取模运算均分地分散到目标服务器中。

(2)数据库事务组件

数据库事务管理是负责整体区块链的数据的保存和使用的，我们将整个模块命名为KanBan Database简称(KBD)，其中主要包含世界状态数据库，交易池和区块数据StateDB

世界状态数据库组件：使用Golang实现基础模型Merkle Patricia Trie然后设置内存Cache并底层接入LevelDB作为持久化层。接下去具体讲一下世界状态树中存储的状态节点的具体存储字段，如下表所示。

address字段用于存放状态节点的地址，也就是从世界状态数据库中获取某一地址信息的key。

balance字段用于存放状态节点的余额，也就是将被共识模块拿去读取验证一笔交易是否满足余额的要求的关键。

nonce字段用于存放状态节点交易位次，通过nonce字段实现防止双花。只有当不同的账户从相同的节点进行交易时，nonce字段的数值才会开始从0计数，而每成功交易一笔，nonce的字段值会相应地加1。此外，后续的nonce值处理是依据当前的nonce值是否处理完成。

code字段用于智能合约代码的存储。

remove字段用于存放状态节点是否被移除。

isSync字段用于存放状态节点是否已被修改。被修改的节点将会在CacheDB层保存但是并没有直接写入到TrieDB和LevelDB中。只有当整个Trie的内容写入底层的LevelDB的时候才会把数据写入。因此需要isSync来标识数据是否已经被同步到底层，从而避免多次不必要的写入数据到LevelDB作持久化存储。

交易池组件：使用Golang实现了基于模块化设计的区块链的交易池，我们命名为KBPool(KanBan Pool)，KBPool使用接受来自应用层发起的交易合约层产出的交易以及从其他KBPool同步过来的交易。由于交易池是被共识模块读取的，所以在运行性能上的要求并不高。

交易的数据字段有七个如下表所示。

nonce为世界状态数据库中传入的nonce值用于防止双花。对于nonce值大于当前系统中nonce的交易本发明称之为未来交易，是在当nonce值在两者之间的交易全部被执行完后才能执行的交易。

property为当前交易的属性，property将按照无符号64位整型存储，按照具体系统可定制化其属性的作用，由于property的存在从此层面上实现了模块化区块链的分片。其可以按照bitmap形式划分，也可以按照类似身份证地区的划分，这个需看具体使用场景中的要求。

price为交易的花费，花费的值根据不同的property是可以为0的但是不能为空。

limit为交易的最大花费值。

recipient为接受交易的地址，和地址根据世界状态数据中一致，最终的接受者可以是具体账号也可以是一个智能合约地址。

amount为转移的代币数量，为64位整型。

VRS为签名信息，签名信息会根据property的不同所含有的信息不同，共识模块最终根据property对每笔交易通过不同的共识算法进行验证。

交易池中交易的升级和降级规则，本发明最终在交易的升级和降级后将发生的信息反馈给过滤器，过滤器将进行如下表所示的调整。

区块数据库组件各个字段如下表所示

property是区块的属性，按照共识出块节点的属性定义，在出新块的时候将会读取此字段，仅会同步对应的属性的区块。

parentHash主要用于记录父区块的哈希值，创世区块在parentHash字段可为空，而其他区块在此字段不可为空。也就是hash指针，整个系统方案的不可篡改主要靠这个保证的。

coinBase是用于记录出块节点对应的地址的。

stateRoot世界状态的哈希，用于确定当前区块下的世界状态。

txRoot本区块中的所有交易按照默克尔树的方式取的hash。

number记录当前的区块号。

time记录当前区块的出块时间。

nonce满足出块的条件，根据共识模块中不同的共识，其含义会稍有变化。

区块中主要含有两个字段如下表所示

ommers里面记录的是叔块们的哈希值，在共识节点不采用Phantom协议或者Spectre协议的时候叔块的交易是不被执行到主链中的，当共识采用Phantom协议或者Spectre协议时，整个区块链的结构将会采用DAG结构。

transactions用于当前区块中完成的交易。

(3)智能合约引擎组件

使用Golang实现了可插拔式智能合约引擎KBE(KanBan Engine)，改造了以太坊所使用的EVM虚拟机的独立运行，但是由于LUA虚拟机迁移进模块存在一定难度最终没有实现LUA虚拟机，但是在接口层面上在EVM上增加了一层API接口用于给其他模块调用，以此实现可独立运行智能合约引擎的可插拔。

(4)可插拔共识组件

使用Golang实现可插拔式共识模块KBC(KanBan Consensus)，内部实现了Raft和PBFT两种共识协议，可通过配置文件快速进行共识修改，同时在此基础上还实现了Spectre协议，当开启Spectre协议后，区块数据库将可以开始采用DAG结构。DAG结构也是本发明实现系统的吞吐量的提升的关键。

模块兼容问题：

其中我们可以发现数据模块的StateDB和BlockDB是必须有一个固定的共识模块KBC用于同步全网的数据库。也就是说StateDB和BlockDB这两个组件是需要和KBC存在一定耦合的，如果单独的StateDB或者BlockDB没有对应的KBC那么该节点上的StateDB或者BlockDB将是不可信的。具体耦合关系如下表所示。

我们联合BlockDB和StateDB对共识出块速度进行测试。测试环境如下表所示。

由于系统配置限制故最多开启12个BlockDB和KBC组，并将StateDB和KBPool部分直接采用固定返回值的形式进行返回，返回800笔交易，这是远超单个BlockDB中一个区块内的交易数量的。最终我们对KBC的性能测试得出如表所示。

由表可得在开启Spectre协议后共识速度上大幅度提升，同时减去直接验证出块的共识时间，我们可以发现在小型网络中本发明实现的PBFT性能是弱于Raft的，尤其是当关闭Spectre协议，使用传统区块链的结构是PBFT协议的速度为Raft协议的7倍。对出块的块中的交易数量进行统计，统计结果如下表所示。

由于系统开销运行，本发明最终在系统中搭建了完整一套运行体系，在不开启Spectre协议时并采用Raft协议根据5.2.7中的测量结果我们可知353.33/0.325≈1087(TPS)，理论上共识出块的时候采用Spectre协议之后如果有更多的共识节点一起出块，在出块速度上还能够进一步提升，使其无限接近于仅验证直接出块，也就是353.33/0.113≈3127(TPS)。同时我们能够更改配置，将共识由Raft切换成PBFT。也可选择关闭Spectre协议式区块链结构退化为原有的单链结构。同时我们的每一个主机内可以仅部署KBPool作为交易池，也可以在此基础上继续部署StateDB或者BlockDB，但是这两个的部署将会依赖于KBC的部署。而我们的每一个组件除了与上层的外部API对接的KLB之外，均是部署在Kether，这也保证了我们模块化设计的高效和高粒度的机制。

本发明立足于区块链环境下区块链性能不足和共识协议兼容性的问题，提出了一种基于模块化设计的区块链方案，在可扩展和去中心化上进行一定的突破。

本发明的主要贡献在于：

1.基础组件与网络上，实现了KLB用于负载均衡以及拦截部分请求、实现Krypto用于生成公私钥、加解密、签名、验证签名。实现了KPS用于整个模块的网络基础运。以及Kether用于将组织模块置于容器中运行，保证了各个模块可以在多环境下运行。

2.数据库事务管理上，设计了支持多属性可以完成保证快速出块安全的区块链数据库事务管理系统KBD，支持按交易属性进行不同的共识合约走向，可以将区块链按照DAG的方式组织起来。实现了世界状态数据库StateDB支持分布式部署。同时实现了交易池KBPool支持多属性管理且能预防DDoS攻击。

3.智能合约引擎上，实现基于堆栈的预编译字节码智能合约运行环境实现了KBE。在运行环境外层通过API结构封装保证运行环境可以独立运行实现可插拔。

4.分布式共识机制上，实现可插拔式共识模块KBC从而使得其具有灵活、精细的权限控制机制。有效保护区块链环境中的数据隐私。

5.实现了区块链浏览器中用于浏览和使用所实现的基于模块化设计的区块链系统。

各个组件部署在相应的容器之中，组成我们最后的模块化区块链，各个节点可以设置其相应的多维度属性且其可以仅保存一个或多个模块实现的，合约可插拔、共识可插拔、高性能的模块化区块链KChain。并通过浏览器对区块链进行使用。