WO2020108289A1 - 一种数据库系统、节点和方法 - Google Patents

Abstract

本发明提供了一种数据库系统的交易方法以及节点设计。节点在接受到客户端发送的请求后，直接在本地状态机上模拟执行生成一个模拟执行结果，并将此模拟执行结果与用户执行逻辑打包，复制给其他节点进行防篡改检验；网络中的其他节点收到消息包后，从中取出用户执行逻辑在本地进行执行生成模拟执行结果，然后再对比消息包中的模拟执行结果；如果两份结果不一致，代表存在数据篡改情况，回复验证失败给发起节点；如果两份结果一致，回复验证成功给发起节点；验证发起节点收到足够多的验证回复后，汇总判断，判断验证失败的请求直接被丢弃，判断验证成功的请求以模拟执行结果集进行pbft共识复制逻辑，直至状态复制结束或失败。

Description

一种数据库系统、节点和方法

本申请要求于2018年11月29日提交中国国家知识产权局、申请号为201811446359.6、申请名称为“一种数据库系统、节点和方法”以及于2019年10月29日提交中国国家知识产权局、申请号为201911038474.4、申请名称为“一种数据库系统、节点和方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及数据库技术，尤其涉及一种基于区块链技术的数据库设计。

背景技术

区块链是一种将数据区块以顺序相连的方式组合成的一种链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。区块链根据去中心化的协议，构建了一个分布式的结构体系，让价值交换的信息通过分布式传播发送给全网，通过分布式记账确定信息数据内容，盖上时间戳后生成区块数据，再通过分布式传播发送给各个节点，实现分布式存储。

智能合约是随着区块链技术发展产生的一种新特性，智能合约实质上是交易双方合约的代码化实例，它根据双方合约规定对接收到的信息进行回应，可以接收和存储价值，也可以输出信息和价值，它扮演着一个可被信任的系统，总是按照事先约定的规则执行操作。

关系数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。当前大部分业务系统的业务关系均可以用关系数据库的模型来定义。标准数据查询语言SQL是一种基于关系数据库的语言，可以通过此类语言对数据库中的数据进行检索和操作。

基于现有的区块链方案，无法实现关系型数据库中的数据管理能力，也无法实现数据的事务操作。因此，难以满足大型数据系统对数据管理的需要。

发明内容

本发明实施例提供一种数据库系统，包括交易方法和节点，实现了用户可以在保持对原有关系型数据库使用方式的情况下，将对传统区块链的使用方式也向数据库使用方式转变，并将二者融合为一个系统，系统统一协同管理两块数据。本发明数据库系统兼容关系型数据库中的大部分特性，包括SQL支持、关系型结构存储、ACID事务保证等。同时增加了更多的区块链特性，具备区块链防窜改的特征，其中包括具备防篡改的拜占庭共识协议、事务区块链、智能合约等特性。

第一方面，本发明提供了一种数据存储的方法：请求接受节点在接受到客户端发送的请求后，直接在本地状态机上模拟执行生成一个模拟执行结果，并将此模拟执行结果与用户执行逻辑打包，复制给其他节点进行防篡改检验；网络中的其他节点收到消息包后，从中取出用户执行逻辑在本地进行执行生成模拟执行结果，然后再对比消 息包中的模拟执行结果；如果两份结果不一致，代表存在数据篡改情况，回复验证失败给发起节点；如果两份结果一致，回复验证成功给发起节点；验证发起节点收到足够多的验证回复后，汇总判断，判断验证失败的请求直接被丢弃，判断验证成功的请求以模拟执行结果集进行pbft共识复制逻辑，直至状态复制结束或失败。

相比与现有技术，在共识之前增加了防篡改验证逻辑，且使用通过验证的模拟执行结果进行复制，既达到了防篡改设计，又能维护好状态的一致性。

第二方面，本发明提供了一种包含链上与链下数据的事务处理方法：客户端发起链上链下事务操作，事务中同时包含了链上数据更新操作集和链下数据更新操作集；服务端事务请求接收节点在接收到请求后，开启一个事务管理器，按照事务请求中的操作顺序进行处理，进行事务预提交，产生两份事务处理逻辑日志缓存，同时向链上事务缓存池中增加链上事务产生的事务日志，事务日志包括事务执行逻辑；以链上事务产生的事务日志发起背书流程，如果背书流程成功，请求接收节点以起共识流程。如果共识流程成功，请求接收节点将包括了链上事务和链下事务产生的预提交进行真正提交，其他节点只接收到了链上事务，所以只对链上事务进行提交，至此，请求接受节点完成了链上链下事务操作。

相比于现有技术，本发明保证了事务的原子性，是的同一事务的链上数据与链下数据能够基于事务处理逻辑进行更新操作。

第三方面，本发明实施例提供了一种包含多个链上数据的事务处理方法：客户端发送交易时，需要标记该交易涉及跨链并指明跨链事务中的每条交易分别属于哪条链。服务端收到客户端的跨链交易请求时，首先对事务中的交易按顺序进行编号，并将该事务中的所有交易按照所属链进行拆分。每条链分别执行该链涉及交易的背书流程，流程即单链背书流程。服务端交易发起节点汇总收集到的背书结果，对于跨链事务，当事务中所有被拆分的交易的背书结果都符合所在链的背书策略时，视为背书成功。背书成功后，将请求拆分结果、每笔交易编号和该跨链事务共涉及哪些链打包复制给对应链的节点，进入系统的共识模块进行共识。每条链独立进行共识流程，流程即单链共识流程。每笔交易编号和该跨链事务共涉及哪些链需要作为交易信息的一部分，后续所有消息的复制都必须附带这两个信息。提交阶段，当前链共识完成之后，进入等待状态，读取该跨链事务所涉及的链的所有节点，将该链的共识结果发送给这些节点。同理该链也会收到所有其他链的共识结果，当收到某条链超过50％节点共识通过的反馈后，即视为这条链共识通过。若该交易涉及所有链都共识通过，即表明跨链共识通过。如果某个节点包含多个链，则需要按照交易编号顺序依次提交每笔交易。链上节点仅提交事务中与所在链相关的交易，如果节点加入了跨链事务中所涉及的多条链，则按照交易序号在不同链上分别提交与该链有关的交易。

在一些实现方式中，该方法还会配置一条系统链，该链可以被网络中所有节点访问，用于记录网络中所有链的成员信息。当网络中创建一条新的链时，在系统链中增加一条记录；新的节点加入链，则由链的创建者更新该条链的成员信息，并同步到整个系统。

相比于现有技术，本发明实施例，本发明保证了事务的原子性，是的同一事务的 多个链上数据基于事务处理逻辑进行更新操作。

第四方面，本实施例还提供了一种数据节点，该数据节点包括了多个功能模块，通过多功能模块，使节点能够实现上述第一、第二、第三方面所描述的功能。

第五方面，本发明实施例还提供一种计算机系统，该计算机系统作为数据库系统中的一个节点。该计算机系统包括至少一个处理器和存储器，其中，该存储器用于存储软件程序，当所述软件程序被所述处理器执行时，该计算机系统的处理器用于执行前述第一、第二、第三方面的方法或者任意一个实现方式中的方法。

第六方面，本发明实施例还提供一种存储介质，用于存储计算机程序，当所述计算机程序被处理器执行时，所述处理器用于实现第一、第二、第三方面提供的任意一种方法。具体的，所述计算机程序可以包括用于实现方法各个步骤的一个或多个程序单元。

可见，本发明实施例提供区块链系统交易方法以及节点。实现了数据库系统中数据管理和防篡改机制的融合，降低了部署、管理和运维的成本。同时，一套系统中可以支持多个链上数据以及链下数据的事务处理能力，提高了系统的任务协同效率。

