banner
leaf

leaf

It is better to manage the army than to manage the people. And the enemy.

链上治理

链上治理指的是人们直接在区块链发起社区提案,并进行决策的过程。这里首先要求的是链上支持基本治理协议,这套协议可以规定或强制执行提案,链上治理直接决定 了区块链本身的发展方向。

链上治理的参与方包括了投资者、使用者、开发者、矿工四类人群。

链上治理与链下治理的区别在于,区块链本身是否提供强制执行的机制让少数服从多数。在链上治理协议中,参与者需要可以通过投票参与治理,而链下治理中,多数通过提案、社区见 面开会等多种线下线上互动方式,让整个社区达成一致,扩容之争中的三次共识就是典型的链下治理。

各种类型的链上治理

  1. 1. 比特币 BIP 和区块投票 虽然比特币没有提供完整的链上治理机制,但是比特币也支持简单的投票机制,例如在区块中写入共识信息表示支持某项提案,例如矿工可以在区块中填写 NYA 表示支持纽约共识。 但这一切都是基于比特币的 BIP,首先得有 BIP,才能发起投票。BIP 的组织架构比较社区化,主要由 Github 上的一些开发者和核心社区成员组成。矿工的所有行为也是非强制性的,当真正发生主网升级时,矿工仍可以选择不升级,这将带来分叉,也是所有人都不愿看到的。

  2. 2. 以太坊 Gas limit 投票 以太坊上提供了对 Gas 消耗的上限参数 ——Gas limit,矿工通过投票选择增加或减少 Gaslimit,Gas limit 决定了单个区块上可以处理的智能合约数量,但这仅针对这一项细分功能,并不 能决定整个区块链的发展。实际上,以太坊的发展受 Vatalik 本身影响比较大,核心成员和早期资本的推动是以太坊治理的主要源动力。

  3. 3. 比特股 BTS 和柚子 EOS 的链上治理 我们在前面的文章介绍过 EOS 区块链链上治理结构 —— 区块链宪法。实际上宪法也没有强制约束力,但是它成为了一种社区强制约束力,类似宣誓过程。EOS 和比特股的治理结构来自于 DPoS 算法提供的投票过程,投票是根据币的数量作为权重的,使用者、投资者、开发者、矿工这四种角色中,其中把矿工和投资者进行了合并,受资本的要挟,风险比较大。

以上治理结构,我们把比特币和以太坊归为一类,这类倾向于链下治理,EOS 和比特股倾向于链上治理。

链上治理的几个问题 无论链上治理还是链下治理方式都存在一些问题。升级的实际执行者矿工总是理性的,也就是追求自身利益最大化。惰性投票,只有很少一部分人会真正地去投票。投票权过度集中,大户持有者往往话语权更重。

链下治理相比链上治理,更接近我们现实社会的方式。链上治理不是一个设计问题,它是社区制度问题,“如何让区块链更好地发展” 相比 “区块链项目应当设定什么样的发展目标”,是排在第二位的。 社区在自身追求目标的过程中,会自发地找到最佳治理结构,人为设计可能会有诸多漏洞和缺陷,也限制了可开发性。

例如链上治理至少存在以下几个问题。

  1. 1. 公地悲剧 当所有人都觉得别人会投票的时候,也就没有人投票了,这个典型案例是英国脱欧公投。区块链上进行链上投票可能也会遇到类似的问题。

2.女巫攻击 目前区块链很难映射现实中人的身份,链上治理指的是人们直接在区块链发起社区提案,并进行决策的过程。这里首先要求的是链上支持基本治理协议,这套协议可以规定或强制执行提案,链上治理直接决定 了区块链本身的发展方向。

链上治理的参与方包括了投资者、使用者、开发者、矿工四类人群。

链上治理与链下治理的区别在于,区块链本身是否提供强制执行的机制让少数服从多数。在链上治理协议中,参与者需要可以通过投票参与治理,而链下治理中,多数通过提案、社区见 面开会等多种线下线上互动方式,让整个社区达成一致,扩容之争中的三次共识就是典型的链下治理。

