ChainSQL:基于数据库操作日志的区块链数据查询

总所周知,区块链是一种去中心化链接数据结构,本质上设计用于防止数据篡改。但如果用户想要查询存储在区块链中的数据,实现非常繁琐并且效率不高。中科院深圳先进技术研究院的一项研究ChainSQL意图解决此问题。项目的论文“A Blockchain Database Application Platform”于今年九月发布在预发表网站ArXiv上。项目的网站是http://www.chainsql.net/,可以从官方网站下载白皮书,开源地址是https://github.com/ChainSQL。目前已有66颗星。

简介

ChainSQL考虑将分布式数据库与区块链结合在一起。数据库技术经过四十多年的发展,是提供快速查询处理的主要手段,但是在实现有效数据查询的同时,数据可靠性问题并非数据库设计中的主要关注点。ChainSQL为区块链提供了良好设计的数据结构,实现了去中心和、分布式、防篡改、可审计、多活的数据存储,并提供了数据层面的灾难恢复机制。下面我们基于论文介绍ChainSQL的关键特性实现,具体特性可参考ChainSQL白皮书。

ChainSQL是一种基于区块链的日志数据库,它组合了区块链技术和分布式数据库的特性。ChainSQL主要针对两种用例,一种是将企业应用与数据库系统结合在一起的多活数据库中间件,另一种是连接数据库生产阶段和灾难恢复节点的数据库灾难恢复中间件。这两类中间件用来都是用来连接企业应用与底层数据库。ChainSQLde主要亮点包括:一、提供了访问个人用户数据的认证功能,提高了数据的安全性。二、交易存储在区块链中,而实际数据存储在数据库中。三、多对一的灾难恢复架构,支持单一备份中心为多个生产站点提供备份。四、易于与MySQL、Oracle、DB2等现有数据库集成,并使用API编程。五、数据库操作历史存储在区块链中,支持审计。这些亮点使得ChainSQL不仅提供传统的数据库实例,而且提供区块链的安全性。

结构

从结构上看,ChainSQL由区块链网络、分布式数据库和用户组成。基本结构如下:
1. ChainSQL使用区块链网络Ripple。Ripple支持快速发布和验证交易,它采用一种称为UNL(Unique Node List)的方式避免了区块生成中使用过量的计算。
2. 在区块链节点基础上配置了分布式数据库,数据库使用区块链同步,并使用了区块链的read操作。
and facilitates quick database like blockchain ‘read’ operations.
3. 提供了三种查询方式:直接查询区块链网络、创建用于快速存取的数据库区块链节点,以及结合二者的查询。示意如图一所示。


图一 ChainSQL提供的三种查询方式示意图

ChainSQL的主要组件包括:

  • 应用接口(Application Interface):访问区块链需要通过API,API提供了应用的接口,使得对用户而言区块链的交易命令类似于数据库操作。ChainSQL API支持多种编程语言,实现了灵活性和可应用性。

  • 数据库操作(Database Operation):数据库操作是在实时环境中执行的。区块链网络将交易数据直接传递给相应的数据库,并由数据库处理。共识机制用于验证交易的有效性,实现为:在ULN模式中指定了验证交易的一组区块链网络节点。交易一旦通过验证,就将发送到区块链网络实现共识,进而写入到数据库中。一旦共识失败,数据库操作回滚。整个过程可在数秒内完成,因此从用户角度看是近实时完成的。

  • 数据库恢复(Database Recovery):在区块链网络中,一个节点配置了用于恢复的数据库,该数据库中存储了区块链中的交易,或者是重建数据库的操作过程。区块链网络支持阶段为存储区块链网络全部交易的完全记录节点,或是存储部分交易的部分记录节点。

用例

ChainSQL的启动运行情况如图二所示。这里给出两个基本用例。


图二 ChainSQL启动过程示意图

多活数据库中间件