附图说明

为了更清楚地说明本发明实施例或背景技术中的技术方案，下面将对本发明实施例或背景技术中所需要使用的附图进行说明。

图1是本发明实施例提供的一种数据库系统的系统架构图；

图2是本发明实施例提供给的一种数据库的存储结构的示意图图；

图3是本发明实施例提供的一种数据库系统的数据存储方法的流程图；

图4是本发明实施例提供的又一种数据库系统的数据存储方法的流程图；

图5是本发明实施例提供的又一种数据库系统的数据存储方法的流程图；

图6是本发明实施例提供的一种数据库系统中的链上与链下数据进行事务操作的流程示意图；

图7是本发明实施例提供的又一种数据库系统的数据存储方法的流程图；

图8是本发明实施例提供的又一种数据库系统的跨链事务的背书与共识的流程示意图；

图9是本发明实施例提供的一种数据库系统中的跨链数据进行事务操作的流程示意图；

图10是本发明实施例提供给的一种数据库系统中节点的硬件架构示意图。

具体实施方式

下面结合本发明实施例中的附图对本发明实施例进行描述。

首先介绍的区块链网络架构中的一些概念。

客户端(Client)：用户可以通过区块链系统中的客户端实现创建链码，发起交易等功能。客户端可以部署在任意的终端上，通过区块链系统相应的SDK(Software Development Kit，软件开发工具包)实现。该终端通过与区块链网络中的节点进行通信，从而实现客户端相应的功能。

区块(block)：在区块链技术中，数据以电子记录的形式被永久储存下来，存放这些电子记录的文件我们就称之为“区块”。区块是按时间顺序一个一个先后生成的，每一个区块记录下它在被创建期间发生的所有价值交换活动，所有区块汇总起来形成一个链式的记录合集。

区块结构(BlockStructure)：区块中会记录下区块生成时间段内的交易数据，区块主体实际上就是交易信息的合集。每一种区块链的结构设计可能不完全相同，但大结构上分为块头(header)和块身(body)两部分。块头用于链接到前面的块并且为区块链数据库提供完整性的保证，块身则包含了经过验证的、块创建过程中发生的价值交换的所有记录。

节点(peer)：区块链网络中，构建了一个分布式结构的网络系统，让数据库中的所有数据都实时更新并存放于所有参与记录的网络节点中。同时，区块链网络构建一整套协议机制，让全网每一个节点在参与记录的同时也来验证其他节点记录结果的正确性。只有通过协议机制使得符合条件的节点(例如全部节点、大部分节点或者特定的节点)都同时认为这个记录正确时，或者所有参与记录的节点都比对结果一致通过后，记录的真实性才能得到全网认可，记录数据才允许被写入区块中。因此，在区块链网络中，所有节点共同构成了一个去中心化的分布式数据库。

在不同的区块链系统中，节点除了用于存储区块数据外，还存在部分特殊节点。例如背书节点，排序节点。其中，背书节点是执行智能合约状态机，模拟执行交易。背书节点包含预先指定的背书策略集，这些背书的策略集安装了特定的链代码，所有的交易都必须依据背书策略进行交易，因为只有经过背书处理的交易才是合法、被认可的交易。在具体的实现中，背书节点接收到客户端的交易请求后，对执行模拟交易，并根据模拟交易的结果生成背书签名，从而完成对交易的背书。

关系数据库(Relational Database，RDB)：RDB数据库就是基于关系模型的数据库，也叫关系型数据库。在计算机中，关系数据库是数据和数据库对象的集合。所谓数据库对象是指表、视图、存储过程、触发器等。而管理关系数据库的计算机软件就是关系数据库管理系统(Relational Database Management System，RDBMS)。关系数据库是由数据表和数据表之间的关系组成的。在关系型数据库中，表的关联是一个非常重要的组成部分。表的关联是指数据库中的数据表与数据表之间使用相应的字段实现数据表的连接。

大部分业务系统的业务关系均可以用关系数据库的模型来定义。标准数据查询语言(Structured Query Language，SQL)是一种基于关系数据库的语言，可以通过此类语言对数据库中的数据进行检索和操作。当前不少的业务系统中存在一些对区块链账 本的需求，如供应链物品跟踪账本、电商平台中的多方订单账本等，都需要区块链技术的防篡改和抗抵赖特性来支撑其运行，能被定义为这类账本数据的，可以称为链上数据。同时，链上数据也会与原有业务中的其他数据(也称为链下数据)存在一些强相关性，通常需要维护它们之间的一致性、原子性等。但是，将业务系统单纯地拆分一些数据至区块链上，以此获得了区块链账本带来的优势，会使得链上数据和链下数据的共同管理更加困难。

关系型数据库系统更多注重一致性、高可用性、高性能，而区块链系统更多注重不可篡改性、去中心化、安全性。基于两者的特性，业界出现了一些融合数据库技术与区块链技术的系统原型，如BigChainDB、ChainSQL、Catena等，这些原型都具备了体现区块链特性方面的去中心化、防篡改性、拜占庭容错等，但在数据管理方面的能力存在不小差异：1)BigChainDB不支持SQL访问，仅支持K-V类型数据结构，更不支持事务；(2)ChainSQL将区块链非结构化的数据同步至结构化的外置数据库中，支持有限的SQL访问，由于状态存储于新增的外置数据库系统中，不支持事务，也增加了一致性维护问题；(3)Catena可以被认为是传统公链系统上增加了一层轻量的SQL支持模块，SQL支持能力非常有限，不支持事务，由于共识为非确定性算法，离ACID事务保证非常遥远。

在本发明中，将传统关系型数据库的数据管理能力与区块链技术的可信实现防篡改能力相结合，并通过通用的SQL作为接口输出。实现了一套系统解决用户对数据管理与防篡改的诉求，从而使部署、管理、运维成本降低，学习曲线变短。一套系统内可支持多链和链下数据存储，无需第三方工具同步，直接提供链上链下事务和跨链事务操作，协同分析效率高。

为了便于对本发明的理解，对下面对本发明实施例中的一些关键概念进行解释。

背书共识机制：

当前一些主流的强一致性分布式数据库系统主要是基于类paxos的非拜占庭容错一致性协议来构建节点间的状态复制机制的。此类型机制的复制内容可以为：a)单个节点的执行结果状态集；b)请求执行逻辑；

a类型先由其中一个节点模拟执行用户请求逻辑，拿到模拟执行结果，然后将模拟执行结果进行一致性复制，待一致性达成后，每个参与节点直接使用此模拟执行结果更新自身状态，此类型方式相对易于维护集群状态一致，例如有MySQL的row-based binlog、zookeeper的CRUD操作日志等，然后此类型方式更类似使用单一节点的状态去更新整个集群的状态，如果模拟执行节点被篡改时，整体集群状态就会错乱；

b类型将原始的用户执行逻辑复制于整个集群节点上，然后再在各个节点上单独执行并更新各自状态，此类型有利于每个节点独立维护自身状态，对于存在篡改情况更有利，例如有MySQL的statement-based binlog等，然而此类型侧重在复制处理过程，在一些实现中，处理过程会存在随机性，如random()逻辑等，所以在不同节点上的执行可能带来不一致的问题；

由以上可见单纯的使用a和b都没法同时达到防篡改和一致性的目的，本发明实施例的数据库系统提出了一种防篡改的复制机制：(1)请求接受节点在接受到客户端发送的请求后，直接在本地状态机上模拟执行生成一个模拟执行结果，并将此模拟执 行结果与用户执行逻辑打包，复制给其他节点进行防篡改检验；(2)网络中的其他节点收到消息包后，从中取出用户执行逻辑在本地进行执行生成模拟执行结果，然后再对比消息包中的模拟执行结果；(3)如果两份结果不一致，代表存在数据篡改情况，回复验证失败给发起节点；如果两份结果一致，回复验证成功给发起节点；(4)验证发起节点收到足够多的验证回复后，汇总判断，判断验证失败的请求直接被丢弃，判断验证成功的请求以模拟执行结果集进行pbft共识复制逻辑，直至状态复制结束或失败。

