写点什么

迅雷该怎么把区块链这件事做好?

  • 2018 年 9 月 21 日
  • 本文字数:4408 字

    阅读完需:约 14 分钟

2018 年 9 月 15 日下午,中关村创业大街的 3W 咖啡聚集了一群区块链开发者和爱好者。这里正在进行一场干货满满的迅雷链技术沙龙。迅雷链超级区块链平台是目前全球最大规模的 ToC 区块链商业生态,他们以赋能实体经济为目标,致力于成为 ToC 现象级区块链应用的摇篮。那么迅雷该怎么把区块链这件事情做好,为广大开发者和企业提供坚实的臂膀?我们将活动干货内容整理成文,帮助开发者了解迅雷链的技术内容和一些区块链的趋势和落地。

迅雷链架构设计思路有什么特别之处?

可能大家都听说过迅雷链的同构多链架构,它选用 PBFT 做共识,在这个架构下可以实现百万 TPS,并且有很多独特的外围辅助系统。迅雷链开放平台研发负责人张慧勇,针对这 3 个方面详细分析了迅雷链的特点。

我们知道区块链的最基本组成包括基础层、核心层和服务层。基础层包括 P2P 网络、存储和计算;核心层包括共识算法、密码学、块链式数据结构;服务层包括节点管理、接入服务和应用服务。

迅雷链的架构也是基于此建立而成的,并在此基础上拓展了很多特别的模块。比如说:迅雷链在服务层提供了比较多的辅助性的系统,能帮助企业更方便的使用区块链,包括有交易订单系统、合约中心、事件订阅系统。核心层也明显区别于其他区块链,包括链间通信、路由等等,因为同构多链的设计需要通过链间通信和路由这两个部分来完成。智能合约目前接入的是以太坊的虚拟机。还有块链式数据结构,也是迅雷链自定义的,因为多链相对于单链需要做一些区分,,并且链间通信也需要用到这一部分。

迅雷链为什么优先关注 TPS?

我们知道,支付宝在去年双十一的时候,峰值也才在 20 万 TPS 左右,为什么区块链就需要一个百万级的 TPS 呢?迅雷链又是为何要设立这样一个目标?

  • 首先,区块链它将作为互联网的一个基础层的服务,而不是应用层的,类似 DNS 服务,所以它需要有很强的处理能力。
  • 其次,区块链的的应用场景比较多,而在某个场景中的交易并不能简单的理解为现实中的一笔交易,比如就是一个转账或者一个买卖,而是信息的上链或者信息确权。信息的产生以及它的上链过程是需要非常大的 TPS 来作为它的支撑的。
  • 再次,迅雷链调查很多区块链的具体场景,发现在未来的物联网时代,数据源指数级增长,百万级 TPS 也是远远不够的。

而同构多链的方式,它的优点就是可以无限扩链,进而可以不停地提高 TPS,这是一个可在线扩展的方案,也是迅雷链架构设计的首要目标。

为什么选择 PBFT 做共识算法?

如果熟悉共识算法的同学应该都有了解,共识算法有两种:一种是确定性的,一种是随机性的。而对于商业级的应用比较难以接受随机性的应用,特别是存在区块回滚和分叉的情况。比如在淘宝支付一笔交易,区块回滚了订单没有成功,这很难被用户接受,也会选择放弃购买。

而在确定性的共识算法中,能保证主链的安全性的 + 秒级确认的,PBFT 几乎是唯一的选择。当然,PBFT 有一个很明显的缺点,就是需要 2/3 的节点达成共识,才能生成区块进行下去。所以只要有超过 1/3 的节点出现问题就无法达成区块,这样区块链就不可用。

迅雷在解决这个问题上有很大的优势,因为迅雷链有 150 万 + 的共享节点,随着我们这个节点的增多、地域的扩散,这个安全性会越来越好。

迅雷链有哪些独特的外围辅助系统?

迅雷链的外围辅助系统,能够为企业接入提供一键式服务。其中比较独特的就是交易订单系统和迅雷链文件系统,这在其他区块链平台也是很少有的服务。同时,区块链浏览器也在不断拓展中,包括交易记录、查询优化等,方便大家对数据查询。

另外合约中心是为了符合国家监管特别设置的,用来审查所有链上的合约代码,同时也要防止一些恶意的程序。此外,合约也是迅雷链和企业之间达成共识的基础,所以必须开源给企业用户,为用户提供一个合约代码查询的地方。

事件订阅系统也是采用互联网的传统方式,主要是让大家更方便的查看到合约发生的事件以及有一个可回溯和查询的过程。合约标准与模板库的建立,也可以大大降低客户的开发难度。有兴趣的朋友可以关注迅雷链官网了解更多。

如何在迅雷链上开发智能合约应用?

迅雷链应用层研发工程师郝旭,针对这个内容进行了详细解答。