各种类型的链上治理

  1. 1. 比特币 BIP 和区块投票 虽然比特币没有提供完整的链上治理机制,但是比特币也支持简单的投票机制,例如在区块中写入共识信息表示支持某项提案,例如矿工可以在区块中填写 NYA 表示支持纽约共识。 但这一切都是基于比特币的 BIP,首先得有 BIP,才能发起投票。BIP 的组织架构比较社区化,主要由 Github 上的一些开发者和核心社区成员组成。矿工的所有行为也是非强制性的,当真正发生主网升级时,矿工仍可以选择不升级,这将带来分叉,也是所有人都不愿看到的。

  2. 2. 以太坊 Gas limit 投票 以太坊上提供了对 Gas 消耗的上限参数 ——Gas limit,矿工通过投票选择增加或减少 Gaslimit,Gas limit 决定了单个区块上可以处理的智能合约数量,但这仅针对这一项细分功能,并不 能决定整个区块链的发展。实际上,以太坊的发展受 Vatalik 本身影响比较大,核心成员和早期资本的推动是以太坊治理的主要源动力。

  3. 3. 比特股 BTS 和柚子 EOS 的链上治理 我们在前面的文章介绍过 EOS 区块链链上治理结构 —— 区块链宪法。实际上宪法也没有强制约束力,但是它成为了一种社区强制约束力,类似宣誓过程。EOS 和比特股的治理结构来自于 DPoS 算法提供的投票过程,投票是根据币的数量作为权重的,使用者、投资者、开发者、矿工这四种角色中,其中把矿工和投资者进行了合并,受资本的要挟,风险比较大。

以上治理结构,我们把比特币和以太坊归为一类,这类倾向于链下治理,EOS 和比特股倾向于链上治理。

链上治理的几个问题 无论链上治理还是链下治理方式都存在一些问题。升级的实际执行者矿工总是理性的,也就是追求自身利益最大化。惰性投票,只有很少一部分人会真正地去投票。投票权过度集中,大户持有者往往话语权更重。

链下治理相比链上治理,更接近我们现实社会的方式。链上治理不是一个设计问题,它是社区制度问题,“如何让区块链更好地发展” 相比 “区块链项目应当设定什么样的发展目标”,是排在第二位的。 社区在自身追求目标的过程中,会自发地找到最佳治理结构,人为设计可能会有诸多漏洞和缺陷,也限制了可开发性。

例如链上治理至少存在以下几个问题。

  1. 1. 公地悲剧 当所有人都觉得别人会投票的时候,也就没有人投票了,这个典型案例是英国脱欧公投。区块链上进行链上投票可能也会遇到类似的问题。

2.女巫攻击 目前区块链很难映射现实中人的身份,如果按照身份去投,大户是可以扮演多个伪造身份进行投票的,在产生区块链数字身份之前,链上治理只能依托于币的数量进行权重投票。这便造成一个代 币一票,持币多的选民有更大的话语权。

3.贿选 这其实是女巫攻击的延伸,链上治理节点可以承诺将获得的收益与其他节点进行分享,这种拉票方式其实就是贿选,如果恶意节点可以通过贿赂成为记账节点,

进而左右区块链的升级过程,后果非常可怕。目前创始团队进行控制式治理是最常见的,在社区强大后,创始团队再退出,让社区自己运作,是比较典型的 “中本聪模式”。链上治理其实是一个很热门的话题,它关注的是区块链自身的发展,很可能会是区块链的一个重要研究方法,但是这并不是技术所能解决的,所以并不太乐观。

区块链在各行业的快速发展,带来了全新的机遇。从数字货币到数字资产数字货币是数字资产的清算底层,数字资产的经济活动依赖数字货币。数字货币一般只能是公链项目,数字资产依靠公链生态提供,这种支撑型结构决定了数字货币的种类不会很多,而数字资产会非常多。目前数量繁多的数字货币最终会消亡一大半,只剩下几个生态丰富的数字货币,通过这几个数字货币来支持数量繁多的数字资产,而这些公链会通过一些大型的中心化交易平台完成互通互兑,小型的交易平台多为垂直类的数字资产服务。

