前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >谁说高颜值女神做不了技术?她偏做,还是百万级主链!

谁说高颜值女神做不了技术?她偏做,还是百万级主链!

作者头像
区块链大本营
发布2018-06-19 18:41:42
5201
发布2018-06-19 18:41:42
举报
文章被收录于专栏:区块链大本营区块链大本营

记者 | Aholiab

编者注:以下内容根据迅雷链总工程师来鑫采访整理,并获得独家授权,未经许可不得擅自转载。

还有20来天,万众期待的EOS主网就要上线了,公链的战场里又会入场一个大玩家。在中国,迅雷在4月末也推出了一个区块链平台迅雷链,与以太坊等明星公链广受诟病的TPS过低不同,迅雷链在推出时就号称「百万量级」。

公链的百花齐放代表了区块链技术向大中渗透的良好开始,但公链涉及的技术、生态、安全等因素,使得真正落地并且在一众角逐中胜出务必艰难。那么迅雷链究竟是一个怎样的平台?它诞生的背后有哪些故事?它跟其他公链又有哪些区别呢?

带着这些问题,区块链大本营(ID:blockchain_camp)近日采访了迅雷链总工程师来鑫。以下为采访实录。

来鑫,2015年加入网心科技,负责星域调度系统的技术研发,目前主导玩客云及网心区块链业务方案设计,建设共享计算的区块链底层平台。此前曾在百度参与建设分布式计算及网页搜索架构,后担任腾讯云高级工程师,主导去中心化负载均衡系统的大规模使用,以及分布式消息队列服务、信鸽移动推送、应用加固等技术研发。

百万TPS如何实现?

区块链大本营:请介绍一下迅雷链的核心架构。

来鑫:迅雷链主要的两个创新是同构多链框架(homogeneous multichain framework)带来的横向扩展能力和共识算法的更新。从模块层级上分成三层:应用层、服务层和基础层

最底层我们称为基础层,是构成区块链的最核心组成部分。最上层的应用层,是ToC端的用户直接接触到的产品和服务。中间的服务层作为应用和链之间的桥梁,提供应用层需要的接口和服务。

应用层主要包括:

  • 账户客户端,主要指迅雷链的链克口袋,负责管理链上资产;
  • 第三方客户端,主要指接入链克兑换的产品和服务,比如迅雷直播。用户在这些应用中使用链克兑换产品和服务,会调起链克口袋扣除相应链客,如果是PC、电视端等会弹出二维码。服务层会跟第三方客户端的后台服务交互,通知兑换信息是否入链成功。
  • 合约应用,主要是指基于迅雷链开发的DApp。

服务层主要包括以下部分。

  • 安全控制:这一层类似我们做互联网架构的接入层,在这里一个核心的功能就是做好鉴权、合法性校验等安全相关的工作,将问题挡在最外层。
  • 合约部署:合约部署的触发主要是迅雷链内部的审核系统触发,只有企业资质审核通过、产品内容合法合规的才会部署到迅雷链上。
  • 合约调用:检查合约调用接口中参数的合法性,比如合约地址是否存在等,对于不合法的请求直接返回失败,合法的会转发给基础层。
  • 数据请求服务:这个模块涵盖了跟链克相关的所有请求,包括查询余额、查询兑换记录、执行兑换。

最后再说说基础层,基础层的模块比较多,我挑重要的简要介绍下。

  • 路由模块:当请求到达的时候,路由模块会根据请求中的from地址,将请求路由到该用户所属的链;另一方面,当请求入块,需要链间通信将请求和区块信息同步到目的链的时候,也需要路由模块的信息。
  • 链间通信模块:将已入链的区块中,需要跨链的请求、证明信息、区块信息同步到对应链,是同构多链框架的重要组成部分。
  • 订阅通知模块:一些外围的服务,需要及时拿到新入链的区块数据,比如监控服务、余额查询等服务。
  • 共识:这是区块链等分布式存储服务共同的核心模块。
  • 数据存储:相比于以比特币为代表的UTXO模型,迅雷链选择了基于账户模型,方便支持智能合约。
  • 密码学:这也是区块链非常核心和独特的模块,区块链的不可篡改、隐私保护等特点都是源于此,涉及签名、摘要计算、公私钥对的生成等等。

区块链大本营:迅雷链号称可以做到每秒百万TPS,请问原理是什么?

