一文看懂迅雷链技术栈和架构设计思路

戳蓝色字“区块链硬件”关注我们哟！

随着区块链 3.0的技术革新，在保证区块链本身公开、透明、防篡改特性的基础上，还需要能够支持商业级别应用的高性能底层平台。迅雷链就是这样的一个底层平台，企业和个人开发者可以按需上链，打造可大规模使用的区块链应用。

在迅雷建立的“区块链 +共享计算”的模式中，迅雷通过多年积累的无限节点调度和使用等创新技术，将用户的闲置存储、计算、带宽等资源转化为云计算服务，输送给需要这些资源的企业客户，而区块链技术在其中帮助量化用户的贡献，激励用户尽早加入共享计算的建设。

据了解，迅雷目前已经有 150多万个共享计算节点，而且还在快速增加，不断扩大的用户规模也对迅雷区块链技术提出了挑战，为了应对这一难题，迅雷链提出同构多链框架，每秒处理的并发请求量可达百万，使得迅雷链具备了可以作为区块链 3.0时代主链的条件。下面来看看迅雷链系统架构和同构多连框架的设计思路。

1

迅雷链的技术栈与重点模块介绍

下图为迅雷区块链的技术栈，可以直观的看出各模块的分工和协作。

最上层的应用层，是 C端用户直接接触到产品和服务，包括账户客户端、第三方客户端和合约应用。

其中，合约应用是指基于迅雷链开发的 DAPP。应用中使用的合约通过服务层的“合约部署”服务部署到区块链上。DAPP中的合约调用通过服务层的“合约调用”模块进行校验，合法的才会转到链上处理。

中间的服务层作为应用和链之间的桥梁，提供应用层需要的接口和服务。包括安全控制、合约部署、合约请求和数据请求服务。

其中，合约部署的触发主要是迅雷链内部的审核系统触发，只有企业资质审核通过并且产品内容合法合规，才会被部署到迅雷链上。同时，迅雷链是同构多链框架（下文会详细介绍），合约会有自己所属的链，并在该链上完成合约创建。而普通链上的用户发起合约调用时，用户所在链请求入块后，需要知道将该请求和区块路由到哪个链上，所以合约部署时还需将合约的路由信息通知到所有链。

而数据请求服务模块，包含链克相关的所有请求，包括查询余额、查询兑换记录、执行兑换等。对于余额、兑换记录这类请求量很大的模块，会在所有接入节点上做缓存，每个节点通过基础层的“订阅及通知服务”订阅区块信息。当收到区块产生的通知后，可以立即解析区块内信息，并修改缓存中的余额和兑换记录。对于执行兑换的请求先校验合法性，再将合法请求转到基础层。

最底层也叫基础层，是构成迅雷链最核心的组成部分，由 11个模块组成。

其中，共识模块包括共识算法和校验。这是区块链与分布式存储服务共同的核心模块，区块链的共识比普通的分布式存储服务多了一些安全上的校验，比如日志。所有参与共识的节点需要对区块校验其内部数据的合法性。至于如何达成共识就跟共识算法有关了，迅雷链采用的共识算法是 pbft，具体算法的原理和选择理由下一次分享会继续介绍。

智能合约模块：迅雷链上有越来越多的应用在接入，这些应用的业务逻辑代码其实就是智能合约。而智能合约代码是独立于区块链程序的，所以需要在区块链程序中运行虚拟机来解释和执行。再者，智能合约里面需要读取和修改区块链上的数据，所以虚拟机还要提供方法来与区块链交互。

数据存储部分：包括区块、原始请求和用户数据。相比于以比特币为代表的 UTXO模型，迅雷链选择了基于账户模型，方便支持智能合约。迅雷链的本地存储系统选择的是 leveldb，在数据存储的结构上借鉴了以太坊的精髓，包括交易树、账户树、事件树。每种树都是一个 merkletree，在区块头部只存储树的 root的 hash。

密码学模块：包括签名和加密。这也是区块链非常核心和独特的模块，区块链的不可篡改、隐私保护等特点都是源于此，涉及签名、摘要计算、公私钥对的生成等。