多活数据库是一种连接企业应用和底层数据库的中间件。底层数据库可以是任何传统关系型数据库,以及NoSQL数据库。区块链维护了操作日志,其中记录了数据库中所有的数据定义和操作,是不可修改的。操作日志可用于重新生成数据库,因此可用于数据库审计。用户应用调用ChainSQL API获取适用于区块链网络的交易数据,并将交易数据发送给网络节点。网络节点在将交易数据发送给网络中其它节点之前,会对新到来的数据做认证并验证。网络节点通过对以交易形式提交的数据达成共识而打包形成区块。如果达成共识,网络中的每个节点将以区块形式保存同一数据。每个节点配置了一个数据库,节点将数据发送给数据库,并同步数据库操作。一旦节点出现故障,用户可无缝地切换到另一个节点。该机制保障了零恢复时间和实时多活数据库部署。在恢复时,故障节点根据最近的监测点恢复。多活数据库中的一个关注点是数据在网络中传输的安全性。ChainSQL提供了对称和非对称加密机制,用户可选择适当的安全机制。多活数据库的另一个主要关注点是可扩展性。新节点可以自动地从已有节点获取操作日志,并参与到构建共识和同步数据写操作中。

多灾难恢复中间件

多灾难恢复是一种连接企业应用中数据库生产节点和灾难恢复节点的中间件。如上所述,在数据库中,用户操作记录在操作日志中。在灾难恢复时,第一步是实现区块链网络的共识,该步骤可保证所有操作日志数据的一致性。一旦生成了新的区块,指定的备份节点将读取区块并将其发送给灾难恢复中心。恢复中心使用交易数据执行数据库备份。这样,如果在生产环境中有节点故障,用户可切换到恢复中心,备份节点提升为生产节点。恢复中心在10秒内可提供操作日志,对故障生产节点重新执行基于用户设定恢复点的恢复操作。

结论

结合区块链和数据库,提供了可靠的数据管理和恢复机制,这使得ChainSQL在金融和供应链等具有数据可靠性要求的领域。当前开源的ChainSQL提供了一个基础平台,可进一步研究数据分析能力、数据分片技术、验证技术等。

基于区块链的安全数据库交易日志管理

大家在看区块链相关技术时,难免会产生一个疑问;“传统技术都能解决的问题,我们为什么还需要区块链”。

对此问题,很多业内专家都从很宏观的角度给出了解读。我们注意到,一些研究从“区块链技术作为传统技术有益和必要的补充”的角度,考虑了分布式系统、数据库、FinTech等领域。下面,我们将对其中一些代表性研究做出分析。

首先,我们看的是收录在2018年Dependable Computing Conference上的一篇论文,“A Prototype Evaluation of a Tamper-resistant High Performance Blockchain-based Transaction Log for a Distributed Database”,由罗马大学和南安普顿大学的研究人员合作完成。

确保数据完整性是很多现代业务的基础需要。在传统数据库中,交易历史以重做日志文件的形式记录。一旦出现问题时,数据库使用重做日志恢复交易。但是,重做日志的安全性一般由操作系统保证,易于被恶意篡改和伪造,进而破坏数据的整体完整性。区块链提供了强大的数据完整性保证,但是其在性能上的局限性限制了它在现实中的广泛应用。在这项研究中,研究者提出了一种多层区块链架构,用于维护分布式数据库的重做日志。具体而言,第一层为一种高速区块链,实现共识算法,并将安全相关机制导向基于PoW的第二层区块链。研究进而提出了使用拜占庭容错共识和DHT(分布式哈希表)改进可用性和可扩展性上的一些考虑。

基本架构

