10月19日下午，由百度超级链学院与区块链网联合主办的百度超级链学院线下技术沙龙《区块链与数据库的融合碰撞》在北京科技寺创业空间滚石店顺利举行，现场汇聚了来自阿里、腾讯、京东等知名企业从业者以及区块链技术爱好者共同讨论、分享和学习行业及技术知识。主题分享及讨论参与嘉宾包括：百度超级链资深研发工程师孙君意、百信银行开放银行区块链技术负责人梁俊锋、Conflux研究总监杨光先生、众享比特实验室主任吴飞鹏、众享比特方案中心总监周世晟、众享互联技术总监章锋以及IBM开源技术实验室软件工程师郭剑南。

以下为演讲整理（有删改）：

郭剑南：大家好，我是郭剑南，现在在IBM开发中心，是一名软件工程师，主要是从事云计算，区块链领域的开源软件开，目前是Fabric的代码维护者之一。首先想简单了解一下现场大家听说过Hyperledger Fabric项目的请举手（现场约50%听众举手），谢谢大家。我在这里先做一个开源广告吧，Hyperledger是Linux基金会旗下的开源项目，现在有包括百度，阿里，腾讯等很多会员公司参与，是一个完全开放的社区，随时欢迎大家来参与。

今天其实发给我这个题目以后，我也比较慌，因为之前从事的都不是数据库相关的工作，这个题目虽然比较广泛，但其实要思索可讲的内容还是需要费些脑筋，而且作为最后一个演讲的人，之前嘉宾关于这个题目都讲的差不多了，我这边只能查缺补漏，从区块链的角度，谈一谈对数据库的使用，或者数据库相关服务的工作。本演讲内容主要是从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相对于智能合约来讲的，而不是相对于本地数据库来讲。

Hyperledger Fabric这个项目是从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，本身代码需要很大程度的重构，也是阻挠工作进展比较显著的一个问题。

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