本发明实施例的数据库系统相比传统的状态复制机，在共识之前增加了防篡改验证逻辑，且使用通过验证的模拟执行结果进行复制，既达到了防篡改设计，又能维护好状态的一致性。

事务区块链：

区块链系统通过链式结构可以保证历史交易的不可篡改性。当前关系型数据库仅在文件中保存历史操作日志，用于数据恢复等工作，但是日志文件并不能保证可篡改。为此，本发明实施例的数据库系统使用事务的日志内容构建区块，并组装成链。其区块中除包含该事务的所有被提交的交易，还包含区块号、父区块哈希值、交易号、时间戳、各种签名信息等附加内容。同区块链系统，本发明实施例的数据库系统链式表通过父区块哈希保证不篡改性，同时，也可以通过交易签名追溯请求发起者信息，通过背书签名追溯请求背书认可节点信息。

智能合约：

智能合约作为区块链由单一数字货币功能扩展至各个领域的最关键特性，保证各个节点可以执行相同的业务逻辑。在关系型数据库中，存储过程已经包含类似的功能，但是传统的关系型数据库以相对可信的环境被运行背景，所以在存储过程的流程设计上还是以单点执行，多点复制状态为主，所以不具备防篡改性。本发明实施例的数据库系统结合存储过程的设计特点，将其扩展为具备防篡改性的智能合约特性，消息复制时，会将调用命令及执行结果打包复制至所有节点先进行防篡改校验，只有通过校验的调用才会继续后续步骤处理。同时，本发明实施例的数据库系统支持多链，一个智能合约对应于一个链，只被安装于对应链的节点上，当链被删除时，其上智能合约也一起被清理。系统中所有对链上数据更新操作只能通过智能合约调用来完成。

权限管理：

权限管理主要是针对于本文系统支持的多区块链而建立的。本文的本发明实施例的数据库系统中链式结构分为System Chain和Data Chain两类，其中System Chain为系统链，用于整个集群数据链元信息的存储与管理；Data Chain为数据链，用于用户数据读写，为用户发起创建。为了方便描述，这里将一个Data Chain的参与节点描述为此链的Member Node，否则称其为此链的非Member Node。

(1)Data Chain访问权限控制，考虑到更好的数据隔离和隐私保护，这里对Data Chain的访问控制权只留给了链中的参与节点，如果有节点想要访问其他节点维护链的数据，必须通过对Member Node的访问才可以。

(2)System Chain访问权限控制，System Chain作为整个系统的元信息存储链，对外部用户不可见，只允许集群成员节点以系统请求进行访问。首先，整个集群中所 有的成员节点，经过投票达成共识，完成此链的构建，并将所有成员的配置信息存储于此链，此类信息在System Chain构建时一次写入，后期只允许读取，不允许再次修改和追加；其次，在某个Data Chain创建完成时，由其Member Node向System Chain写入此Data Chain元信处，System Chain会验证写入者是否为Data Chain的Memebr Node之一。

链上事务与链下事务：

现存的区块链系统中，数据都存储在账本上可以被所有节点访问，数据隐私性无法得到保证。对于要求数据隐私性的业务场景(如金融系统)，只能将部分隐私数据进行链外存储，剩余可公开数据上链，需要有额外系统去维护这两部分数据的关联一致性。本发明实施例的数据库系统中，为了能更有效地做好数据隔离，按DB粒度定义一个链，将每一个区块链作为一个分区channel来维护，同时整个集群联盟可以维护多个channel，且每个节点实例可同时支持两种数据存储类型：

a)On-Chain：链上DB，即链上区块链，存储节点共享的链上数据，所有节点参与维护，每个链统称为一个channel；每创建一个DB时，系统根据DB名称创建一个channel；每个channel由所有联盟成员节点共识维护；

b)Off-Chain：链下DB，即链下本地库，存储本节点私有的链下数据，仅由创建节点维护；

整个集群联盟支持多区块链共存、链下链下共存，全员节点维护一个内置系统链，用于管理所有用户数据链信息。

基于上述多链设计，本发明实施例提供了一个多类型数据管理的一体化方案，并且针对于它们之间的事务性支持提供了特性：

1)链上跨链事务：保证一个事务中对多条链上数据的批量操作的原子性保证，即要么所有链上更新都成功，要么所有链上更新都失败；

2)链上链下事务：保证一个事务中对链上与链下数据的批量操作的原子性保证，即要么所有链上更新及包括的链下更新都成功，要么全失败；

下面具体介绍链上跨链事务

当本发明实施例的数据库系统中某一个节点收到用户请求同时包含多条链上数据更新操作时，此节点生成一个跨链事务进行处理。

当生成跨链事务后，服务端节点在事务的Prepare阶段，生成事务日志，并按链粒度将其拆分为单链部分，然后通过系统链查到每个链的成员节点，使用单链部分分别进行背书共识，其中每个链共识的commit信息需要广播给所有参与节点。所有的参与节点拿到所有链共识的结果，并进行统计，只有所有链共识都完成时，才可提交本节点所维护链的事务部分，最终达到了对于整个集群而言，保证所有链更新要么全成功，要么全失败。

下面具体介绍链上链下的跨链事务

当本发明实施例的数据库系统中某一个节点收到用户请求同时包含链上链下更新操作时，此节点会生成一个链上链下事务进行处理。

当生成此链上链下事务后，服务端节点按照以上提到的事务处理流程来进行处理，同时在事务的Prepare阶段，生成的事务日志分为两部分：(1)链上部分；(2)链下 部分；其中对于链上数据的更新操作日志只存在于链上部分中。

在进行背书共识流程时，节点只使用事务日志中的(1)链上部分，待背书共识流程通过后，一次性对(1)和(2)进行提交，若失败则都回滚，最终达到链上链下的原子性操作。

实施例一

下面结合图1，介绍本发明一种实施例的数据库系统的系统架构图。如图所示，本发明实施例的数据库系统可以分为客户端110侧和服务器120侧。客户端110包含了客户端110a、110b、110c……110n的多个客户端，服务器120包含了服务器节点120a、120b、120c……120n的多个服务器。服务器节点可以是一个独立的物理服务器，也可以是一个虚拟机节点。

客户端110中每个客户端(110a、110b、110c……110n)上有应用程序111，SDK/API模块112和签名模块113。SDK/API模块112负责支持数据库连接API，从而使得数据库系统支持其他业务系统。签名模块113通过Triangle CA颁发证书，来完成登录与请求加签验证；在客户端110与服务器120握手阶段，安全模块113对登录请求信息进行签名，并将签名信息及配套证书附加在请求信息中。服务器120在收到客户端110登录请求消息后，只有完成验证才会继续进行握手流，否则登录失败。

服务器120中每个节点(120a、120b、120c……120n)中包含如下模块：

CA模块121:主要用于系统的权限管理,参考CA验证方案。首先生成一份根证书及对应私钥，然后使用根证书私钥签发普通证书及对应私钥。根证书私钥保存及证书签发工作需整个联盟成员协商完成。每个服务端都包含根证书，充当CA的中心验证机构。网络中所有消息必须附加签名信息及配套证书。

