10月19日，百度超级链与金色财经在北京联合主办“区块链与数据库的融合碰撞”技术沙龙，IBM、众享比特、conflux、covenantSQL等行业内合作伙伴，共聚一堂，对各自在公链、联盟链等场景中的实际需求和经验，展开热烈的讨论和分享。不仅仅聚焦技术，话题还延展到了“在产业应用中遇到的困难与挑战”，为来自五湖四海的听众解读区块链与数据库的前世今生。

IBM中国开放标准与开源技术实验室软件工程师郭剑南进行了主题为 《如何在区块链中使用数据库》的分享，以下为演讲整理。

本演讲内容主要是从Hyperledger Fabric这个项目当中来的，但是概念或者说想法有可能能够去影响到其他的项目。

这个演讲分两个层面，首先是如何把区块链当做一个数据库来使用，这也是很多应用开发者和区块链的使用者熟悉的，比如它能够给我带来什么特性，能不能像普通数据库一样使用。其次是区块链中使用了什么数据库。

首先我从数据库的角度对区块链做个诠释，就是Replicated Database that Tolerates Byzantine Fault，它本身是对分布式数据库中的一个副本，或者说实现了分布式状态机。只不过区块链把一个节点的数据复制到其他成千上万个节点，并且保持最终一致性。这（数据库的复制）在区块链之前就是经常去做的一个技术，使用场景包括容错、并发等等的，这是一个一直都有的技术。但是我们这里要注意，在区块链中我们的节点通常是对称的，在分布式数据库中可节点并不一定是对称的。

区块链这个分布式数据库有几个特点，首先它需要对每一个节点去写，或者说管它叫做Multi-Master。第二要支持事务性，第三就是这个数据库的一致性算法，在区块链中把它叫做共识算法。如果说把区块链当做一个数据库来看，它其实要支持的东西是非常高度类似，只是最后要容忍拜占庭错误，相对于数据库来说比较特殊，也是跟分布式数据库有差异的核心点，分布式数据库更多使用的是CFT（Crash Fault Tolerant）。但是依然跟分布式数据库达到的目的是一样的。在所有的节点不管是最终一致性，还是强一致性，最终的效果其实是一样的。所以说下面我写了这句话，不管说你从什么样的角度去看分布式数据库或者区块链，都是要将同时写入不同节点的交易进行序列化。所谓共识，其实就是对这个序列进行共识。

既然是序列化，究竟是对什么东西序列化，我们来对比一下区块链和数据库，一个分布式数据库里面，通常做Replication的话有几种方式，比如说我们把原始的操作进行一个序列化，然后这样在每一个节点重复执行原始的操作，达到最终一致的效果。里面就要求这些执行一定有确定性（deterministic），不能某个节点执行之后出现不同的结果，否则就违背了它的一致性要求。在分布式数据库中，它其实要达到的共识的是执行语句的顺序，执行语句通常由Master向Replica进行分发，没有需要去容忍拜占庭错误，Replica会无条件的相信Master下发的执行语句，在本地只要进行重复就OK了，这是分布式数据库要做的事情。在区块链当中一样，我们要去对一些东西进行序列化，并对这个序列进行共识，但是它序列化的具体内容，我后面也会讲到，分为两种。我们暂时认为是对某种信息进行一个共识，然后能各自的把这个信息去重复，在本地的数据库当中达到同样的一个结果，这其实是区块链要做的事情。但是它跟数据库显著的差别就是平等的节点，或者说对称的节点，并且都能够去共同的参与到对于这些信息的共识当中，虽然在一些共识算法中，某个时刻一些节点会是领导。

在下面谈一下区块链究竟对什么样的信息进行共识，大家一直在说共识，但较少得谈到共识的内容，我这边更倾向于说对于序列化，也就是全局去确定一个顺序，所以其实就是许多共识的本质。序列化的内容分两种，一个是对于Input，一个就是对于Output。比如说以太坊，它其实是对Input进行共识，或者排序。这个图左边是以太坊的数据结构，大家可以看到在每个块中都包含这样的Input，大家如果提交过以太坊交易，就知道Payload其实就是你提交的内容。然后当节点对这个交易输入进行共识之后，我们再执行合约，最终产生的结果保存在本地账本当中，也就是说我先有了一个确定性，排序好的全局的交易，然后我再独立的把这些交易进行重复，得到了一个最终的状态，也就是说这是一种对Input共识。第二种是对Output进行共识，也就是说每个节点拿到交易之后，会各自执行一下这个智能合约，但是它得到的其实是读写集，也就是我们最终修改的数据是什么，智能合约之后产生的结果是什么，然后我对这个读写集打包的区块进行共识之后，每个节点拿到读写集，简单的把它重复到数据库当中就可以得到最终一致的结果，也就是它对Output进行共识，这里的Input和Output相对于智能合约来讲的，而不是相对于本地数据库来讲。