比特币本身是最成功的数字货币项目,同时也是最成功的区块链项目。比特币的应用生态主要集中在全球无国界支付结算上,由于比特币本身是一种原生资产,它没有与 任何其他资产锚定,所以比特币的应用生态取决于人们的共识,这点比特币已经做到了。只要比特币的社区不发生大的动乱,那么比特币的地位是很难超越的,尽管有诸多崭新的区块链技 术冒出来,如提升共识效率、提升网络容量等等。

比特币本身是最成功的数字货币项目,同时也是最成功的区块链项目。比特币的应用生态主要集中在全球无国界支付结算上,由于比特币本身是一种原生资产,它没有与 任何其他资产锚定,所以比特币的应用生态取决于人们的共识,这点比特币已经做到了。只要比特币的社区不发生大的动乱,那么比特币的地位是很难超越的,尽管有诸多崭新的区块链技 术冒出来,如提升共识效率、提升网络容量等等。

但是比特币的共识经过了近十年的历史开创,形成成熟稳定的生态结构,这一点在技术上是无法取代的。 所以比特币依然会作为互联网领域的第一支付手段,并且延伸到线下场合。除了比特币还有 Tether 和 bitCNY 等锚定型数字货币,这些数字货币最大的特性是与法币锚定。其 实也可以与实体资产锚定,只不过我们还没有走到那一步。综上,我们可以总结出两大类数字货币:原生数字货币和锚定型数字货币。

原生型数字货币具有如下特点:

非营利性社区自治;

依赖社会共识承认;

超级结算工具;

可用于支持数字资产。

锚定型数字货币具有如下特点:

  1. 商业性自治;

  2. 2. 依赖广泛的承兑商;

  3. 3. 稳定的支付结算工具;

  4. 4. 可用于支持数字资产。

我对数字资产进行一个分类,数字资产所产生的金融我们称为数字金融,国内又称为通证和通证经济,涵义上差不多。 Token 是数字资产最直接的表现形式,Token 的生态结构具有自发和原生性,大致可以分成这几种 类型。

一种是基础设施型生态,一种是金融型生态,还有一种是商业垂直应用生态,这三种生态都非常有潜力。

基础设施型 Token 基础设施一般就是指公链的权益代币,很多公链都在做这个领域的研究,当然这也是最迫切需要被 突破的,有了成熟的基础设施,区块链应用才得以广泛普及。 这类的 Token 的典型是以太坊上的以太币 Ether,除了以太坊,还有 EOS、NEO 等,可以说能够 支持发行 Token 的公链都具有较高的潜在价值,它们目前处于军阀混战时期,后期是垂直细分还是 一统江山很难判断。 另外基础设施型 Token 本身也具备数字货币的功能。

金融型 Token 这类 Token 的典型是 Tether 、bitCNY 等锚定型数字货币,以及交易平台的 Token ,例如火币的 HT、OKEX 的 OKB 和币安的 BNB。这类 Token 的典型特点是在为原生数字资产创造流动性,它是数字金融发展的必然结果。

金融型 Token 有点接近证券,只能在流动性高的地方产生,例如数字资产交易所、承兑平台。商业垂直生态型 Token 这一类 Token 具有非常大的商业潜力,释放的能量也是最大的,这里当然不是指单个 Token ,而是某个商业生态形成的一类 Token 。例如游戏直播平台可以打通形成一类 Token ,

这类 Token 的设计者,也面临了两个挑战。 首先从业者需要理解区块链,理解区块链不单指理解区块链的技术原理,而是区块链本身蕴含的思维,这里的思维我归纳为两类,第一类是开放的产品形态,第二类是社区共同治理。 其次从业者容易拘泥于传统互联网时代的商业模式,例如做内容或做流量的 App,表现方式无非广告和会员,思维很难跳出来。要知道,未来商业垂直型的 Token 几乎肯定都是原生数字资产,所以按照阿里或者腾讯的模式可能找不到区块链的方向,这类 Token 的未来一定是新的阿里和腾讯。

我预测这类 Token 会极大地改变互联网产品的运营模式,Token 模式下的产品运营会拉近用户与运营商的距离,他们不再是对立关系,而是区块链式的共生社区自治的关系,区块链的治理模式也 会影响产品的运营模式。 最后我们总结一下,以上三类 Token 依赖关系是:

  1. 1.商业垂直生态型 Token 依赖基础设施型 Token ;

  2. 2. 金融型 Token 依赖基础设施型 Token ;

  3. 3. 商业垂直生态型 Token 可能依赖金融型 Token 。