安全模块122：用于对背书请求中的签名进行验证，并在背书成功后添加背书结果签名。交易背书阶段，其他服务节点收到复制的消息后，同样先进行验证操作，通过后再执行背书流程。背书完成后，返回背书结果时，同样需要使用服务端私钥对背书结果进行签名，然后将签名及配套证书附加在背书结果中。共识阶段，收集各节点背书结果时，同样需要进行验证工作。只有验证通过的结果才会被视为有效背书信息。

SQL解析模块123：用于解析来自客户端的SQL请求，将请求中的SQL语句按照SQL语法规则进行解析，将文本转换成抽象语法树。

智能合约模块124：用于管理用户安装的智能合约。

背书共识模块125：负责节点对事务请求的背书、一致性复制，具备拜占庭容错能力。本发明实施例的数据库系统相比传统的状态复制机，在共识模块中增加了防篡改验证逻辑：1)请求接受节点在接受到客户端发送的请求后，直接在本地状态机上模拟执行生成一个模拟执行结果，并将此模拟执行结果与用户执行逻辑打包，复制给其他节点进行防篡改检验；(2)网络中的其他节点收到消息包后，从中取出用户执行逻辑在本地进行执行生成模拟执行结果，然后再对比消息包中的模拟执行结果；(3)如果两份结果不一致，代表存在数据篡改情况，回复验证失败给发起节点；如果两份结果一致，回复验证成功给发起节点；(4)验证发起节点收到足够多的验证回复后，汇总判断，判断验证失败的请求直接被丢弃，判断验证成功的请求以模拟执行结果集进 行PBFT共识复制逻辑，直至状态复制结束或失败；

存储引擎模块126，主要的功能是用来做数据存储。数据主要分为3类：系统链数据，用户链数据和用户私有数据。具体的数据存储形式如下：

系统链数据：系统建立时配置系统链DB，存储系统中所有链的meta信息。DB中包含两类表：1.系统成员表：表中包含本系统中所有的节点信息，节点ID，IP地址和状态信息，(节点可能不属于同一条链)；2.链成员表：每一条链分别对应创建一张配置表，表名与链名保持一致，如：chain1。此类表中包含该链上所有节点ID,IP地址，证书、背书节点标志位和状态信息(online、offline、error)。用户加入系统或者加入链的过程中，发起交易更新系统成员表或链成员表。用户创建链的过程中，由系统根据用户创建的链对应创建此链的配置表，并插入此链的成员节点信息。系统数据链在所有节点都有备份，可以被所有节点访问且共同维护，配置信息可用于配置背书策略和跨链交易；

用户链数据：包含3部分内容，1)用户链上数据：这部分数据是系统中真正的用户业务数据。如果节点加入了多条链，则每一条链上的用户数据分别对应一个DB，链与链之间的数据以DB进行隔离。属于同一条链上的节点共同维护此链上的用户数据，不在该链的节点没有此部分数据的备份。对用户链上数据的修改会计入对应的区块表和历史表中；2)用于追溯事务更新的历史快照链数据和3)该链的区块链数据。用户链数据存储在系统的blockchain DB中，每条链包含一张区块表(以${chain_name}_blockchain命名)和多张历史表(每张历史表对应用户链上数据DB中的一张表，以${chain_name}_${table_name}_chain命名)如果一个节点加入了多条链，则在本地维护多份用户链数据。此部分数据仅在该链所包含的节点上有备份，其他未加入此链的节点无法访问或操作此部分数据；

用户链下数据：此部分数据属于节点的私有数据，仅在本节点上独立存在。节点发起的事务中如果涉及操作用户链下数据，系统会过滤此部分内容，仅对事务中链上数据的部分进行同步和复制。同时，修改此部分数据，不会产生历史记录和新区块，仅在节点本地生效。

参考图2，是多链共存在一个服务器集群中的一个示例。节点1、节点2和节点3共同维护一个系统链。节点1与节点2共同维护数据链1上的数据，而节点2和节点3共同维护数据链2上的数据。同时，节点1与节点3各自维护其各自的链下数据。

整个集群联盟支持多区块链共存、链下链下共存，全员节点维护一个内置系统链，用于管理所有用户数据链信息。

事务区块引擎127：负责事务请求对应的区块生成，维护整条区块链数据的更新，保证请求在节点间的分布式事务特性。

本实施例中的通过链式结构来进行数据存储，具体如下：

事务链：

在本发明实施例的数据库系统中，每个channel拥有一条事务链，用于保存事务日志，使系统具备防篡改能力。在创建channel时，自动创建一条对应的事务链，该链仍然以关系型结构保存在一张表中。区块表结构信息为：区块号、父区块哈希、交易发起时间戳、客户端签名、所有背书节点签名、该事务内容、执行结果。

完成共识后，将共识完成的事务日志打包成区块，每个事务作为一个区块。首先解析事务日志，读取客户端交易发起时间、交易请求、经过背书的执行结果、客户端签名、各个背书节点签名等信息。然后读取链式结构上一个区块的内容，首先取上一个块的区块号加一作为该块的区块号，然后对整个块求哈希作为父区块哈希值。上述所有内容根据事务区块表结构构成当前事务的区块。由每个区块包含父区块的哈希来构成链式结构。

生成区块后，直接插入事务链表。因为事务日志是该链所有节点共识的结果，即事务日志保证相同，因此可以保证每个节点的区块内容一致。如果数据被篡改，则父区块哈希无法校验通过。

历史快照链：

当前关系型数据库并不支持直接查询历史信息的功能，无法通过SQL语法快捷的进行分析统计工作。本发明实施例的数据库系统中，每个数据表单独设计一条历史快照链，用于保存该表的所有历史状态。历史快照链也是按照关系型结构保存在表中，用户在创建数据表时，自动创建一张对应的历史快照链表。该表结构信息：对应数据表所有列、区块号、交易号、上条记录哈希值。该表会在用户创建数据表时对应创建。同样历史快照链使用关系型表存储，每条交易为一条记录。

一个事务的每笔交易均会在对应历史快照链中产生一笔记录，做为历史块照链的一个块，该区块和事务链区块同时产生。在上述事务链解析事务日志时，再解析执行结果，按交易及拆分梳理。对每条交易，读取操作的数据表、修改内容、交易类型等信息，每个表涉及的交易单独编号作为交易号。每条交易均取父快求哈希值，同时取该事务的区块号。将上述所有信息按照历史快照链组成块，同样由父区块哈希值构成链式结构。

需要查询某个数据的历史状态信息做分析统计工作时，只需在对应历史表中使用SQL语法进行查询即可。事务链，历史快照链可以防止历史数据被篡改。

在本发明的一种实施例中，如图3所示，本发明实施例的处理流程的基本粒度为事务，一个事务包含了若干个智能合约和若干个普通sql的调用，事务的主要处理流程如下图所示上述服务器120中各模块的交互流程如下：

S301、客户端发起交易由SQL解析123模块对请求进行解析，判断是否为调用智能合约的交易，如果是，则从智能合约模块中调用用户安装的智能合约进行执行；

S302、交易首先在发起节点本地执行，产生读写集，并由本节点的安全模块122对交易进行签名，然后将交易请求命令、本地读写集和节点签名进行打包；

S303、交易准备好之后进入背书共识模块125，首先进行背书流程(endorse)，验证交易执行前的世界状态、交易请求命令的执行逻辑没有被篡改，且执行相同命令之后的世界状态保持一致，视为背书成功，然后进入PBFT共识复制流程；

S304、交易经节点共识复制后，由节点的事务区块引擎127打包生成区块同时根据交易内容产生历史快照链的历史记录；

S305、存储引擎模块126将交易事务写入磁盘即更新世界状态，并且将区块和历史链记录持久化入磁盘。

实施例二

