2018 年 7 月 14 日，标准共识成功举办了首期线上技术分享会，主讲人周迅就「智能合约的数据存储」与标准共识技术评审团成员及 20 位嘉宾成员分享了技术经验。

周迅是一家区块链公司的 CEO，对以太坊有着深刻的理解。目前团队核心目标是做一个工程师易上手的实用版以太坊。以下整理自周迅的分享内容。

只发 Token 无意义

我之前在一家媒体分享过我认为 DApp 开发平台的共识机制应该是什么样子。我说我们核心解决的问题是：如何让开发者把业务也放到链上，而不只是发个 Token，把「积分」上链了。

今天我们就先不讨论逻辑上链的必要性，我们从技术上考虑怎么让逻辑上链。

既然是区块链的数据存储，默克尔证明就必不可少。默克尔证明保证了数据的可验证性和永久保存性。可验证就是提供一个根，就可以得到一个 key 对应的 value，永久保存性就是每次对默克尔树进行更新的时候，旧的树根都是可以读取所有的数据的。

虽然默克尔的功能非常强大，但是默克尔证明有个很大的问题：只能存储 Key-Value 类型的数据，虽然可以在数据序列化和反序列化的时候做一些扩展，但是功能非常有限。

数据储存的三种解决方案

我们团队就在想：是否可以让 DApp 的开发者可以使用 SQL、Mongo 这样的数据库进行 DApp 的开发呢？

然后调研了三个方案：

1、类似于 EOS 的 MySQL 插件和 Mongo 插件，这种实现起来是最简单的，所有的工作都是交给开发者去做，自己这边只需要做一个连接管理就可以了。

2、对默克尔字典树进行更新，叶子节点可以存储多列数据（List)、可以存储 Map，也可以存储简单的 value，这种情况下如果 len（list）特别大的情况下，不会像只存储一个 byte，然后反序列化为 list 有特别大的内存和 CPU 开销。

3、默克尔树只存储简单 KV，在上层封装一层 SQL layer。

三种解决方案的思考路径

我下面先说第三种方案：不知道大家听说过 pingcap 没有，我们主要研究的方案就是他们的 tikv 和 tidb，我们使用默克尔字典树替代 tikv，tidb 就可以直接使用了，只需要修改底层数据读取的相关逻辑即可，因为 tidb 读取 tikv 的时候其实也是有多个 tikv 服务器的，所以默克尔树的读取效率可以说不受太大的影响。

但是，第三种方案有一个特别大问题，对于开发者来说，我们封装的 SQL layer 只是个 SDK，对于轻客户端来说，无法验证数据的有效性。

因为轻节点还是要把对应的默克尔树读一遍才知道数据是否是正确。

第三种方案是我们研究的时间最长的一种方案，但最后发现，对于轻客户端来说这个基本上没有太大的意义的，所以选择了放弃。

第二种方案对默克尔树的修改比较简单，也比较能实现复杂逻辑的方案。

这种方案对于开发者来说也是非常友好的，它可以很方便的让开发者把一个可能有很多条数据的 list 拆分开去存储。

当然，它的问题在于在根据非主键查找/更新 list 的时候效率会比较低。对于这一方案，我们团队目前一直在研究。

接下来讲第一种方案。它就是直接使用 MySQL、Mongo 这种数据库的方案，我们考虑过使用网络数据库，但是可能是有很大问题的。

比如某一个节点对数据库服务器的网络中断了，可能就会出现一些问题。所以，我们在前期考虑的是使用嵌入式的 SQL 数据库，比如 sqlite。

对于第一种方案，我们也在考虑的原因是，我们是把 sql 这种类型的数据库当成了一个节点的「私有空间」，在一些数据不方便公开的时候（比如斗地主的随机数），是不方便写到默克尔树里去的，这个时候就可以放在SQL 里面，当适合更新到默克尔树里面的时候（一局斗地主结束），再把数据从 SQL 中读出来，写到第二种方案的默克尔字典树里面。

总结

1、更新后的默克尔字典树用于存储可校验的公开透明的数据；

2、嵌入式的 sql 数据库用于作为私有的存储空间，让开发者存储一些不适合公开的数据或者带有条件查找的数据，带有条件查找的数据可以指向默克尔根，方便轻节点对数据进行校验；

这些其实是业务逻辑的数据存储。当然，除了业务逻辑的数据存储，可能还会有一些文件的存储需求；这个时候可能就需要一些第三方的存储了，比如 IPFS。

需要说明的是，IPFS 虽然做了很多工作，但是无法实现文件的分区高可用，我认为可能适合存储一些不是那么重要的数据，电子合同之类的肯定是不能存储在 IPFS 里面的（虽然文件丢失的可能性基本为 0，但是某一个时间内不可用的可能性还是有的）。

相关推荐

必看：区块链存在比较容易忽略的两个问题

区块链专利申请数中国名列前茅，市场发展前景广阔

区块链大交易所洗牌开始!你慌了吗?

点击查看更多精彩内容【18183财经频道】