Token 的流动性大小依次是: 基础设施型 Token > 金融型 Token > 商业垂直生态型 Token

Token 的种类数量分布依次是: 商业垂直生态型 Token > 金融型 Token > 基础设施型 Token

那么 Token 从这个角度来看,只有两类。普通 Token

  1. 1. 积分型。这种 Token 可能比较常见,因为我们经常遇到,例如超市积分,产品积分等等,这种 在产品运营上可能换了一种形式,相比较原来的积分体系,流动性可能有所提升。

  2. 2. 会员型。大多数会员制的营销方式,相当于是使用权预售,例如苹果手机预售发行,不必局限在某个渠道商,可以以发行 Token 的方式进行预售。这种类型的 Token 也可以映射到当下现 实场景中去。

  3. 3. 分红型。这种类型的 Token 典型是币安的 BNB,利润回购是分红型 Token 常见的手段,但由于操作不够透明,很可能会遇到问题

价值型的 Token ,一定会触及改变了原有的生产关系。就如一个人刚接触股权概念的时候,很难解释清楚股权对应什么,Token 也是类似的处境,Token 具有可编程属性,它可以带来多 种属性合一。

使用权,表示 Token 可交付产品或服务;

可交易,流动性是数字资产的基本需求;

可升值,这是由第二条带来的附加属性,也就是升值。

Token 技术栈比较 Token 的实现已经有 ERC20 为主的以太坊生态、比特股 SmartCoin 生态、NEO 的 NEP-5 生态、

量子链的 QRC20 生态,还有元界的 MST 生态。

于中心化交易所是主流应用,所以今天我主要介绍的是中心化模式下的数字货币交易平台。两套账本

数字货币交易平台的技术基本沿用了金融交易技术中的系统架构,只是把原来针对法币和证券(或平台代币)的部分,也就是我们通常称作资金管理系统的部分,完全替换为针对数字货币的数字货 币管理系统,换句话说,就是换了一套内部账本。然而我们知道,区块链本身也是用来记账的,也算作一种金融账本,所以一套内部账本,一套区块链本身的账本,这里就出现了两套账本,如何管理这两套账本,就是资金管理系统的首要任务

image

图示 数字货币交易所) 解释一下这张图,图的左边表示了多个区块链账本,右边的数字货币交易所有自己的内部账本,这两套账本是独立的。交易所内部的账本记录的是交易 Trade,这个交易是由用户挂单,接着被撮合引擎撮合成交而产生的,而区块链账本上的交易 Transaction,是当且仅当用户发起充币提币请求并被执行时,才会产生的。

这两种交易都用了中文 “交易” 来表示,但是它们所属的语境不同,前者的交易表示的是金融交易语境下的资产交换,也就是 Deal;后者表示的是区块链上的技术概念,表示资产转移的一次记账过程,上述特意用英文以表区别,希望你能够区分。

数字货币交易所包含哪些系统模块 一个数字货币交易所的后端其实至少有四部分构成:Web 业务逻辑系统、交易撮合系统、运营后台管理系统、资金管理系统。资金管理系统其实就是刚才说到的内部账

image

Web 业务逻辑系统:这个模块通常包含了用户账户模块、登录网关、账户安全管理、KYC 认证、行情推送等等,这个模块更偏向用户,也与通常的电商账户系统十分类似。

交易撮合系统:这个模块是一个交易所的核心模块,为所有的用户提供订单撮合。

运营后台管理:这个模块是一个交易所运营人员使用的系统,交易所内部人员才能访问。

资金管理系统:这里的资金管理其实包含了三部分,第一部分是法币的支付网关,可能需要对接银行或第三方支付机构;第二部分就是数字货币钱包管理,它提供了大部分主流数字货币的支付功能;第三部分是用户持仓信息,所谓持仓就是用户持有多少数字货币,这个是记录在数据库中的,不需要与区块链保持一致,但是要求交易所的总账是平的。

