去中心化数据库DB3Network如何做到高性能查询
每次跟别人讲，我们正在做一个去中心化的链上数据库，就会被质疑：区块链的数据库，岂不是性能很差？数据库要的是高性能的增删改查，最好能在几十毫秒内得到相应才好。
难道去中心化数据库就做不到吗？
我们一步一步拆解去中心化数据库Db3Network具体是如何做到高性能查询，还不降低去中心化程度的。为了达到这个目的，我们提出了一个概念：QuerySession 。
在此之前，我想讲讲数据的可信问题。当我们用中心化的数据库的时候，为什么性能很高，有多方面原因，比如数据库索引性能好，本地机房离得近，分库分表做的好等等，其实还有一个关键的点，就是我们信任自己的机房。前面几点很好理解，可为什么信任会很重要？因为你相信自己的机房会正确执行你传入进去的SQL语句，并返回预期的实际结果，甚至数据库实现的代码都是你自己写的，所以你从来不需要去验证结果，更不会需要数据库给你提供什么证据来证明它正确执行了你的SQL。一切都是因为信任。
可以是在一个开放式的非信任的网络环境下，你并不知道执行你的SQL的机房是哪个，背后管理员又有什么动机，没人保证你的SQL会被正确执行。比如数据库运行者会因为自己运行sql的多少得到付费，那它就有很大的动力尽快尽可能多的执行sql，无论你输入什么sql，数据库执行者都给你返回一个随机数，看起来你的很快的得到响应，但结果却是错误的。所以在去中心化网络环境中，我们需要对执行结果进行验证，或执行方需要提供证据证明他正确执行了SQL语句，这也就是非信任的成本，而中心化数据库是没有这个问题的，这也是影响数据库性能的关键。
结果可信
如何做到结果可信问题？
方案很简单：共识。我们的做法跟传统区块链如BTC，ETH没有什么区别，就是一笔交易让网络中所有节点执行一遍，得到同样的结果，达成共识，以此来保证数据库查询的结果是正确的，只有执行了正确的逻辑，矿工才能获得区块链奖励，否则就会受到惩罚。
这里有几个设定：
1、开放的去中心化网络，任何人都可以运行节点去执行交易，即数据的增删改查
2、作为节点，需要质押一定量的token
3、作为激励，矿工节点每正确执行一次SQL，都会获得用户支付的查询费用
4、错误的执行会受到网络的惩罚
5、用户需要为自己的调用支付费用
等一下，为了到达以上几点，不就会导致查询性能很差吗？
激励+惩罚
矿工之所以愿意加入到Db3network的网络，就是因为有激励，可以获得收益。收益可以分为两部分：1、网络增发，2、节点数据服务gas。
网络增发这里先不说，重点讲gas收益。用户每次查询数据，都需要为自己的查询语句带上签名，并支付gas费用。但是gas费并不会立即给到执行查询的矿工手中，而是需要经过一轮结果验证，最终验证通过后才会收到费用。
如下图所示，执行sql的Miner节点，会将自己执行的事件广播到网络中，让网络其他节点验证，只有验证通过后才能获得收益，如果事件不被广播或者验证不通过，则执行节点将不能获得收益，甚至会受到惩罚。所以矿工是有充分的动力提供数据查询服务，并积极提供数据服务证明。
上图可以看出，网络的共识过程其实对用户（client）的查询影响是非常有限的，查询结果可以立即返回而不用等待区块的产生。
但是如果每单次查询都要走这个过程，那网络的带宽消耗非常高，而且很容易出现区块size太大，逐渐导致查询结算延迟，甚至出现区块分叉问题，所以我们的解决方案是整体打包，提出querySession的概念。
QuerySession
这里，我们介绍一个新的概念：QuerySession。当client连接到一个最近的矿工节点后，会开启一个Session，建立client 和Miner之间的链接，这个Session 会持续一分钟左右时间，在这个时间内，client可以跟Miner之间进行多次的数据交互，交互的过程并不会立即上链，而是等Session close的时候，将整个Session信息整体打包上链，这个过程能在不损伤共识的前提下，大幅降低链上数据共识压力。
Query Session 的结构
这里简单展示一个Query Session是大体构成，包含了Session的start_time 和 status，另外就是client是server双方的签名信息，网络会验证这个这个签名信息，并整理出账单等信息。还有个模块就是sample，client端会抽样出在这个Session中的一些 queries 和 respone，打包后，上传到网络进行异步的验证。下面这段代码只是样例，真实的Session数据结构要比这个复杂很多
Query Session 的校验
区块校验的过程大概如下：
1、跟client交互的server会将Session信息提交到Mempool中，作为一笔交易TX，
2、网络中随机节点从Mempool中选择TXs ，置信交易并校验通过，提交一个propose作为区块，
3、网络中其它节点收到propose并同样执行这些Mempool中的交易，并确认交易，
4、区块产生，提供server 的矿工节点得到待结算的账单
具体session上链过程如下图所示：
结论
关于Db3Network的性能问题，我们要解决的问题远不止信任问题，除此之外还有
数据库索引性能问题
数据证明问题
提供服务的机房地理位置问题
分库分表问题
限于文章篇幅，本篇只介绍 结果可信问题。
关于DB3Network
Github：
https://github.com/dbpunk-labs/db3
欢迎任何感兴趣的朋友来我们github上提issue
Twitter:
https://twitter.com/Db3Network
Discord:
https://discord.com/invite/sgY2bbFCzr
文章作者
Twitter： @muran_eth
原文链接为Mirror