Skip to main content

Attitude is altitude

Tag: blockchain

通用区块链浏览器引擎泛想

通用区块链浏览器引擎泛想 1.背景 目前区块链行业各种链横行,公链有 ethereum、bitcoin、filecoin 等,联盟链有 fabric、fisco bcos、XuperChain、ChainMaker 等,而且每个链的浏览器都需要单独开发,因为每个链的区块、交易、账户体系、链上接口都是不一样的,因此每个链都要有适用自己的浏览器,但是大多数浏览器的功能还是比较相同的,大多数都是存储区块、交易、账户、合约、组织、节点等信息,但是对于公链和联盟路的区别比较大,比如公链大多数都有原生代币以及允许发行代币,联盟链甚至没有代币,并且还有节点准入、业务隔离等特点。但从功能上来说,区块链离不开区块、交易、账户、合约这些东西,因此开发一款通用的区块链浏览器引擎还是很有必要的。 2.什么是区块链浏览器引擎 区块链浏览器的功能很简单,都是将链上的数据存储到数据库,同时提供数据查询的接口,比如查询区块信息,合约信息,账户交易等。那么这部分功能可以做成通用的。通用区块链浏览器引擎最难的一点是如何适配所有的区块链。 不从实现角度说,只从功能来说,通用区块链浏览器引擎就是开发者可以在此基础上非常简单的开发出自己区块链浏览器,也就是说,开发者只需要做很少量、很简单的开发就可以适配一个区块链。 3.难点 先说如何针对一条链开发对应的浏览器。首先要知道链的数据结构,包括区块、交易、账户体系、合约相关数据结构、代币、组织等等。然后确定浏览器的功能。之后选择爬取链上数据的方式,比如按照区块高度爬取、事件订阅方式等等。之后就可以编码了。简而言之,就是确定区块链数据结构、确定浏览器功能、确定链上接口、确定浏览器程序架构(接口、数据库等)。 对于上面的四点,其中确定浏览器程序结构算是最简单的,只有数据库的选择会有一点问题,因为大多数数据库都能满足需求。 最难得是区块链数据结构与链上接口以及浏览器的功能。也就是在开发者使用区块链浏览器引擎时,如何最简单的告诉引擎区块链的数据结构和链上的接口,以及想要的功能。举一个例子,在联盟链中,fabric 有 channel 和 组织,XuperChain 平行链和群组,fisco bocos 有群组和 channel,ChainMaker 有平行链和组织,虽然功能类似,但是引擎如何适配这些概念是一个难点。另外我们不知道接下来还会出现什么样的奇怪的概念,那么引擎该如何做呢?这是通用区块链浏览器引擎的最大难点! 3.1 接口类型 目前大多数区块链对外的接口有两种:json-rpc 和 grpc,json-rpc 是可以使用 http 或者 ws 的 json 格式数据 rpc,grpc 底层使用的是 http2,可以通过这些接口查询链上信息。如何统一呢? 3.2 数据结构 对于链上的区块、交易、合约等数据,都是 go 中的 struct。 第一每个链的结构不一样,第二每个链上的概念不统一,而且后续可能有很多新的概念。 这个问题如何解决呢? 4.解决方案(第一版) 4.1接口解决方案 对于各种类型的接口,没必要全部实现,也就是不需要在引擎中实现 json-rpc、grpc、https 等所有接口,只需要在引擎中定义一个接口,使用引擎的开发者实现这个接口,也就是把客户端与服务端的连接实现这个接口,比如引擎有接口 ClientInterface type ClientInterface interface { QueryBlockByHeight() QUeryTxByID() ...... } 开发者将真正的与链上的连接封装一下,同时实现 ClientInterface 接口,那么引擎可以使用这个对象去做链上的数据查询。 4.2数据结构解决方案 对于数据结构同样采用接口的方式,区块结构举例,定义 Blocker 接口 type Blocker interface { Bytes() Load() .

如何使用 Go 语言写区块链的 SDK (一)

“ 最近在使用 Go 语言写一个区块链的 SDK,从设计到上线总结了其中的一些问题以及思考,如果你也在写 SDK 或者要写 SDK,希望这篇文章可以帮到你。这篇文件不会区分是否是区块链的 SDK,下一篇文章主要写区块链的 SDK 与普通系统 SDK 的一些区别以及相关思考” 当写一个 SDK 时,第一需要考虑的问题应该是这个 SDK 的功能,或者说这个 SDK 是给什么样的用户来用,或者用户使用这个 SDK 能做什么。弄明白了这个问题后才可以开始动手。 一个系统的接口肯定是知道的,但有些情况并不是一个接口就能够完成一个用户的操作或者需求,此时需要系统的多个接口组合调用才可以,同时在调用多个接口时,有很多逻辑是需要在客户端完成的,那么接口调用以及用户的逻辑就需要在 SDK 中完成。所以简单来说,一个 SDK 的基础功能就是系统的接口调用与用户的部分逻辑(当然这只是我抽象出来的,实际情况 SDK 有很多种)。 我个人把 SDK 的出生过程总结如下: SDK 功能确认; 系统接口逻辑确认; SDK 接口设计; SDK 架构设计; SDK 使用文档或者示例代码; 测试; 接下来就分这七步来聊一聊如何开发一个易用、可靠的 SDK。 1. SDK 功能确认 某个系统的 SDK 会有官方的 SDK 也有其他人贡献的 SDK,比如有的企业或者开发者觉得官方提供的 SDK 功能不全,或者使用不方便,满足不了现在的需求. 而且官方很大几率不会再开发一个专门的 SDK 来满足个别的需求,所以开发者有可能根据系统的接口来开发或者在官方 SDK 基础上添加功能。 对于这种现象的出现,我觉得主要原因在于官方的 SDK 在设计之初就是存在问题的,或者说 SDK 的功能确认是错误。 系统可能有几十个接口,但是对于用户有用的或者最常用的可能只有一半或者三分之一,所以 SDK 并不需要把所有的接口都支持,而是要把核心的功能筛选出来,这一点并不与上面提到的功能确认存在问题。