各自模块的特征 Web 业务系统与我们常见的电商系统无异,主要是用户账户以及简单的业务逻辑,重点是可扩展性,业务要求比较弹性。交易撮合系统本质上是一个高并发的计算系统,特点是系统性能高和稳定性好,其中订单队列可以是编程语言中的数据容器,也可以是内存数据库。

运营后台系统在整个交易所生命周期的早期并不凸显重要性,但是运营后台系统恰恰是交易所中后期发展的核心系统,重点在数据准确,要求网络安全性高和可扩展性好。资金管理系统包含用户持仓状态,以及数字货币钱包服务,它是一个交易平台中安全性要求最高的系统,资金管理系统往往要搭配一个内存数据库,其中数字货币钱包服务也可以拆出来做成独 立子系统,甚至可以改造成整个公司的内部区块浏览器,因为钱包服务需要设计成多个钱包实例,并统一所有的币种钱包接口。

image

上图中,MatchingGroup 相当于是交易撮合系统;Web-Group 相当于 Web 业务逻辑系统;Backoffce 相当于后台管理系统;AssetsManagement 相当于是资金管理系统。

涉及的技术栈 如果我们再将刚才提到的各个模块细分,会看到以下的功能。

image

按照上图的细分功能,我们可以得到哪些技术支持一目了然。 首先是 Server 需要数据库作为支撑,其次是 Restful API 作为基础通讯协议,并且集成钱包相关的技术,撮合引擎为 Sever 提供撮合服务。在这里面,例如需要 SMS 系统,所以可以使用云服务中的 SMS 组件,这些都可以是成熟的通用组件技术。我们可以发现中心化交易使用的技术与互联网技术并无不同。把这些通用组件塞到下图中各个层次和大模块当中,所以最终一个交易所的详细架构可能是下图的 样子

image

首先是存储,持久存储通常可以选择 MySQL,撮合相关的模块由于要避免接触磁盘 IO,所以需要为撮合模块提供 Redis 类型的内存存储,二者需要保证最终一致性。撮合和行情部分,几乎与传统技术无异,行情推送可以类比到其他推送系统,只是频率更高,一般首选 Websocket 技术。这与传统互联网应用的最大区别里主要是数字货币钱包管理,这块完全是新的内容,对安全性、易用性提出了相当高难度的挑战,这里也是交易所资金托管的根本,所以如何管理好大量数字货币,往往要结合运营、内部管理制度、冷热钱包技术一起才能做好交易所的资金管理。

那么用户是如何挂单的,又是如何产生区块链交易的呢?我们来看一看。

#交易过程 那么说,用户 A 拿 0.01BTC 换取了 B 的 10 个 ETP 的过程究竟是什么样的呢,我来举一个例子。

  1. 1. 用户 A 挂 10ETP 买单,出价 0.01BTC 经过 Web 业务系统进入撮合系统订单簿 ETP-BTC 买单队列,等待撮合成交,同时资金管理系统冻结 0.01BTC。

  2. 2. 用户 B 挂 10ETP 卖单,出价 0.01BTC 经过 Web 业务系统进入撮合系统订单簿 ETP-BTC 卖单队列,与步骤 1 中 A 的订单撮合匹配成功,生成 Trade,同时资金管理系统结算对应资产,B 的资产变化为增加 0.01BTC 并减少 10ETP, A 增加 10ETP 并减少 0.01BTC。

  3. 3. 成交 Trade 以及资产变化通过资金管理系统写 RDB 数据库,形成成交记录,同时更新行情数据库记录可供用户和运营后台管理系统查询。 要注意的是这一步并不是登记到区块链上。

  4. 4. 用户 B 经过 Web 业务系统发起提币请求,请求提取 10ETP 进入自己的数字货币钱包,这个请求进入资金管理系统,交易所运营人员可通过运营后台观察到这笔请求,运营人员审核用户 B 的信息,比如实名认证是否正常等。

  5. 5. 提币请求进入运营系统后,如果通过审核,则资金管理系统会冻结用户 B 的 10ETP,同时将提币请求发起给数字货币钱包服务系统,也就是 WalletGroup,子系统发起区块链上的交易 x(Transaction), 等待交易被打包,并根据更新提币审核状态,供用户查看。

  6. 6. 数字货币钱包服务根据区块信息查询交易 x 是否被打包,如果已经打包,则资金管理系统将完全把用户 B 被冻结的 10ETP 直接抹成 0,更新提币状态最终为完成,提供区块交易 ID 以供用 户和运营后台系统进行查询。