参考图4是本发明的一个实施例的流程示意图，该实施例可以应用在图1所示的数据库系统中，也可以基于其他符合本发明设计思想的系统架构中。该流程方法描述了在本实施例的数据库系统中，客户端的交易请求如何在服务器中生成交易数据并保存在数据节点的数据库中。在本实施例中，结合不同的具体实施方式，不同的节点角色可能为同一节点所实现，也可能为不同节点所实现。例如，在一些实现方式中，执行背书流程的节点和存储数据的节点为同一节点，即同一节点既可以实现背书节点的功能，又可以实现数据节点的功能；又例如，在一些实现方式中，部分数据节点并不作为背书节点，即这类节点仅具有数据节点的功能而不具备背书节点的功能。

本实施例的方法包括：

S401，客户端向节点发起交易指令。

在一种实现方式中，客户端部署在与节点分离的其他终端上，用户通过客户端进行交易操作后，终端向节点发送交易指令，节点通过网络交易指令。在另一种实现方式中，客户端部署在节点上，则用户通过客户端进行交易操作后，节点可以直接获得该交易操作生成的交易指令。

客户端所生成的交易指令，请求内容包括以DML，DDL等SQL语句形式存在的交易执行逻辑，请求内容例如创建一条学生基本信息的记录：

INSERT INTO student(‘name’,‘age’,‘id’)VALUES('Alice',‘20’,‘001’)；

在上述SQL命令中，客户端的交易指令指示对存储有交易信息的表格进行写入，对其表项写入对应的值。

在一些实现方式中，交易指令中还包括证明客户端合法身份的签名信息。节点可以通过前述安全模块对该签名信息进行验证，从而确定交易指令所对应的客户端身份。

S402，交易发起节点接收客户端发送的交易指令，解析并本地执行交易指令中的SQL语句。

在节点120中，接收到客户端发送的交易指令的节点作为交易发起节点。例如，在一个实施例中，节点120a接收到客户端发送的交易指令，并作为交易发起节点在节点120中发起该次交易。

交易发起节点120a通过SQL解析模块，解析来自客户端的交易指令，将交易指令中的SQL语句按照SQL语法规则进行解析，将文本转换成抽象语法树。基于解析后的SQL语句，交易发起节点120a将该SQL语句在本地执行，从而产生基于本地世界状态的读写集S(r,w)，读集和写集分别对应本次交易执行前后的世界状态。

在一些实现方式中，由于交易指令中还还包括证明客户端合法身份的签名信息，交易发起节点在接收到交易指令中，首先会对该签名信息进行验证，在基于验证结果确定用户身份的合法性之后，才在本地执行交易指令中的SQL语句。

在一些实现方式中，交易发起节点在本地执行成功后，会对该交易进行签名，从而产生一个交易发起节点的签名信息。

S403，交易发起节点将客户端所发送的交易指令中的SQL语句以及本地执行所产生的读写集S(r,w)发送给背书节点进行背书。

基于数据库的背书策略，交易发起节点需要对该次交易进行背书。

与区块链系统所不同的是，本实施例中交易发起节点在发起背书操作时，除了将 包含有交易执行逻辑的SQL指令发送给背书节点，还将指示了交易发起节点将SQL指令本地执行前后的世界状态的读写集S(r,w)也发送给了背书节点。可以理解的，在不同的实施方式中，前述的SQL指令和读写集S(r,w)可以通过同一个消息或者同一次通信流程发送给背书节点，也可以通过不同的消息或者通信流程发送给背书节点。

在一些实现方式中，交易发起节点在本地执行成功后，会对该交易进行签名，从而产生用于验证节点合法身份的签名信息。在进行背书是，交易发起节点还会将该签名信息发送给背书节点。

S404，背书节点接收交易发起节点发送的背书请求，并在本地执行背书请求中的SQL指令。

背书节点在本地执行SQL语句，将SQL语句按照SQL语法规则进行解析，将文本转换成抽象语法树。基于解析后的SQL语句，节点120a将该SQL语句在本地执行，从而产生基于本地世界状态的读写集S’(r,w)，读集和写集分别对应本次交易执行前后的世界状态。

在一些实现方式中，由于交易指令中还还包括证明客户端合法身份的签名信息，背书节点在接收到交易指令中，首先会对该签名信息进行验证，在基于验证结果确定用户身份的合法性之后，才在本地执行交易指令中的SQL语句。在一些实现方式中，由于交易发起节点会将带有交易发起节点身份的签名信息发送给背书节点，背书节点首先会对该签名信息进行验证，在基于验证结果确定交易发起节点的合法性之后，才在本地执行交易指令中的SQL语句。

S405，背书节点将本地执行交易的读写集S’(r,w)与交易发起节点所发送的读写集S(r,w)进行对比和校验。

在一种实现方式中，在将本地执行交易的读写集S’(r,w)与交易发起节点所发送的读写集S(r,w)进行对比和校验时，一些实现方式是，将两个读写集分别哈希后对比哈希值是否相同；另一些实现方式包括但不限于直接比较两个读写集的二进制代码等方式。

在进行比对之后，如果结果相同，则背书节点向交易发起节点发送背书成功的指示消息，在一些实现方式中，背书节点会对此交易进行签名，并将签名信息也发送给交易发起节点。如果结果不同，则向交易发起节点发送背书失败的指示消息。

S406，交易发起节点汇总收集到的背书结果，判断是否满足背书策略。背书策略可以基于系统配置确定，即事务执行需要被哪些节点确认，背书策略可以指定为所有节点背书(交易需要得到所有节点的确认)、多数节点背书(如:交易需要得到超过2/3节点的确认)和指定节点背书(如：交易需要得到节点A、B、C的确认)，被背书策略指定的节点为背书节点。背书策略以链为单位，如果节点属于多条链，则需要为每一条链指定背书策略。

在一些实现方式中，交易发起节点会验证背书节点所发送的签名，以确定背书结果所对应的背书节点的合法身份。

S407，如果满足背书策略，则进入系统的共识模块进行共识；否则，表明数据可能出现不一致的情况，丢弃此交易，并向客户端进行反馈：交易失败，数据可能被篡改，需要人工干预。上述流程中，如果此次背书未通过，之后涉及被篡改的数据的交 易将无法通过背书，但此时涉及其他交易的仍然可以正常执行，并不影响系统的可用性。

S408，交易发起节点将经过背书的交易发送至本节点的共识模块并与其他节点进行共识，共识算法可以采用多种现有的共识算法，例如PBFT算法。共识模块负责对分布式事务进行认证和排序。如果达成一致则继续执行，否则丢弃此交易。

在一种实施方式中，基于PBFT对事务进行共识。共识主要用于事务的排序，如果交易冲突，则对应事务共识失败，交易失效。本发明实施例的数据库系统中，PBFT中要求网络共三个阶段。

(1)pre-prepare：达成背书后，由排序节点发起共识。排序节点可以是交易发起节点，也可以是服务器集群中的其他节点。发起该事务请求，发送给channel中的其他节点。其他节点收到请求后，判断该请求中所包含的读集等信息是否有冲突，若无冲突则同意该请求，并发送给channel中的其他节点。

(2)prepare：当收到超过2f+1个节点同意请求，则该节点同意事务提交。并将结果发送给所有其他节点。

(3)commit：若收到超过2f+1个节点同意事务提交，则最终达成共识，提交事务。

S409，共识完成后，如果达成一致，则各个节点进入提交阶段，从而更新用户数据

此过程包含3部分内容：

1.节点根据交易请求和执行交易产生的读写集生成区块：新生成的区块中包含当前区块的区块号，交易执行逻辑和执行结果；生成区块的过程还包括从区块表中获取上一区块的记录并进行哈希运算，将计算出的哈希值放入新生成区块的previousHash字段，然后将区块写入区块表，形成区块的链式结构。