HyperledgerFabric这个项目是从2015年开始的。一开始，它也是先排序再执行，这跟其他很多区块链项目没有区别，完整地实现了pbft加上基于Docker的智能合约。但是在1.0中，很显著的借鉴了数据库的思想，也是因为当时参与架构设计的人很多都是之前做数据库的，比较明显的就是MVCC，这其实是数据库里面比较常见的概念。

这边会简单介绍一下Fabric的执行过程，因为很多在场的人不太了解。Fabric其实是分三步，也就是说执行、排序和验证。在区块链当中你的客户端会发送Transaction给多个节点，这个取决于你的背书策略，根据你的业务来指定。节点接收到交易后，会执行合约，交易完成之后它会把这个执行的结果，比如读了什么数据，改了什么数据，打包在一个返回结果里面，反馈给你的客户端。客户端收到这些背书之后，提交到排序节点，这个可以理解成一个出块节点，他负责把这个交易进行一个全局的排序，最后把区块返回给这些提交交易的节点，就是我们的Peer。Peer会把这些区块打开，里面看到的就是之前已经执行过得到的读写集，并且有一个全局的一致性的顺序。Peer从头到尾很简单得遍历一遍这些读写集，所有节点就能得到全局一致的最终状态，所以说大家比较记住的一点，就是在Fabric当中，我们打包的其实是智能合约执行后的结果。

Fabric也用到了一些开源数据库，刚才吴总刚才所说的非常准确，现在依然是使用LevelDB和CouchDB。CouchDB相对于LevelDB有更加丰富的查询能力，在智能合约安装的时候去进行指定，比如我把年龄做一个索引，之后查询的时候会更加快速一些。另外可以相对于LevelDB来说，CouchDB有一些复查询问能力，或者是批量修改的能力，这个也是数据库本身提供的能力。另外很早的时候，大概2016年左右就提了支持SQL，当时是提的PostgreSQL，对它做一个支持。但是由于各种原因，这份工作现在也是暂停状态。

刚才是整个执行过程，现在把它放大来看，具体实现过程是这样的，我们在这个过程当中会有一个模拟器，它其实相对于劫持了你对数据库的写操作。合约是通过一层shim接口与peer通讯的。当peer接受到对数据库的请求之后，先通过模拟器，所以当你对数据库进行读写的的时候就已经记录了这些操作，但是写数据不会影响到数据库的状态，所有人都对数据库进行写的时候，其实是看到的同样的状态，并且不会当时影响数据库的内容。这里有一个比较大的影响，在同一个智能合约中，你虽然写了数据，但是在同一次执行中无法读到，也就是目前不支持read-your-own-write这个概念。在当前版本中，读写集是用区块的高度来表示，像刚才说的打包作为一个交易去执行后面的排序工作，产生了区块之后会返回给你的peer，它会做几种检查。第一是签名，第二是背书策略，第三个是MVCC，这个MVCC是性能的瓶颈。原因除了写代码的有一些问题，另外一个原因就是天然决定了它对于序列的要求。首先从每个区块到了之后从头到尾遍历了一遍，检查你的读集是否一致，一致就写到数据库里面，如果一个交易的读集出现冲突，这个交易会被标记为无效。

图中左边展示的是合约可以使用的对数据增删改查的接口，基本都是针对键值对的操作。右边展示的是如果使用CouchDB能够利用的富查询接口，传入一个字符串，会编译成为CouchDB的查询语句。

最后想讲几句话关于SQL，这个比较早在社区提了出来，但是这个工作现在目前是一个暂停状态，如果有人愿意贡献，可以去接这个活儿。它的目标比较简单，就在Fabric当中实现SQL数据库的支持。好处也是显而易见，主要有两方面。首先，很多开发者还是比较依赖于SQL数据库，希望既可以写智能合约，也可以直接写SQL。如果一个数据库直接在用户节点暴露出来进行查询，其实也是相对来说比较简单和容易一些，而且对于SQL数据库有很多已有的经验可以借鉴，总的来说是实现了更好的开发者体验，让开发者能够更加简单开发应用。第二点，是支持SQL数据库对于Fabric本身来说也有很大的好处，我们可以达到更简单的架构。比如说在备份节点的时候，直接使用SQL数据库的能力，不通过拉取所有区块来做的话，比较简单的实现一个数据库的备份或者是迁移。在SQL的数据库通常提供了历史查询、修改历史。使用SQL数据库，对Fabirc来说也有一个比较大的简化空间。不过一个比较大的问题事，我们去支持SQL，本身代码需要很大程度的重构，也是阻挠工作进展比较显著的一个问题。

以上就是我今天想分享的内容，谢谢大家。

如果你是区块链开发者、技术发烧友，

欢迎加入超级链开发者社群。

加群方式：添加百度超级链小助手微信（image-baidu），

回复：我是开发者