来鑫:区块链技术的本质是什么?我理解应该是分布式存储,加上了密码学的技术。我们做分布式存储,跟平时做后台服务一样,性能要高,要能够平行扩展,比如怎么提高MySQL集群的吞吐,那就是分库分表,这个理念一样能够用到区块链上。24核服务机器可以做到每秒2000 TPS的处理,按照这个还算不错的性能来算,如果做到1000万TPS,那就需要500组。10台机器500组就需要5000台机器。整体算起来是要有1亿元的投入。

我们的做法是通过「玩客云」的智能硬件节点,将用户分享的计算资源转发为云计算服务,这些节点现在有百万级。虽然共识协议能达到去中心化的目的,但网络中的每个全节点必须处理每个交易,这直接导致了吞吐量低和交易形成区块的时间慢等问题。

刚才提到的「同构多链框架」的做法是它有多条链,每条链上都在运行程序。不同用户的请求会发到不同的链上从而进行并行处理。当A、B、C、D同时发起请求,比如有 A->B,A->C,A->D , 同时有B->C, C->D,D->E。A、B、C、D根据路由规则落到不同的链上,四条链可以并行进行处理,如果一条链每秒处理的请求是1000笔,那么只需上千条链,就可以达到百万TPS。这一思路和理念跟我们做服务器架构有类似之处,比如要提高MySQL集群的吞吐,会做分库分表,从而能够平行扩展。

算法与合约

区块链大本营:在共识算法的算选择上,会考虑哪些因素?

来鑫:共识算法上,根据CAP定理:P是必须选择的,剩下的在C和A里面去选,三者不可兼得。POW选择了A,带来的问题是可能存在分叉,所以请求的确认时间很长,对于想大规模使用的ToC应用是不适用的。所以我们选择的是PBFT算法。

区块链大本营:也有人说PBFT不太适合公链上的多并发场景,你怎么看?

来鑫:这里是两个问题:第一,PBFT是否适合公链,以及PBFT是否可以应对高并发。我先解释应对高并发,单纯的PBFT算法,随着记账节点增加性能会下降很快,性能瓶颈很容易触到,所以单链应用PBFT整体性能是固定的,所以我们同时又创造了同构多链框架,让整体性能不局限于单一链的性能。

另一个问题是PBFT是否适合公链。现在的公链其实已经不像以太坊或比特币那种了,将来发展的主流区块链技术也不会是之前那种谁都可以记账的模式了。节点太多共识肯定慢,共识慢请求结果就慢,就没法在toC的应用场景中落地。就像人一样,人多了参与决策就肯定会慢。所以如果以后想往性能高的方面去发展,最好是选一些可信任的节点去做决策,PBFT本质就是这样,选好的一些节点去投票。这一算法的各节点由业务的参与方或者监管方组成,安全性与稳定性能够得到保证的同时,共识效率高,可满足并发量大的需求。

区块链大本营:在使用PBFT这一算法后,是否有一些优化的地方?

来鑫:PBFT的三阶段提交已经经过了理论的验证,没法做任何修改,改了会出问题。但在实现过程中可以做一些优化。proposer给其他记账节点发起propose,其他节点收到区块,验证通过后用自己的私钥签名投票,并通知给其他节点。当收到超过2/3的precommit后,区块就可以产生了。

比如这里就有一个可以优化的点,就是如果网络条件不好,有可能没有收到超过2/3的precommit,这时就要重新发起propose,如果重新打包区块,需要对所有请求再check一遍,很浪费资源。所以需要再不更换proposer的情况下,仍然对这个区块发起propose。

区块链大本营:迅雷链的合约处理流程是怎样的?

来鑫:多链的合约有很多细节比较难处理。首先,开发者的应用数量可能非常大,我们希望开发者之间不要相互影响,开发者也不要影响普通用户之间的请求。所以我们基本上是一个开发者给一条链。这样一来,当一个用户发起合约调用,在其所在的链入了块之后,链间通信模块会同步到对应的合约链上。

另一方面,因为要防止恶意的合约或者合约本身的bug导致占用大量资源,所以需要根据合约执行情况保管相应的数字通证。其数量是需要从请求发起方的账户里扣除的,而真正执行合约的是在合约所在的另一条链,所以最终需要的Token具体数量,在发起请求方所在链入链这笔请求的时候尚未可知,这怎么办呢?

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