2.节点根据交易请求和交易所影响的用户数据生成历史记录：历史记录包含更新后用户数据内容、区块编号、交易发起者签名、交易背书者签名以及上一条历史记录的哈希值，相邻历史记录通过此哈希值形成快照链；

3、提交事务，更新用户数据。

实施例三

本实施例包含了链上事务与链下事务之间的流程性描述。为了便于描述，本实施例的方法流程中引用了前述实施例中相对应的步骤，因而可以基于前述实施例中的流程进行实施。但是，本实施例所描述的发明内容也可以在其他满足条件的数据库系统中实施，因而，本实施例中的实施方式并不必然受到前述实施例的限制。

如果交易中涉及链上链下事务或跨链事务，则背书流程中在转发事务之前会将事务进行拆分：对于链上链下事务，则只将操作链上数据的SQL语句和产生的读写集进行转发；对于跨链事务，系统会按照事务所在链的粒度进行交易拆分，将对应链的SQL语句和读写集分别转发，接收到背书结果之后将会按照配置中不同链的背书策略进行校验。只有当跨链事务所涉及的所有链的背书策略同时得到满足时，才会认为此跨链交易背书成功。

每个节点维持链下数据存储域：OffChain，用于存储链下数据，此类数据仅存在于本节点，属于本节点的私有数据，无需经过共识，更不会复制给其他的节点，但是本节点数据维持链上数据与链下数据的事务性。

本实施例对于链上链下操作本实施例提供事务保证，结合图5，具体流程如下：

S501、客户端发起链上链下事务操作，事务中同时包含了链上数据更新操作集onchain op set和链下数据更新操作集offchain op set；

S502、服务端事务请求接收节点在接收到请求后，开启一个事务管理器，按照事务请求中的操作顺序进行处理，对于offchain op set和onchain op set，都会进行事务预提交，产生两份事务处理逻辑日志缓存offchain r-w set和onchain r-w set，此时访问到此节点的其他请求，并不能见到此事务的更新，因为还未真正提交，同时向链上事务缓存池中增加onchain op set产生的事务日志，事务日志包括事务执行逻辑onchain op set、onchain r-w set；

S503、以onchain op set产生的事务日志发起背书流程(参照上文中本实施例一的具体步骤)，如果背书流程失败，请求接受节点将链上链下事务回滚，同时将offchain op set和onchain op set产生的预提交都进行回滚，此事务失败退出，并将错误码返回给客户端，如果背书流程成功，走入下一步；

S504、请求接收节点以onchain op set产生的事务日志发起共识流程，如果共识流程失败，请求接收节点将链上链下事务回滚，同时将offchain op set和onchain op set产生的预提交都回滚，此事务失败退出，并将错误码返回给客户端，如果共识流程成功，走入下一步；

S505、请求接收节点将包括了offchain op set和onchain op set产生的预提交进行真正提交，其他节点只接收到了onchain op set，所以只对onchain op set进行提交，至此，请求接受节点完成了链上链下事务操作。

下面结合图6以一个具体的实例来说明：

在Tx prepare阶段，一个包含了链上数据操作和链下数据操作的事务提交到节点1(Node1),节点1模拟执行后，分别得到了链上数据的事务日志OnChain tx log和链下数据的事务日志OffChain tx log，事务日志中更包含了数据操作和数据模拟执行后的读写集。在背书和共识阶段(Endorse&Consensus)，将链上数据的日志OnChain tx log与节点2与节点3进行共识和背书，当共识以及背书成功之后，进入提交阶段，节点1提交包含了链上数据和链下数据的事务，而节点2与节点3提交链上数据的事务。如果当共识以及背书失败之后，则节点1将模拟执行的链上数据和链下数据操作事务进行回滚，而节点2与节点3则对模拟执行的链上数据进行回滚。

在一些实现方式中，考虑到更强的容灾能力，持有OffChain数据节点，可以自增额外节点，并将OffChain数据改为私有的OnChain数据。

实施例四

在另一个实施例中，描述里本发明如何处理链上事务之间的跨链特性，即对于同一个事务，当涉及到两条以上的数据链时的处理方式。为了便于描述，本实施例的方 法流程中引用了前述实施例中相对应的步骤，因而可以基于前述实施例中的流程进行实施。但是，本实施例所描述的发明内容也可以在其他满足条件的数据库系统中实施，因而，本实施例中的实施方式并不必然受到前述实施例的限制。

现有技术的联盟链中，一般通过链实现数据隔离，不同的链不具有互通性，不能互相访问数据。但现实的业务场景中部分交易涉及到不同链的原子性：一个事务包含涉及多条链的交易，这些交易必须同时成功同时失败，即跨链。

本实施例支持跨链特性，结合图7，具体跨链流程如下：

S701、配置一条系统链，该链可以被网络中所有节点访问，用于记录网络中所有链的成员信息。当网络中创建一条新的链时，在系统链中增加一条记录；新的节点加入链，则由链的创建者更新该条链的成员信息，并同步到整个系统。

S702、客户端发送交易指令时，需要标记该交易涉及跨链并指明跨链事务中的每条交易分别属于哪条链。服务端收到客户端的跨链交易请求时，首先对事务中的交易按顺序进行编号，并将该事务中的所有交易按照所属链进行拆分。

S703、服务端节点解析拆分结果中的交易执行逻辑，并在本地执行产生对应不同链的读写集；节点将拆分后的交易执行逻辑、读写集和本节点签名按照所属链进行打包发送给该交易所对应的链上的背书节点进行背书，背书流程可以遵循前述实施例中的背书流程。

S704、服务端交易发起节点汇总收集到的背书结果，对于跨链事务，当事务中所有被拆分的交易的背书结果都符合所在链的背书策略时，视为背书成功。背书成功后，将请求拆分结果、每笔交易编号和该跨链事务共涉及哪些链打包复制给对应链的节点，进入系统的共识模块进行共识。每笔交易编号和该跨链事务共涉及哪些链需要作为交易信息的一部分，后续所有消息的复制都必须附带这两个信息。

S705、提交阶段，当前链共识完成之后，进入等待状态，读取该跨链事务所涉及的链的所有节点，将该链的共识结果发送给这些节点。同理该链也会收到所有其他链的共识结果，当收到某条链超过50％节点共识通过的反馈后，即视为这条链共识通过。若该交易涉及所有链都共识通过，即表明跨链共识通过。如果某个节点包含多个链，则需要按照交易编号顺序依次提交每笔交易。跨链交易的提交遵循前述实施例中的提交流程，链上节点仅提交事务中与所在链相关的交易，如果节点加入了跨链事务中所涉及的多条链，则按照交易序号在不同链上分别提交与该链有关的交易。

下面结合图8，通过一个示例具体说明多链之间的背书共识过程：

在图8中，节点0(Node0)只维护链1(chain1)，节点1(Node1)至节点4(Node4)同时维护链1(chain1)、和链2(chain2)，节点5(Node5)只维护链2(chain2)。

背书共识过程如下：

1、Pre-prepare阶段：Node1收到跨链事务：chain1Tx和chain2Tx，对其进行拆分，在本节点上进行事务预操作，如果预操作通过，将chain1Tx投递入blockchain1，将chain2Tx投递入blockchain2；

2、Prepare阶段：blockchain1上所有节点对chain1Tx进行背书，并把结果以投票形式发给所有节点，并统计blockchain1上所有节点对此事务的投票结果，以>2f1 为投票统计法则，最终将本节点对chain1Tx的统计结果作为commit意见投票发送全员，其中对发给本链成员节点时带上事务信息，而发给链外节点时只带投票成功与否标志，blockchain2上所有节点对chain2tx处理类似；

