TPS百万级的超级区块链架构解析

作者｜区块链名媛

这次有幸邀请到迅雷链总工程师来鑫跟大家聊聊迅雷链的同构多链框架。

迅雷自 2004 年开始创业，到 07 年就与 QQ 并肩风靡一时。随着互联网技术的发展和用户需求的变化，迅雷调整了业务战略，从 2014 年起，开始涉足云业务，并给迅雷带来连续 8 个季度的营收增长。迅雷基于成熟的分布式技术优势和庞大的用户基础，使玩客云迅速占据市场。

随着 2017 年区块链技术的兴起，让迅雷看到了更适合的商业逻辑：将区块链技术应用到共享计算上。这一过程对于迅雷本身而言，是把区块链技术与共享计算技术相结合，保证复杂的“共享计算资源有偿共享和使用”机制，实现即时性、安全性和公平性，从而对用户的分享行为起到激励作用。这是迅雷发明的创新型共享计算模式。

她叫来鑫，是迅雷链的总工程师

曾在百度参与建设分布式计算及网页搜索架构，后担任腾讯云高级工程师，主导去中心化负载均衡系统的大规模使用，以及分布式消息队列服务、信鸽移动推送、应用加固等多项技术研发。在分布式计算领域拥有丰富的经验。

2015 年加入迅雷，负责星域调度系统的技术研发，目前主导玩客云及区块链业务方案设计，建设共享计算的区块链底层平台。个人拥有分布式计算多项专利。

迅雷链在做什么？

随着区块链 3.0 的技术革新，在保证区块链本身公开、篡改、透明特性的基础上，还需要能够支持商业级别的高性能的底层平台技术。迅雷做的是云计算服务，同一般的后台服务一样，需要通过平行扩展来提高性能，这样的技术一样能够用到区块链上。

例如，24 核服务机器可以做到每秒 2000TPS 的处理，一个超级节点需要 120 核，每秒能够处理 3000TPS，这已经是很理想的状态了。但如果做到 100 万 TPS 就需要 500 组，成本需要上亿。而这对于迅雷来说并不需要花那么多钱买机器，因为迅雷有上百万的共享计算的节点。共享计算是把老百姓家里闲置的带宽跟企业所需要的带宽有效的结合起来，提升整个社会资源配置效率。

那么，区块链起到一个什么作用？区块链做的事，就是能够平衡供给方和需求方的权力义务关系，让分散的个体，能够平等的与企业对话，从而激励用户自发地参与到共享计算的体系中来。现在已经有了百万级的共享计算节点，而且还在快速增加，这是迅雷追求区块链技术高性能的动力和来源。

迅雷链的系统架构是怎样的呢？

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

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

账户客户端：主要指迅雷链的链克口袋，负责管理链上资产。用户可以通过链克获取网络加速、数字内容等多种增值服务。而链克的查询、兑换请求是通过服务层的“数据请求服务”提供的接口来完成。另一方面，链上资产如果是依托于某个智能合约，这部分资产的查询和信息修改，就需要通过服务层提供的“合约调用”接口转发到基础层的链上执行。

第三方客户端：主要指接入链克兑换的产品和服务，比如迅雷直播。用户在这些应用中使用链克兑换产品和服务，会命令链克口袋相应链克。如果是在 pc、电视端等发出的请求，会弹出二维码响应。服务层的“数据请求服务”会跟第三方客户端的后台服务交互，通知兑换信息是否入链成功。

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

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

安全控制：这一层类似互联网架构的接入层，其核心功能就是做好鉴权、合法性校验等安全工作，将问题挡在最外层。

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

合约调用：检查合约调用接口中参数的合法性，比如合约地址是否存在等。对于不合法的请求直接返回失败，合法的请求会转发给基础层。

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

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

路由模块：包括普通请求路由和合约路由。当请求到达时，路由模块会根据请求中 from（发起方）地址，将请求路由到该用户所属的链；另一方面，当请求入块，需要链间通信将请求和区块信息同步到目的链时，也需要路由模块的信息。

跨链模块：包括链间通信和跨链确认。该模块将已入链的区块中，需要跨链的请求、证明信息、区块信息同步到对应链。

订阅通知模块：该模块是为了支持“数据请求服务”功能，需要及时拿到新入链的区块数据，比如监控服务、余额查询服务等。

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

账户管理：主要是账户密钥的生成，这部分会做成库给账户客户端使用。另一方面是对账户的权限管理。

请求池：收到的请求需要在这里等待校验合法性，通过后被放入等待入块的队列。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

从使用的角度再看同构多链框架

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

当 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 号这条链上。

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

整体分享下来，我们发现，迅雷一直在根据自身优势确定技术方向。正如来鑫所说：“做技术重点是解决问题，而不需要对标什么”。在分享结束后的 QA 环节，我们收集到很多有针对性的问题，来鑫都一一做了解答。

（原创文章，转载请注明出处）