网络通信模块：包括 P2P和 RPC。区块链中所有参与的记账节点都是对等的，记账节点之间包括请求、区块等信息都需要网络送达，当然要做一个健壮的区块链网络，在网络通信模块还需要不断优化。

通用模块：包括压缩和事件机制。因为账户模型里要存储的数据信息相对较多，而且随着时间推移，链的长度也越来越大，所以数据落盘前需要压缩。事件机制主要是为外围系统提供链上执行合约、链上区块产生等底层支持。

2

案例：上链请求的执行过程

以用户在客户端应用中发起链克兑换为例。

链克口袋将请求发到链的服务层——从架构角度看的最外层就是接入层；

接入层会根据 from（发起方）地址将请求路由到对应链的链，接入层也会判断请求的合法性，针对非法的请求直接返回失败；

外层验证 ok后，会进入服务层——从架构角度看的内层，会验证请求是否为重放、余额是否不足等；

服务层验证通过的请求到达基础层——从架构角度看就是我们的记账节点，也叫验证人；

记账节点之间转发请求，记账节点中本轮的 proposer负责发起区块，区块数据在几个记账节点之间也相互转发，收到区块的节点进行投票，并把投票信息广播，根据我们的 pbft共识算法记账节点达成共识，区块入链；

新区块产生后，记账节点中链间通信的模块会针对新区块中涉及跨链的请求，依次根据请求的目的链，将跟该目的链有关的请求原始数据、本链的区块头信息、本链的交易证明信息等转发给目的链的记账节点；

目的链的记账节点将收到的信息转发，并达成共识，将请求写入目的链区块的同时也完成了目的链对应地址的余额增加。

3

同构多链框架的设计思路

所谓同构多链框架，顾名思义就是有多条链，每条链上都运行相同的程序。不同用户的请求会发到不同的链上进行处理。

当 A、B、C、D同时发起请求，比如有 A->B，A->C，A->D , 同时有 B->C, C->D，D->E。A、B、C、D根据路由规则落到不同的链上，四条链可以并行进行处理，如果一条链每秒的打包请求并落区块的速度是 1000，那么上千条链，就可以达到百万 TPS。

对于普通请求，消耗的链克 gas是固定的，这种链间的处理是相对容易的，而支持智能合约，需要一些额外的处理。因为要防止恶意的合约或者合约本身的 bug导致占用大量资源，所以需要根据合约执行情况扣除相应的链克 gas。

消耗的链克 gas是需要从请求发起方的账户里扣除的，而真正执行合约的是在合约所在的另一条链，所以最终需要的具体数量，在发起请求方所在链入链这笔请求的时候尚未可知，这怎么办呢？

解决办法是在发起方所在链扣除请求中传入的 gasLimit值，也就是用户指定的上限值，这个请求入块后同步到合约所在链，合约执行后请求入块能知道这笔请求真正扣掉的通证数量，再通过链间通信将链里面入块的合约调用请求同步到发起方所在链，发起方确认合约链的区块数据，并把多扣掉的通证退回给发起方。这些对账户余额的操作在链上都有相应的操作记录写入，方便对账。

前文介绍了整体吞吐的提升主要通过增加新链的方式，那怎么能做到轻量地增加新链呢？

迅雷链的路由规则选择的是最简单直接的针对地址取模，比如针对 1024取模，因为地址是根据公钥经过 hash运算出来的，整体随机分布，所以基本上所有用户会平均分布到这些链上。

以当前有 1024条链举例，其编号从 0到 1023，地址取模结果是 1、1025、2049、3073、……会落到 1号链。 那么当我们想扩容到 2048条链的时候，实际上是原来每条链上的一半用户迁移到新链。新链启动时区块数据来自原来的链，比如 1025号链的数据来自原来的 1 号链，原来在 1号链上地址取模为 1025、3073、……的用户数据之后会都落在 1025这条链；而原来在 1号链上地址取模为 1、2049、……的用户数据之后还在 1号这条链上。

通过这样的方式，可以让扩链的整体变动最小化。

.End.