3、Commit阶段：每个节点统计整个跨链事务中所有子事务的commit意见投票，只有所有子事务同时被统计为commit时才在本节点对此跨链事务进行真正的提交，node0提交chain1 tx部分，node1-node4同时提交chain1 tx和chain2tx，node5提交chain2tx部分；

为了便于理解，通过又一个实际例子来说明跨链流程：

该网络中共存在chain1、chain2两条链，其中chain1包含A、B、C三个节点及智能合约test1()，chain2包含C、D、E三个节点及智能合约test2()。该信息已经保存在系统链中，所有节点均可访问。

(1)客户端发起一笔内容为跨链事务的交易，事务中包含调用chain1上的智能合约call test1()和调用chain2上智能合约call test2()；

(2)服务端收到消息进行编号、拆分、转发；

将{id:1,cmd:‘call test1()’,chains:‘chain1,chain2’}发送给A、B、C三个节点

将{id:2,cmd:‘call test2()’,chains:‘chain1,chain2’}发送给C、D、E三个节点

(3)共识完成后，将共识结果发送给其他链

例如，chain1共识通过，A、B、C节点会将共识结果同时发送给C、D、E。

C、D、E同理。

(4)C、D、E如果收到超过2(>1/2)个chain1共识通过的消息，则视为chain1共识通过。若chain2也共识通过，则最终提交交易call test2()。

A、B、C节点同理。

若chain1和chain2均共识通过，C节点会按照交易顺序依次提交call test1()；call test2()。

结合图9，是上述执行流程的又一个示例：

在Tx prepare阶段，一个包含了两个链上数据操作的事务提交到节点(Node2),节点2模拟执行后，分别得到了链上数据1的事务日志Chain1 tx log和链上数据2的事务日志Chain2tx log，事务日志中更包含了数据操作和数据模拟执行后的读写集。在背书和共识阶段(Endorse&Consensus)，节点2将链上数据1的事务日志Chain1 tx log与节点1进行背书和共识，将链上数据2的事务日志Chain1 tx log与节点3进行背书和共识。在共识的投票阶段(Multi-consensus voting)，统计所有节点对此事务的共识结果，当共识以及背书成功之后，进入提交阶段(Tx Commit)，节点2提交包含了链1和链2数据操作的事务，而节点1提交链1的数据操作的事务，节点3提交链2的数据操作的事务。如果当共识以及背书失败之后，则节点2将模拟执行的包含了链1和链2数据操作的事务进行回滚，而节点1回滚链1的数据操作的事务，节点3回滚链2的数据操作的事务。

实施例五

本实施例介绍本发明的智能合约的设计。

本发明实施例中的数据库系统基于传统的存储过程(stored procedure)，设计实现了防篡改的智能合约(smart contract)。存储过程一组为了完成特定功能的SQL语句集，存储在数据库中，经过第一次编译后调用不需要再次编译，用户通过指定存储过程的名字并给出参数来执行。传统的分布式数据库系统中，存储过程安装后会被同步安装到系统中所有节点。但是调用存储过程的交易在进行复制时都不是在“call level”(stored procedure calls are replicated at the statement level rather than at the call level)，也就是说交易发起节点执行一个调用存储过程的交易的时候只会在本地执行一次存储过程，而其他节点在复制的时候是直接复制被这次调用所更新的数据，而不是再执行一次同样的存储过程。这样的设计会保证数据的强一致性，但是如果存储过程内容被篡改甚至交易是否是通过约定的存储过程来执行的，其他节点都无法察觉与分辨，这就给了作恶节点通过修改存储过程内容来篡改数据的可能性。本文中的可信数据管理系统优化存储过程的复制流程，将存储过程的复制设置为call level，结合背书流程实现了智能合约特性：节点在本地根据合约名和参数执行智能合约。具体流程如下：

(1)客户端调用执行合约的交易：

“call Smart_Contract(arg1,arg2)”

(2)服务端交易接收节点在本地传入参数arg1和arg2执行名为Smart_Contract的智能合约，产生读写集S(r,w)；然后将智能合约名字、参数和读写集打包转发给背书节点；

(3)背书节点接收到背书请求，根据请求中的智能合约名字和参数调用本地存储的智能合约。如果智能合约可以在本地成功执行并产生读写集S’(r,w)，则与背书请求中S(r，w)进行比对，返回背书结果。

其中，流程(3)中背书节点如果智能合约执行失败，原因可能是智能合约不存在或者参数不匹配，说明交易发起节点执行了一个被篡改的智能合约。如果读写集中的读集不一致说明在执行智能合约前的数据状态被篡改，如果读集一致而写集不一致，则说明智能合约的逻辑有可能被篡改。通过本文中的设计可以实现不可信环境下，节点通过一段约定好的程序段来更新数据，同时保证此过程中智能合约逻辑不被篡改。

实施例六

本实施例中介绍本发明实施例中权限管理的设计。

本文中的本发明实施例的数据库系统在交易请求的生命周期中加入签名信息(客户端签名、背书签名)和验证流程，服务端可以更有效地验证用户的合法性，将请求加签信息随事务信息存入区块中，具备更强的可追溯性和抗抵赖性。具体的加签和验签流程如下：

(1)客户端使用证书登录，服务端通过校验证书的合法性，来判断客户端是否具有登录权限；

(2)客户端使用所持有的证书，将所要发送的请求进行签名。服务端校验证书和签名的合法性，用来判断该用户是否有操作数据所需要的读写权限，非法时直接报 错，否则将其签名信息缓存以备后续记入区块使用；

(3)背书节点在模拟执行交易并校验读写集之后，使用自己所持有的证书进行背书签名，表明该交易通过了本节点的背书；

(4)交易发起节点校验背书签名，判断背书签名的合法性，并由此判断背书策略是否得到满足。

本系统中的交易经过完整的生命周期之后，区块中所记录的交易结构中将带有发起节点的签名：用来证明此节点具有发起交易操作数据所要求的权限。还带有背书节点对此交易背书的签名：用来证明此交易内容与执行前后的数据正太得到了背书节点的认证。由签名验签流程保证交易执行的有效性和系统的一致性与不可篡改性。一旦有任何关于交易的纠纷发生，可以通过签名信息认定责任，保证了系统的抗抵赖性。

本系统对于表的管理和权限控制通过权限表实现：创建数据表的同时新增一条关于此数据表的权限记录插入权限表数据，记录表创建者证书信息及拥有读写权限的证书信息。结合加验签流程，当交易读写数据时，服务端首先验证交易发起者的证书是否有相应权限，若没有，则交易失败。数据表创建者可以修改读写权限。

在数据表基础上，本系统增加区块表和历史表。这两类表的的权限以及插入和更新由系统根据用户数据事务的操作进行维护，对这两类表的操作由节点本地系统执行，无需经过链上节点共识同步，与用户数据事务强相关，即节点所有业务数据保持一致，则所有节点上的这两类表也必然保持一致。

在本发明实施例中，可以包括两类链：

1)system chain系统链：系统链属于系统内置，全员参与链，用来同步和管理用户的配置信息，如系统中共存在的所有用户链、每一条事务链上包含的所有节点以及每一条用户链的背书策略，此类信息可用于跨链事务。当有新节点要加入链时，由系统内某节点在系统链上发起加入链的交易，经过系统链上所有节点共识之后，可以更新系统链上对应新节点要加入的用户链的节点信息。如果背书策略发生变化，使用同样的流程更新背书策略信息。

2)user chain用户链：功能和传统区块链系统中的链保持一致，通过使用链式结构记录用户对数据系统的操作，所有节点维护一份相同的账本，保证整个系统的一致性和不可篡改性。同时使用的结构化存储，给数据追溯、分析与统计带来了极大的便利。

实施例七

