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

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

随着区块链 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.

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20181114B0Z3CG00?refer=cp_1026

扫码关注云+社区