在步骤 3 中,我们可以看到用户所持有的资产,相当于是交易所对用户的负债,但这也只是数据库,并不是真正的链上资产。

在步骤 6 中,我们看到区块链上的 “交易” 与步骤 3 中的 “交易” 完全不是一个概念,同时用户的资产是否安全,完全取决于交易平台的技术是否安全,对交易所是否信任。

再来看看充值阶段。 简单来说,充值是与提币相反的过程,不同的是,充值不需要审核,一般数字货币交易所的原则都是 “宽进严出”,在充值过程中,交易平台通常不直接使用数字货币钱包检测用户是否充值到账,而 是使用 “扫块”(block_scan) 这一方法检测用户的充值。

数字货币钱包的分类#

目前市面上的数字货币钱包有很多种,看起来似乎有些眼花缭乱,不过,我们可以将它们进行分类后,再快速了解。下图展示了按照不同属性区分的区块链钱包

image

左一是按照用户端平台划分的钱包,这种钱包实际是在服务端运行的,用户端的钱包实际上只是一个代理,所以用户不需要关心钱包的细节,使用起来十分方便,典型的例子是各种在线钱包。 左二是按照货币类型分类的钱包,主要是指这款钱包到底是否支持多币种,这里的多币种可以是基于以太坊 ERC20 Token 的同一个区块链上的多币种,也可以是集成了比特币和以太坊等不同区块 链的多币种。

右二是按照私钥存储的方式来区分的钱包,实际上这里主要涉及了用户私钥是否被平台托管,如果不托管直接存储在用户端,也就是硬件、终端设备、纸质记录,这些都可以被称为 On-chain 的钱 包;如果用户无法接触到私钥,私钥被托管在平台,那么这种钱包也被称为 Off-chain 的钱包。右一是按照访问方式进行分类的钱包,例如可以多个人共同管理,同时它也是需要多重签名支持的 钱包,否则就变成了个人私有的钱包。

上的分类并不是绝对的,一个钱包可以兼具以上不同的属性,例如某个 Mobile 钱包是提供 Onchain 的,也提供多重签名、提供多币种的钱包,这种钱包通常就是业界比较流行的钱包类型。 但是,对于平台方来说,上述钱包类型可能不足以支持自己平台的需求,并发挥出最佳的功效。毕竟作为平台来说,对高可用、分叉检测、区块确认的要求是远远高于普通钱包的,这样的问题又是 如何解决的呢?这就引入了一项新的技术。 扫描区块技术 Block scan

我们之前在深入区块链技术部分介绍过,构成区块链的四个核心技术是:P2P 网络协议、分布式一致性算法、加密签名算法、账户与交易模型。这四个技术对应到数字货币钱包中就是,P2P 网络、 持久化存储、账户以及私钥管理、共识与交易验证四大模块。

其中,持久化存储模块是由全节点钱包自带的嵌入式数据库提供的,这里有 LevelDB、BerkerlyDB、SQLite3 等多种选择。 但是无论选择哪种嵌入式数据库,都面临了一个严峻问题,精细化的交易查询验证与性能不可兼具。换句话来说,任何全节点的嵌入式数据库都无法和服务器级别的数据库相媲美。对于平台开发来说,显然选择服务器级别的数据库是更为合适的选择。那么这里就涉及了一个问,如何把全节点钱包中的数据转换成为数据库服务器中的数据,这就需要用到一种扫描区块技 术,简称扫块。扫块,顾名思义,就是指扫描全节点钱包中的所有区块,然后将其解析后存储到数据库服务器的过程,这些数据库可以是 MongoDB,也可以是 MySQL,取决于你的业务需要。 我们可以举元界区块链扫块的例子,元界上的区块结构与比特币接近,你可以将其类比成比特币区块链。 以下是 Python 代码,展示了基于 MySQL 的关系型表结构,目的是从元界的嵌入式数据库中扫描区块,然后存储到 MySQL 中。