智能合约可以简单的理解为:基于区块链运行的一个应用程序,通过对这个应用程序的调用执行和查询,可以把应用程序里的一些逻辑、数据写到区块链上,并最终同步给所有节点,从而实现去中心化的特性。有了去中心化的特性,就可以实现智能合约业务需要的数据追溯、防篡改、公开透明等特性,从而解决在各行各业中都会产生的信任问题,解决一些效率上或是工作方式上的痛点。

迅雷链的智能合约开发是兼容以太坊 EVM 的,也是基于 solidity 语言开发的,所以在以太坊开发的智能合约应用都可以无缝移植到迅雷链上直接部署和使用。solidity 语言本身就是类似于 JS 这种弱的面向对象语言的形式。

举一个简单的例子。

开发过程中有常用的两种开发方式:一种是 Truffle 框架,它集成了部署、编译、本地化测试等一系列工具,放在一个框架里面去实现;另一个是 Remix,这是以太坊提供的一个浏览器 IDE,可以直接在浏览器上编译你的合约,在虚拟环境下运行合约或者支持单步调试一些功能。

Truffle 和 Remix 都是很好的开发合约的工具,它们有一些不同之处:Truffle 作为一个框架级的应用更方便于做一些工程类的合约,比如说你的合约很复杂,合约之间有相互引用的关系,它比较方便组织与合约之间的应用,还提供了一系列测试流程。而 Remix 比较方便的一点就是,合约部署之后的调试,可以方便的看到每一步单步调试的上下文环境、参数以及 opcode 等具体到底层的信息。

开发者在具体使用这两个框架做开发的时候可以选择自己的需要,简单的合约应用开发其实用 Remix 就够了,比较大的工程用 Truffle 开发更合适,但是 Remix 对单步调试的支持更方便。

那么在迅雷链上接入智能合约的基本流程是怎样的?

简单来说,开发者在开发合约应用时,合约和应用其实是分开的,先开发合约,再开发应用,应用再去调用合约,做签名等。在迅雷链提供的测试环境中可以直接通过 API 做签名,发布在迅雷链测试环境做交易。整个流程结束后再通过迅雷链开放平台把合约部署上去,然后替换测试环境的合约地址就完成整个流程了。迅雷链所有 API 文档都可以在开放平台上查看,上面还有一些对应的 DEMO 流程供参考。

迅雷链在开发合约应用和对接客户的合约应用过程中,总结出来的一个典型架构:

应用层前面三层是主要的,智能合约是单独的,前面三层就是一个普通的 C 端应用。但在管理自己应用数据时,需要一个 B 端的应用管理平台,C 端应用和 B 端应用管理平台操作的数据都来源于智能合约。

应用后台提供的主要功能,一方面是企业自己应用后台所需要的一些业务逻辑,与智能合约相关的主要部分其实就是,通过使用迅雷链为业务方提供 serviceid 和 Key,对 C 端应用和 B 端应用做一次业务签名。

C 端和 B 端应用的不同点是:C 端应用面对普通用户,B 端应用面向管理员,C 端应用操作的就是链克口袋唤醒的过程,B 端应用操作的是服务端 SDK。下面的部分就是迅雷链测试环境和正式环境,分别是在测试和正式环境的两套完全独立且相互相同的环境。整个应用架构分层其实确实跟传统应用基本类似,需要注意的就是智能合约层的开发,也就是关键的应用逻辑和应用数据的实现过程。

比如说足球竞猜这样一个区块链应用,普通用户使用时可以选择他认为的胜方然后投注,投注的过程其实就是调取链克口袋,执行智能合约,背后就是相当于智能合约发送一条交易数据的过程,对应用户输入密码,最终把这条数据发向迅雷链,然后改变智能合约里面相应的数据存储的过程。整个流程我们通过下面两张图来说明:

这样一个应用的团队配置可以是:1 合约开发 + 1 后台开发 + 2 前端开发 + 1 测试;开发周期基本是:开发 + 测试 + 部署上线 1 周。

同时,迅雷链对于合约开发也提供技术支持:迅雷链浏览器是给用户查迅雷链所有数据的平台,API 接口是针对开发者查询所有迅雷链数据的接口,事件回调系统是指合约事件在触发的时候可以通知到开发者,DEMO 应用是指一套从 C 端、B 端到应用后台的一个完善应用,开发者可以直接拿来简单修改后使用。

此外,迅雷链也提供一些解决方案:首先是突破 solidity 语言的限制,支持更多的高级语言开发合约;其次是模板化合约,是指我们做了一些有共性的合约模板支持开发者快速部署;合约升级这个问题是一个比较普遍的问题,不只是迅雷链有,我们所提倡的方式其实就是在业务端重新部署一些合约,以在业务端更新合约地址的方式实现业务升级;合约安全也是当前遇到的一些比较普遍的问题,迅雷链本身会对所有上传的合约做一些代码的自动化检测,以及关键代码的人工审核来支持合约的安全。