上述详细阐述了本发明实施例的方法，下面提供了本发明实施例的装置。

前述实施例一中所示例的是一种数据库系统的服务器节点在实现本发明技术效果时的功能模块设计示例，具体的，可以基于不同的数据库系统实现。即本实施例中的各个功能模块，可以在不同的系统架构中通过软件模块或者硬件模块，或者软硬结合的方式实现。

随着技术的发展，设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，一个方法流程也可以用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件 编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

上述实施例阐明模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。在现有的区块链系统中，对节点的计算能力和网络通信能力有一定的要求，因此一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、节点、膝上型计算机等。但是，随着技术的发展，硬件设备的计算能力和通信能力会不断增强。因此，可以预见的，在将来的技术实现中，各类具备计算能力和通信能力的硬件设备均可以作为区块链系统中的节点设备。例如蜂窝电话、智能电话、个人数字助理、媒体播放器、车载电脑、物联网设备、导航设备、游戏设备、平板计算机、可穿戴设备或者这些设备中的任何设备的组合均可以作为区块链系统中的一个节点设备。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方 框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，如图7所示，是本发明实施例提供的一种节点设备70，该设备70包括处理器701、存储器702和收发器703，所述处理器701、存储器702和收发器703通过总线相互连接。

存储器702包括但不限于是随机存储记忆体(英文：Random Access Memory，简称：RAM)、只读存储器(英文：Read-Only Memory，简称：ROM)、可擦除可编程只读存储器(英文：Erasable Programmable Read Only Memory，简称：EPROM)、或便携式只读存储器(英文：Compact Disc Read-Only Memory，简称：CD-ROM)，该存储器702用于相关指令及数据。收发器703用于与其他节点设备或者与客户端接收和发送数据。

处理器701可以是一个或多个中央处理器(英文：Central Processing Unit，简称：CPU)，在处理器701是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

该设备70中的处理器701用于读取所述存储器702中存储的程序代码，以执行前述方法实施例中的方法步骤，或者实现前述节点实施例的各个功能模块。因此，本实施例的节点设备各个操作的实现可以前述的方法实施例中的相应描述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

Claims (19)

1. 一种数据存储方法，其特征在于，所述方法应用于数据库节点集群中的交易发起节点，所述方法包括：

   获取客户端的交易指令，所述交易指令包括结构化语言SQL命令；

   模拟执行所述SQL命令，确定模拟执行所述SQL命令前的第一世界状态和模拟执行所述SQL命令后的第二世界状态；

   将所述SQL命令，所述第一世界状态和所述第二世界状态发送给背书节点；

   获取所述背书节点的背书成功指令，所述背书成功指令指示所述背书节点模拟执行所述SQL命令前的世界状态与所述第一世界状态一致，且所述背书节点模拟执行所述SQL命令后的世界状态与所述第二世界状态一致；

   根据所述背书成功指令，与所述数据库节点集群中的至少一个其他节点进行共识，以指示所述其他节点在共识成功后执行所述SQL命令。
2. 根据权利要求1所述方法，其特征在于，所述方法还包括：

   所述共识成功后，执行所述SQL命令。
3. 根据权利要求1或2所述方法，其特征在于，模拟执行所述SQL命令，确定模拟执行所述SQL命令前的第一世界状态和模拟执行所述SQL命令后的第二世界状态具体包括：

   根据所述SQL命令，确定在本地执行所述SQL命令的第一读写集，其中，所述第一读写集的读集对应所述第一世界状态，所述第一读写集的写集对应所述第二世界状态。
4. 根据权利要求3所述方法，其特征在于，所述将所述SQL命令，所述第一世界状态和所述第二世界状态发送给背书节点具体包括：

   将所述SQL命令，所述第一读写集发送给所述背书节点。
5. 根据权利要求2所述方法，其特征在于，所述执行所述SQL命令具体包括：

   根据所述SQL命令，生成第一区块，所述第一区块包括执行所述SQL命令的执行逻辑和执行结果，以及所述第一区块的上一个区块的哈希值。
6. 根据权利要求5所述方法，其特征在于，所述执行执行所述SQL命令还包括：

   根据所述SQL命令，生成第二区块，所述第二区块包括执行所述SQL命令后的执行结果，以及所述第二区块的上一个区块的哈希值。
7. 根据权利要求1至6任一所述方法，其特征在于，所述交易指令中还包含所述客户端的签名；

   所述方法还包括：

   根据所述客户端的签名，验证所述客户端的身份是否满足预设条件。
8. 根据权利要求1至6任一所述方法，其特征在于，所述方法还包括：

   生成所述交易发起节点的签名；

   将所述SQL命令，所述第一世界状态和所述第二世界状态发送给背书节点时，所述方法还包括：

   将所述交易节点的签名发送给所述背书节点。
9. 根据权利要求1至6中任一所述方法，其特征在于，所述背书成功指令中还包括所述背书节点的签名；

   所述方法还包括：

   根据所述背书节点的签名，验证所述背书节点的身份是否满足预设条件。
10. 根据所述权利要求1至6中任一所述方法，其特征在于，所述方法还包括：

    生成所述交易发起节点的签名；

    根据所述背书成功指令，与所述数据库节点集群中的至少一个其他节点进行共识时，将所述交易发起节点的签名发送给所述其他节点。
11. 一种交易背书方法，其特征在于，所述方法应用于数据库节点集群中的背书节点，所述方法包括：

    获取交易发起节点发送的SQL命令，第一世界状态和第二世界状态，其中，所述第一世界状态为所述交易发起节点模拟执行所述SQL命令前的世界状态，所述第二世界状态为所述交易发起节点模拟执行所述SQL命令后的世界状态；

    模拟执行所述SQL命令，确定所述背书节点模拟执行所述SQL命令前的第三世界状态和模拟执行所述SQL命令后的第四世界状态；

    若所述第一世界状态与所述第三世界状态一致，且所述第二世界状态与所述第四世界状态一致，则向所述交易发起节点发送背书成功指令。
12. 根据权利要求11所述方法，其特征在于，所述获取交易发起节点发送的SQL命令，第一世界状态和第二世界状态具体包括：

    获取交易发起节点发送的SQL命令和第一读写集，其中，所述第一读写集的读集对应所述第一世界状态，所述第一读写集的写集对应所述第二世界状态。
13. 根据权利要求11或12所述方法，其特征在于，所述方法还包括：

    获取交易发起节点发送的SQL命令，第一世界状态和第二世界状态时，还获取所述交易发起节点的签名；以及

    根据所述交易发起节点的签名，验证所述交易发起节点的身份是否满足预设条件。
14. 根据权利要求11或12所述方法，其特征在于，所述方法还包括：

    生成所述背书节点的签名；

    向所述交易发起节点发送背书成功指令发送时，发送所述背书节点的签名。
15. 一种数据存储节点，其特征在于，所述节点包含至少一个功能模块，所述功能模块用于实现权利要求1-10中所述的方法。
16. 一种数据存储节点，其特征在于，所述节点包含至少一个功能模块，所述功能模块用于实现权利要求11-14中所述的方法。
17. 一种数据存储节点，其特征在于，所述区块链节点包括处理器和存储器，

    所述存储器存储有可执行程序指令；

    所述处理器读取所述存储器中的所述可执行程序指令以执行权利要求1-10中任意一个权利要求所述方法。
18. 一种数据存储节点，其特征在于，所述区块链节点包括处理器和存储器，

    所述存储器存储有可执行程序指令；

    所述处理器读取所述存储器中的所述可执行程序指令以执行权利要求11-14中任意一个权利要求所述方法。
19. 一种区块链系统，所述区块链系统包括所述权利要求15-18中任意一个权利要求所述的节点。

Images