def init_table(conn): tables = [] tb_block = ''' create table if not EXISTS block ( number bigint primary KEY , hash char(64) not null, bits bigint, transaction_count INTEGER , mixhash VARCHAR (128), version char(8) , merkle_tree_hash char(64), previous_block_hash CHAR (64), nonce varchar(128) , time_samp bigint ) DEFAULT charset=utf8; ''' tb_tx = ''' create table if not EXISTS tx ( id bigint PRIMARY KEY , block_height bigint REFERENCES block(id), hash char(64) not null )DEFAULT charset=utf8 ;''' tb_address = ''' create table if not EXISTS address( id int PRIMARY KEY , address VARCHAR (64) UNIQUE )DEFAULT charset=utf8; ''' tb_output = ''' create table if not EXISTS tx_output( id bigint PRIMARY key, hash char(64) NOT NULL , tx_id bigint REFERENCES tx(id), output_index bigint not null, output_value bigint, address_id bigint REFERENCES address(id), script varchar(1024), asset varchar(64), decimal_number varchar(8) )DEFAULT charset=ascii; ''' tb_output_fork = ''' create table if not EXISTS tx_output_fork( id bigint PRIMARY key, hash char(64) NOT NULL , tx_id bigint, output_index bigint not null, output_value bigint, address_id bigint, script varchar(1024), asset varchar(64), decimal_number varchar(8) )DEFAULT charset=ascii; ''' tb_tx_fork = ''' create table if not EXISTS tx_fork ( id bigint PRIMARY KEY , block_height bigint, hash char(64) not null )DEFAULT charset=ascii ;''' tb_input_fork = ''' create table if not EXISTS tx_input_fork( id bigint PRIMARY key, tx_id bigint, belong_tx_id bigint, tx_index bigint, tx_value bigint not null, script varchar(1024), address_id bigint, asset varchar(64), decimal_number varchar(8) )DEFAULT charset=ascii; ''' tb_block_fork = ''' create table if not EXISTS block_fork ( number bigint primary KEY , hash char(64) not null, bits bigint, transaction_count INTEGER , mixhash VARCHAR (128), version char(8) , merkle_tree_hash char(64), previous_block_hash CHAR (64), nonce varchar(128) , time_samp bigint ) DEFAULT charset=ascii; ''' tb_output_asset = '' create table if not EXISTS tx_output_asset( id bigint PRIMARY key, hash char(64) NOT NULL , tx_id bigint REFERENCES tx(id), output_index bigint not null, output_value bigint, address_id bigint REFERENCES address(id), asset_name varchar(64), issuer varchar(64), asset_type varchar(8), description varchar(64) )DEFAULT charset=utf8; ''' tb_input = ''' create table if not EXISTS tx_input( id bigint PRIMARY key, tx_id bigint REFERENCES tx(id), belong_tx_id bigint REFERENCES tx(id), tx_index bigint REFERENCES tx_output(output_index), tx_value bigint not null, script varchar(1024), address_id bigint REFERENCES address(id), asset varchar(64), decimal_number varchar(8) )DEFAULT charset=ascii

我们按照元界区块链的结构,可以把表分为四大类: 第一类是区块 block; 第二类是交易 Tx; 第三类是交易输入输出:tb_input,tb_output; 第四类是分叉处理。 下面我贴一个普通的以 JSON 格式展示的区块和交易,你可以对比一下和上述表的关系:

image

从交易平台开发归纳出来的数字货币钱包服务。

数字货币钱包服务可以为交易平台其他模块提供接口统一的 API,同时将不同的数据结构化到数据库服务中,最后可以通过传统高可用手段完成交易查询和验证。 当然,这也和交易所的规模有关,如果是一个小型交易所,扫块可能不是必需的,但是统一接口的 API 却是必须的。我认为数字货币钱包服务应当有一套标准的钱包服务框架,支持主流数字货币,从而降低大家的使用和部署门槛,这也和我们上一篇聊到的 “区块链即服务” 的概念不谋而合。可以说区块链的配套设施和技术还很原始,还有很大的发展和提升的余地

image