迅雷链产品设计的那些事

区块链技术,最终来说都是应用到每一个需求本身的。如何完成一个性能优良的 DAPP 的设计是产品人员的终极目标。那么,用户为什么要用 DAPP?迅雷链开放平台产品负责人马双阳,分享了迅雷链产品设计的那些事。他总结了 Dapp 的四个优势:安全、隐私、利益、效率。

那么迅雷链有什么优势,开发者为什么要选择迅雷链做来开发 Dapp?迅雷链又能做什么,怎么做,成本如何?这个问题包含的不仅是开发者接入这件事情本身,而是怎么尽可能多的提供软性服务,比如大家在开发过程中的技术问题,或者一些方向选择上问题,包括提供头部资源、人才支持等等。

Dapp 在产品设计上有哪些难点?

迅雷链开放平台上有四个主要产品,包括链克兑换、智能合约、原数据上链、连客商城。双阳总结到,现阶段 Dapp 在产品设计上有三个难点:

  • 一是企业客户的教育成本高。很多企业其实不愿意用 DAPP,因为所有的场景都会对安全、加密、去中心化的特性很敏感。此外如何在这里面做一个好的产品,能够让用户体验依然能够达到或者接近于原来中心化产品,不然推进起来相对困难。
  • 二是线上和线下场景分离。比如说要做溯源,通过溯源解决问题的流程很长,之前阿里在跟茅台对接时遇到个问题:如果本身上链的数据是假的,线下环节怎么掌控?怎么保证整个链上数据真实性?这点可能要跟物联网、一些具有生物特征的技术做结合,区块链就不是单一的问题。
  • 三是底层性能支撑。目前市面上一些主链性能,是否足够支撑线下商业应用。比如迅雷链的百万级 TPS 是否能满足大家的需求。

最后,双阳根据具体场景提出了详细的解决方案,我们通过图片来了解下: 

还想继续了解更多?

我们相信,区块链不仅是技术上的改变,更是生产关系的改变,而主角是企业,作为底层主链,迅雷链希望为这些企业减轻使用新技术时的负担。目前,随着迅雷链服务层的逐步丰富,开发生态的日益完善,已有越来越多的实业公司开始投入到区块链技术上,而且它们使用区块链的思路也越来越清晰,相信不需要太长的时间,大家就能在迅雷链上看到一大批实业类公司的区块链应用上线。

大家可以关注“迅雷链”官方微信,了解更多技术详情。

2018 年 9 月 21 日 05:01919
用户头像

发布了 33 篇内容, 共 88852 次阅读, 收获喜欢 20 次。

关注

评论

发布
暂无评论
发现更多内容

Netty常量池

Java 程序员 后端

nodeJS——网络编程

Java 程序员 后端

NodeJS快速入门必备技能

Java 程序员 后端

pageHelper----Mybaits分页插件

Java 程序员 后端

OpenTelemetry 简析

Java 程序员 后端

Mysql的“三高”集群架构

Java 程序员 后端

Netty编解码方案之Protobuf介绍

Java 程序员 后端

NoSQL到底怎么用?

Java 程序员 后端

OpenFaaS实战之四:模板操作(template)

Java 程序员 后端

OpenKruise v0

Java 程序员 后端

OpenFaaS实战之六:of-watchdog(为性能而生)

Java 程序员 后端

mysql常用函数,mysql进阶

Java 程序员 后端

MySql数据引擎简介与选择方法

Java 程序员 后端

MySQL没有RowNum,那我该怎么按“行”查询或删除数据?(1)

Java 程序员 后端

Netty 核心源码解读 —— 开篇

Java 程序员 后端

Nginx详解Location匹配规则

Java 程序员 后端

MySQL最全整理,1200页文档笔记,从高级到实战讲的太清楚了

Java 程序员 后端

mysql系列:innodb日志管理,带你高效快速理解

Java 程序员 后端

Netty学习之旅------Netty Channel 概述

Java 程序员 后端

Oracle数据库访问性能优化

Java 程序员 后端

MySQL基础总结

Java 程序员 后端

MySQL没有RowNum,那我该怎么按“行”查询或删除数据?

Java 程序员 后端

netty的线程模型, 调优 及 献上写过注释的源码工程

Java 程序员 后端

Protobuf 属性解释

Java 程序员 后端

MySQL索引篇之索引存储模型

Java 程序员 后端

OpenSSL 生成CA证书及终端用户证书

Java 程序员 后端

mysql用户&权限总结

Java 程序员 后端

Netty学习之旅------图说Netty线程模型

Java 程序员 后端

Nginx服务器配置

Java 程序员 后端

Nginx超详细的常用两种安装方式

Java 程序员 后端

OpenFaaS实战之六:of-watchdog(为性能而生)(1)

Java 程序员 后端

迅雷该怎么把区块链这件事做好?-InfoQ