区块链大本营:之前以太坊因为合约的代码问题出现很大的安全事故,在写合约方面你有哪些建议?

来鑫:写智能合约要求程序员思维严谨,考虑清楚异常情况,目前主要的漏洞是DAO攻击、计算溢出。比如一个商城的合约,一笔订单需要的费用=单价*该商品数量,如果乘法直接用乘号实现,那么用户可能传入很大商品数量,使得实际费用是溢出后的很小的值。所以合约里为了安全,计算方法要用安全的SafeMath。

区块链大本营:在迅雷链的开发中,最难的技术挑战有哪些?

来鑫:单独专项的技术点其实都是可以攻克的,而对于一个服务最重要的是保证服务7*24小时稳定,而且要具备能快速发现问题并能快速处理的能力。

技术女神的养成之路

区块链大本营:你是什么时候开始接触区块链的?

来鑫:我一直都在做后台开发,一开始在百度实习就做分布式计算,后来到网页搜索部做框计算,再后来到腾讯云做分布式消息队列和去中心化的负载均衡系统。这个负载均衡系统也是每个节点独自决定后端负载能力,自动执行调度。2015年来网心科技也是做CDN,CDN相当于是一个大分布式系统。所以我一直都跟分布式打交道,于是自然而然地就接触到区块链了,区块链从技术角度本质就是分布式系统。

区块链大本营:从CDN到现在做公链,你认为难度大不大?

来鑫:难度是存在的,就像上面所说,区块链的性能提升、与多种应用接轨的能力是行业难题。不过好在区块链里面用到的技术点比较成熟,包括P2P、共识算法,以及存储(如LevelDB),区块链要做的就是将这些点完美的组合起来,并发挥出效用。

区块链大本营:在技术上,你平时会通过哪些渠道自我提升?

来鑫:一方面是编码,编码质量及可扩展性是最重要的。而如何提高代码质量是有一些方法的,要学习这些方法把它变成习惯,比如单元测试。代码的扩展性,主要是逻辑分层并应用设计模式,这个主要通过看书、看开源的好代码来实现。

第二个方面是架构上的,架构上考虑容灾、安全、高并发的横向扩展能力,这些主要看一些业内分享的文章,以及自己在实践中总结的经验。

第三个方面是全局的可运维性、可靠性,包括建设运营体系、完善的监控和告警体系,以及能够快速的发现问题。这些一方面是之前受到的指导,一方面是项目实践中积累的经验。

前三个方面都是在工作中做执行需要的能力。而第四个方面是技术的规划能力,包括前沿的研究和创新、项目自身的能力优化等。前沿的研究主要看社区的分享、高端会议的论文;项目中的优化一方面靠底层的技术功底扎实,这个通过看书、看一些精品分享的文章,另一方面要能敏感的注意潜在问题并有强有力的执行力落实。

区块链大本营:移动互联网开发者想要学习区块链的相关技术,应用层和底层分别需要学习哪些东西?

来鑫:应用层跟平常做互联网业务逻辑的需求开发差不多,额外需要学习一些区块链基本概念,比如区块链运行机制、账户、合约、Gas等,在合约编写时要注意一些安全问题,这方面的安全注意事项,我们团队也在编写一个指南,后面会提供给迅雷链上的开发者。

底层方面,原来做后台开发的人应该基本上都可以直接转到区块链,应用的知识还是后台开发的知识,比如网络编程、算法数据结构、操作系统、高性能存储。额外需要学习的是共识算法的实现,不只是表面的基本共识流程,要学习各种异常情况的处理。还需要再了解些密码学基本知识。

区块链大本营:你认为今年会有哪些场景先拥抱区块链?

来鑫:我认为,先拥抱区块链的首先是涉及资产保护的,比如版权。一方面是那种使用区块链前信任第三方的,这些领域使用区块链后信任则来自规则。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-05-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 区块链大本营 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
内容分发网络 CDN
内容分发网络(Content Delivery Network,CDN)通过将站点内容发布至遍布全球的海量加速节点,使其用户可就近获取所需内容,避免因网络拥堵、跨运营商、跨地域、跨境等因素带来的网络不稳定、访问延迟高等问题,有效提升下载速度、降低响应时间,提供流畅的用户体验。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档