该研究提出了一种称为2LBC(2-layer blockchain architecture)的架构,如图一所示。其中,第一层实现为私有(permissioned)链,第二层实现为公开链。第一层使用基于领导者轮换机制的高速共识算法,即将时间分成多轮,各位矿工根据固定的公平策略在每轮上轮流坐庄,担任领导者。交易顺序由领导者确定,交易的账本中记录的是重做日志的具体内容。和其它区块链一样,交易一旦经由各方使用非对称加密算法签名,将存储在各方的账本副本中。在典型的联盟应用中,区块链各方用户称为联盟成员。这样,每个联盟成员向2LBC提供一位矿工。该矿工是网络中的一个代表性节点,保持数据库和账本的副本,并维护区块链的完整性。第二层实现为使用PoW确保完整性的公链。第一层区块链的哈希周期性地通过导向管理器(图一中的Anchoring Manager)存储在第二次区块链中。PoW确保了哈希的不可变性。如果有恶意矿工试图修改账本中的重做日志,将导致第二层中存储的哈希不一致。


图一 用于联盟应用的2LBC架构

具体实现中,论文使用Java实现了第一层区块链。矿工加入P2P网络,通过由客户操作、序列号或是时间戳等工作负载组成的交易进行交流,并由矿工的签名认证。矿工可以相互间直接通过JavaRMI通信,也可以使用JGroup (http://jgroups.org/)通过广播机制通信。客户在操作数据库时,通过JavaRMI向所有矿工发送两种操作

  • set(k,v),将值v指定给键k,返回值为布尔值,表示客户是否确认。
  • get(k),通过返回交易,获取键k所存储的值。

共识的实现需要针对2LBC做一定修改。对于给定set(k,v)操作,矿工必须达成共识,才能向客户给出确认。共识基于三阶段提交协议(3-PC)。客户向所有矿工广播一个set操作,矿工使用Verify Manager验证set操作的正确性,并在通过验证后将该set操作添加到队列中。一旦当前指定的领导者提出和set相关的交易,其它矿工从自身队列中移走该set操作,并广播自己签名,构建相应验证。当验证包含了所有的签名,所有矿工将交易提交到自身的账本副本中,并触发对数据库副本的更新操作。对于get操作,每位矿工向客户符合最近set操作相关的交易。客户可以从最近交易中获取值v,并使用矿工的签名验证其正确性。一旦当前领导者坐庄的时间到,它以一种特殊交易的方式触发领导者轮换事件。退位的领导者在第一层区块链上计算SHA-1哈希,并将公正交易发送给第二层上的指定验证智能合约,智能合约使用以太坊实现。

实验采用6个节点的虚拟机网络。对于set操作,图二(a)和(b)分别给出了通量和延迟情况。从结果看,通量要显著高于以太坊,延迟显著低于以太坊。整体共识算法需要矿工对每个操作交换所有签名,因此在240交易/秒左右出现不稳定的情况。此外,领导者轮换对于队列操作引入了一定的开销,比平时高50%左右。图二(c)和(d)分别给出了get操作的通量和延迟情况。get操作并不受领导者轮换的影响。


图二 对2LBC架构中set和get操作的通量和延迟的实验评估情况

性能改进

由上可见,基本2LBC架构的主要问题在于可用性和可扩展性。具体而言,由于共识上的考虑,在架构中添加节点,并不会直接提升架构的整体性能。

为解决可用性上的局限性,初步考虑基于PBFT实现拜占庭容错算法。一般情况下,为容错f个矿工,需要3f+1可靠的矿工。这可以降低验证可信矿工的代价。在提交交易时,可以考虑等待至少f+1可信签名才能提交一个交易。为解决可扩展性上的局限性,初步考虑对私有(联盟)链实现数据分片。这里可以引入基于DHT的账本,其中每个矿工基于键空间分区,每个键具有一个可配置的副本因子实现容错。

结论

2LBC作为一种双层架构的区块链,在保证高性能、高安全性的同时,提供了去中心化环境中的强数据完整性保证。此外,进一步结合拜占庭容错和DHT数据分片,可以改进架构的可用性和可扩展性。该架构适用于与传统数据库应用结合,为重做日志提供完整性,进而提高数据库的安全性。