在 Back-end 部分,元界区块链承担了货物追踪和订单撮合的职能,而所有参与方可以通过搭建属 于自己的元界区块链节点服务,获得链上的订单信息。 在 Front-end 部分,工作人员可以通过移动设备获得订单数据,工作人员也可以像以前一样,通过 IoT 蓝牙传感器获得货物的数据,接着通过移动设备上传至服务器,由服务器挑选并计算后登记到 元界区块链上。 两者的比较 公链方案与DLT 技术相比,具备以下优势。

透明度高:对于可公开的信息,零售环节的普通购买者也能够通过区块浏览器查询到产品来 源。
不可篡改性:由于公链的共识算法的不可篡改性比 DTL 技术更强,且参与的节点更多,所 以数据的真实和可靠性更好。
Token 转移:由于区块链本身支持 Token 登记,所以物流提单可以做成 Token ,变成有价证券 进行转移。
参与性强:任何客户、政府或是监管机构都可以参与到供应链流程整个或某个特定环节,并跟 踪与浏览者相关的某些公开或非公开信息。
共享公链的基础设施,例如参与方不需要再搭建可视化 Web 服务,直接使用区块浏览器即 可,货物 Token 也可以参与到交易平台进行二级交易。 DLT 技术与公链方案相比,具备以下优势。
可控性高:DLT 技术一般严格控制参与方,核心企业的权益可以得到保障。
可快速落地:方案和思路延续传统技术,实施起来方便,对参与方的认知门槛要求低。
匿名性较好:一般公链并没有提供清晰的权限管理和匿名技术,所以企业的数据必须脱敏才可以明文上链,而 DLT 技术不存在这个问题
么行业现状与实际的人才需求是怎样的呢?我们一起来看看。目前区块链领域的人才需求大致可 以分为以下几种。
根据客户的需求,搭建基于 DLT 技术的分布式账本应用,在 DLT 上实现客户要求的业务需求,这类与传统解决方案型的人才十分接近。
公司已经具有了某些行业的资深经验,目标是通过技术选型选择某个公链,在此公链上开发基于区块链的应用。目前游戏与社交类的项目比较成熟,游戏类有以太养猫、LeBloc 等,内容社 区类有 Steemit、币问、币乎等项目。这一类的特点是可以很好地与现有技术结合,在业务层面利用区块链的资产数字化特性,商业潜力大,技术发展空间也很大,进入门槛较低,风险较低。
公司获得融资或者在海外发起 ICO,目标是研发新一代公链,这一类是为了通过改进现有的区块链技术不足而创建的项目,技术发展空间最大,进入门槛最高,风险也最高。
区块链生态基础设施类。数字资产交易平台、数字资产管理、移动钱包、硬件冷钱包、数字金融媒体、区块链咨询、矿池运营等都属于此类,这些都是目前商业利润最高的区块链产业,技 术发展空间较大,进入门槛较低,风险也较低。目前区块链的人才供应需求远远不足以支撑如此庞大的市场。换句话说就是人才极度稀缺,人才的稀缺与过高的估值形成鲜明对比,这也就是泡沫的形成。
与上面的分类相关的,是行业相应需求的编程语言。
第 1 类是 DLT 技术,由于超级账本的流行,DLT 基本以 Golang 为主,但也会涉及应用可视化交互 的问题,毕竟交付给客户的时候,指望客户使用命令行是不现实的,所以不可避免地需要具备一些 前端技术。
第 2 类是公链应用,由于智能合约的存在,使用区块链的门槛大大降低,最流行的以太坊智能合约是以类 JavaScript 的语言 Solidity 编写的,目前也出现了不限定编程语言的智能合约区块链。实际 上,我认为 Solidity 比其他完全开放式的智能合约要安全许多,所以建议你如果打算学习智能合约,还是最好从以太坊入手。
第 3 类是研发自己的公链。目前主流的是静态编译型语言,以 C++ 和 Golang 最为常见,也有用 Rust、Java、C# 实现的公链,SPV 轻钱包型多使用 Java、Python、JavaScript 实现。可以说公链研发几乎都涉及了主流编程语言。
第 4 类是在商业上与区块链最为紧密,但是技术上却是最不紧密的,整体技术栈与传统互联网网络技术差别不大,例如搭建一个区块链财经类网站,甚至不需要任何区块链技术,但是对内容运营有 较高要求

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.