CN111241589A

CN111241589A - Database system, node and method

Info

Publication number: CN111241589A
Application number: CN201911038474.4A
Authority: CN
Inventors: 张秦涛; 聂光耀; 刘奇; 丁健
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-11-29
Filing date: 2019-10-29
Publication date: 2020-06-05

Abstract

The invention provides a transaction method of a database system and a node design. After receiving a request sent by a client, the node directly performs simulation execution on a local state machine to generate a simulation execution result, packages the simulation execution result and user execution logic, and copies the simulation execution result to other nodes for tamper-proof inspection; after receiving the message packet, other nodes in the network take out the user execution logic from the message packet to execute locally to generate a simulation execution result, and then compare the simulation execution results in the message packet; if the two results are inconsistent, the data tampering condition is represented, and the verification failure is replied to the initiating node; if the two results are consistent, replying verification success to the initiating node; after the verification initiating node receives enough verification replies, the verification initiating node performs summary judgment, directly discards the request for judging the verification failure, and performs pbft consensus replication logic by simulating an execution result set for the request for judging the verification success until the state replication is finished or fails.

Description

Database system, node and method

Technical Field

The invention relates to a database technology, in particular to a database design based on a block chain technology.

Background

The block chain is a chain data structure formed by combining data blocks in a sequential connection mode, and is a distributed account book which is cryptographically guaranteed to be not falsifiable and counterfeitable. The block chain constructs a distributed structure system according to a decentralized protocol, information of the price value exchange is transmitted to the whole network through distributed transmission, information data content is determined through distributed accounting, block data are generated after a timestamp is covered, and the block data are transmitted to each node through distributed transmission to achieve distributed storage.

The intelligent contract is a new characteristic generated along with the development of block chain technology, is essentially a coded instance of the contracts of both parties of a trade, responds to received information according to the contract regulations of both parties, can receive and store value, and can also output information and value, and the intelligent contract plays a trusted system and always executes operation according to the rules agreed in advance.

The relational database is a database established on the basis of a relational model, and data in the database is processed by means of mathematical concepts and methods such as set algebra and the like. Currently, most business relationships of business systems can be defined by a model of a relational database. The standard data query language SQL is a language based on relational databases, and data in the databases can be retrieved and manipulated through such a language.

Based on the existing block chain scheme, the data management capability in the relational database cannot be realized, and the transaction operation of the data cannot be realized. Therefore, it is difficult to satisfy the demand for data management of a large-scale data system.

Disclosure of Invention

The embodiment of the invention provides a database system, which comprises a transaction method and nodes, and realizes that a user can change the use mode of a traditional block chain to the use mode of a database under the condition of keeping the use mode of an original relational database, and the use mode of the traditional block chain and the use mode of the database are integrated into a system, so that the system uniformly and cooperatively manages two pieces of data. The database system is compatible with most characteristics in the relational database, including SQL support, relational structure storage, ACID transaction guarantee and the like. Meanwhile, more blockchain characteristics are added, and the characteristics of block chain tamper resistance are provided, wherein the characteristics comprise tamper-resistant Byzantine consensus protocol, transaction blockchain, intelligent contract and the like.

In a first aspect, the present invention provides a method for storing data, comprising: after receiving a request sent by a client, a request receiving node directly performs simulation execution on a local state machine to generate a simulation execution result, and the simulation execution result and user execution logic are packaged and copied to other nodes for tamper-proof inspection; after receiving the message packet, other nodes in the network take out the user execution logic from the message packet to execute locally to generate a simulation execution result, and then compare the simulation execution results in the message packet; if the two results are inconsistent, the data tampering condition is represented, and the verification failure is replied to the initiating node; if the two results are consistent, replying verification success to the initiating node; after the verification initiating node receives enough verification replies, the verification initiating node performs summary judgment, directly discards the request for judging the verification failure, and performs pbft consensus replication logic by simulating an execution result set for the request for judging the verification success until the state replication is finished or fails.

Compared with the prior art, the anti-tampering verification logic is added before consensus, and the verified simulation execution result is used for copying, so that the anti-tampering design is achieved, and the consistency of good states can be maintained.

In a second aspect, the present invention provides a transaction processing method comprising on-chain and off-chain data: a client initiates an uplink and downlink transaction operation, wherein the transaction simultaneously comprises an uplink data updating operation set and a downlink data updating operation set; after receiving the request, the service end transaction request receiving node starts a transaction manager, processes according to the operation sequence in the transaction request, performs transaction pre-submission, generates two transaction processing logic log caches, and adds a transaction log generated by the transaction on the chain to a transaction cache pool on the chain, wherein the transaction log comprises transaction execution logic; and initiating an endorsement process by using a transaction log generated by the transaction on the chain, and if the endorsement process is successful, requesting the receiving node to start a consensus process. If the consensus process is successful, the request receiving node really submits the pre-submission generated by the on-chain transaction and the off-chain transaction, and other nodes only receive the on-chain transaction, so that only the on-chain transaction is submitted, and the request receiving node finishes the operation of the on-chain and off-chain transactions.

Compared with the prior art, the method and the device ensure the atomicity of the transaction, and the on-chain data and the off-chain data of the same transaction can be updated based on the transaction processing logic.

In a third aspect, an embodiment of the present invention provides a transaction processing method including multiple pieces of data on a chain: when a client sends a transaction, it needs to mark that the transaction relates to a cross-chain and indicate to which chain each transaction in the cross-chain transaction belongs respectively. When receiving a cross-chain transaction request of a client, a server firstly numbers transactions in a transaction in sequence and splits all transactions in the transaction according to a chain to which the transactions belong. Each chain executes the endorsement process related to the transaction, namely the single-chain endorsement process. And the server transaction initiating node collects the collected endorsement results, and for the cross-chain transaction, when the endorsement results of all the split transactions in the transaction conform to the endorsement strategy of the chain, the transaction is regarded as successful endorsement. And after the endorsement is successful, packaging and copying the request splitting result, each transaction number and the chain related to the cross-chain transaction to the node of the corresponding chain, and entering a consensus module of the system for consensus. Each chain independently carries out a consensus process, namely a single chain consensus process. Each transaction number and the cross-chain transaction relate to which chains need to be part of the transaction information, and the replication of all subsequent messages must be accompanied by both information. And in the submitting phase, after the current chain consensus is completed, the waiting state is entered, all nodes of the chain related to the cross-chain transaction are read, and the chain consensus result is sent to the nodes. Similarly, the chain also receives the consensus results of all other chains, and when the feedback that more than 50% of nodes of a certain chain pass the consensus is received, the chain is considered to pass the consensus. If the transaction involves all chains passing by consensus, it indicates that the chain passes by consensus. If a node contains multiple chains, each transaction needs to be submitted in turn according to the transaction number sequence. And the nodes on the chain only submit the transaction related to the chain in the transaction, and if the nodes join a plurality of chains related to the cross-chain transaction, the transactions related to the chain are submitted on different chains respectively according to the transaction sequence numbers.

In some implementations, the method also configures a system chain that is accessible by all nodes in the network for recording member information of all chains in the network. When a new chain is created in the network, adding a record in the system chain; and a new node is added into the chain, and the member information of the chain is updated by the creator of the chain and is synchronized to the whole system.

Compared with the prior art, the method and the device for updating the chain data of the transaction ensure the atomicity of the transaction, and update operation is carried out on the data on the chains of the same transaction based on the transaction processing logic.

In a fourth aspect, this embodiment further provides a data node, where the data node includes a plurality of functional modules, and the multifunctional modules enable the node to implement the functions described in the first, second, and third aspects.

In a fifth aspect, an embodiment of the present invention further provides a computer system, where the computer system is used as a node in a database system. The computer system comprises at least one processor and a memory, wherein the memory is configured to store a software program, and when the software program is executed by the processor, the processor of the computer system is configured to perform the method of the first, second, third aspect or any of the implementations.

In a sixth aspect, an embodiment of the present invention further provides a storage medium for storing a computer program, where when the computer program is executed by a processor, the processor is configured to implement any one of the methods provided in the first, second, and third aspects. In particular, the computer program may comprise one or more program elements for implementing the steps of the method.

Therefore, the embodiment of the invention provides a transaction method and a node of a blockchain system. The method realizes the fusion of data management and tamper-proof mechanisms in the database system, and reduces the cost of deployment, management and operation and maintenance. Meanwhile, a set of system can support the transaction processing capacity of a plurality of data on the chain and data under the chain, and the task cooperation efficiency of the system is improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments or the background art of the present invention, the drawings required to be used in the embodiments or the background art of the present invention will be described below.

FIG. 1 is a system architecture diagram of a database system provided by an embodiment of the present invention;

FIG. 2 is a schematic diagram of a storage structure of a database provided by an embodiment of the present invention;

FIG. 3 is a flowchart of a data storage method of a database system according to an embodiment of the present invention;

FIG. 4 is a flowchart of a data storage method of a database system according to another embodiment of the present invention;

FIG. 5 is a flowchart of a data storage method of a database system according to another embodiment of the present invention;

FIG. 6 is a flow chart illustrating a transaction operation between on-chain and off-chain data in a database system according to an embodiment of the present invention;

FIG. 7 is a flowchart of a data storage method of a database system according to another embodiment of the present invention;

FIG. 8 is a flow chart illustrating endorsement and consensus of a cross-chain transaction in another database system according to an embodiment of the present invention;

FIG. 9 is a flowchart illustrating a transaction operation performed on cross-chain data in a database system according to an embodiment of the present invention;

fig. 10 is a schematic diagram of a hardware architecture of a node in a database system according to an embodiment of the present invention.

Detailed Description

The embodiments of the present invention will be described below with reference to the drawings.

Some concepts in the blockchain network architecture are introduced first.

Client (Client): the user can realize the functions of creating chain codes, initiating transactions and the like through the client in the blockchain system. The client can be deployed on any terminal and implemented by an SDK (software development Kit) corresponding to the blockchain system. The terminal communicates with the nodes in the blockchain network, so that the corresponding functions of the client are realized.

Block (block): in the block chain technique, data is stored permanently in the form of electronic records, and the file storing these electronic records is called a "block". The blocks are generated chronologically one after the other, each block recording all the value exchange activities it has taken place during the creation, all blocks together forming a chained set of records.

Block structure (blockastructure): the block records transaction data in the block generation time period, and the block body is actually a collection of transaction information. The structural design of each block chain may not be identical, but the large structure is divided into a head (head) and a body (body). The chunk header is used to link to previous chunks and provide guarantees of integrity for the blockchain database, and the chunk body contains all records of verified value exchanges that occur during the chunk creation process.

Node (peer): in the block chain network, a network system with a distributed structure is constructed, so that all data in the database are updated in real time and stored in all network nodes participating in recording. Meanwhile, the block chain network constructs a whole set of protocol mechanism, so that each node of the whole network participates in recording and simultaneously verifies the correctness of the recording results of other nodes. Only when the nodes (such as all nodes, most nodes or specific nodes) meeting the conditions consider the record to be correct at the same time through a protocol mechanism, or all nodes participating in the record pass the comparison result in a consistent way, the authenticity of the record can be approved through the whole network, and the record data is allowed to be written into the block. Thus, in a blockchain network, all nodes together form a decentralized distributed database.

In different blockchain systems, nodes are partially special nodes in addition to being used for storing block data. E.g., endorsement node, sort node. The endorsement node is an execution intelligent contract state machine and simulates execution of transactions. The endorsement node comprises pre-designated endorsement policy sets, the endorsement policy sets are provided with specific chain codes, all transactions have to be transacted according to the endorsement policy, and only the transactions processed by the endorsement are legal and approved transactions. In a specific implementation, after receiving a transaction request of a client, the endorsement node executes a simulated transaction, and generates an endorsement signature according to a result of the simulated transaction, thereby completing the endorsement of the transaction.

Relational Database (RDB): the RDB database is a database based on a relational model, and is also called a relational database. In a computer, a relational database is a collection of data and database objects. By database objects are meant tables, views, stored procedures, triggers, etc. The computer software for managing the Relational Database is a Relational Database Management System (RDBMS). A relational database is made up of data tables and relationships between the data tables. In a relational database, the association of tables is a very important component. The table association means that the data tables in the database are connected with the data tables by using corresponding fields.

The business relationships of most business systems can be defined using a model of a relational database. Standard data Query Language (SQL) is a relational database-based Language through which data in a database can be retrieved and manipulated. Some demands for blockchain accounts exist in current business systems, such as supply chain article tracking accounts, multi-party order accounts in e-commerce platforms, and the like, tamper-resistant and repudiation-resistant characteristics of blockchain technologies are needed to support operation of blockchain articles tracking accounts, and the blockchain articles tracking accounts can be defined as such account data and can be called as on-chain data. Meanwhile, the on-chain data may have some strong correlation with other data in the original service (also referred to as off-chain data), and consistency, atomicity, and the like between them are generally required to be maintained. However, the business system simply splits some data to the blockchain, so as to obtain the advantages brought by the blockchain account book, and make the common management of the data on the chain and the data under the chain more difficult.

Relational database systems place more emphasis on consistency, high availability, high performance, and blockchain systems place more emphasis on non-tamper-ability, de-centralization, security. Based on the characteristics of the two, some system prototypes fusing database technology and block chain technology, such as bigchain db, ChainSQL, Catena, etc., have appeared in the industry, and all of the prototypes have decentralization, tamper resistance, byzantine fault tolerance, etc. in terms of embodying the characteristics of the block chain, but there is no small difference in the capability in terms of data management: 1) BigChainDB does not support SQL access, only supports K-V type data structures and does not support transactions; (2) ChainSQL synchronizes the unstructured data of the block chain to a structured external database, supports limited SQL access, and also increases the problem of consistency maintenance because the state is stored in a newly added external database system and does not support transactions; (3) the Catena can be regarded as a lightweight SQL support module added to the traditional public link system, the SQL support capability is very limited, the transaction is not supported, and the common recognition is a non-deterministic algorithm and is very far away from the ACID transaction guarantee.

In the invention, the data management capability of the traditional relational database is combined with the credible realization tamper-proof capability of the block chain technology, and the data is output as an interface through the universal SQL. The data management and tamper-proof system realizes the appeal of a set of system to users, thereby reducing the deployment, management, operation and maintenance cost and shortening the learning curve. The system can support multi-chain and down-chain data storage, does not need synchronization of a third-party tool, directly provides up-chain and down-chain affair and cross-chain affair operation, and is high in collaborative analysis efficiency.

In order to facilitate understanding of the present invention, some key concepts in the embodiments of the present invention are explained below.

An endorsement consensus mechanism:

some mainstream strong-consistency distributed database systems currently build a state replication mechanism between nodes based on paxos-like non-Byzantine fault-tolerant consistency protocol. The replicated content for this type of mechanism may be: a) a set of execution result states for a single node; b) request execution logic;

the type a is that one node simulates and executes user request logic, a simulation execution result is taken, then the simulation execution result is subjected to consistency copying, after the consistency is achieved, each participating node directly uses the simulation execution result to update the self state, the type mode is relatively easy to maintain the consistency of the cluster state, such as row-based binlog of MySQL, CRUD operation log of zookeeper and the like, then the type mode is more similar to the mode of using a single node to update the state of the whole cluster, and if the simulation execution node is tampered, the whole cluster state is disordered;

b type copies original user execution logic on the whole cluster node, then executes and updates respective states on each node independently, which is beneficial for each node to maintain its own state independently, and is more beneficial to the situation of tampering, such as MySQL state-based binlog, etc., however, this type focuses on the copying process, in some implementations, the process may have randomness, such as random () logic, etc., so that the execution on different nodes may bring inconsistent problems;

as can be seen from the above, the simple use of a and b does not achieve the purpose of tamper resistance and consistency at the same time, the database system in the embodiment of the present invention provides a tamper-resistant copy mechanism: (1) after receiving a request sent by a client, a request receiving node directly performs simulation execution on a local state machine to generate a simulation execution result, and the simulation execution result and user execution logic are packaged and copied to other nodes for tamper-proof inspection; (2) after receiving the message packet, other nodes in the network take out the user execution logic from the message packet to execute locally to generate a simulation execution result, and then compare the simulation execution results in the message packet; (3) if the two results are inconsistent, the data tampering condition is represented, and the verification failure is replied to the initiating node; if the two results are consistent, replying verification success to the initiating node; (4) after the verification initiating node receives enough verification replies, the verification initiating node performs summary judgment, directly discards the request for judging the verification failure, and performs pbft consensus replication logic by simulating an execution result set for the request for judging the verification success until the state replication is finished or fails.

Compared with the traditional state copying machine, the database system of the embodiment of the invention adds the anti-tampering verification logic before consensus, and copies by using the verified simulation execution result, thereby achieving the anti-tampering design and maintaining the consistency of the state.

Transaction block chaining:

the blockchain system can ensure the non-tamper property of historical transactions through a chain structure. The current relational database only saves historical operation logs in files for data recovery and other works, but the log files cannot guarantee tampering. To this end, the database system of embodiments of the present invention builds blocks using the log content of transactions and assembles into chains. The block contains additional contents such as a block number, a parent block hash value, a transaction number, a timestamp, various signature information and the like in addition to all submitted transactions of the transaction. In the same block chain system, the database system chain table of the embodiment of the invention ensures non-tamper property through parent block hash, and meanwhile, the information of a request initiator can be traced through a transaction signature, and the endorsement approval node information can be traced through an endorsement signature.

Intelligent contract:

the intelligent contract is used as a block chain and is expanded from a single digital currency function to the most critical characteristic of each field, and each node can execute the same business logic. In the relational database, the storage process already contains similar functions, but the traditional relational database is operated in a relatively trusted environment, so the flow design of the storage process is still implemented in a single point, and a multi-point copy state is taken as a main point, so the storage process does not have tamper resistance. The database system of the embodiment of the invention combines the design characteristics of the storage process, expands the storage process into the property of the tamper-resistant intelligent contract, when the message is copied, the calling command and the execution result are packed and copied to all nodes to be subjected to tamper-resistant verification, and only the calling passing the verification continues to be processed in the subsequent steps. Meanwhile, the database system of the embodiment of the invention supports multiple chains, one intelligent contract corresponds to one chain and is only installed on the node of the corresponding chain, and when the chain is deleted, the intelligent contracts on the chain are also cleaned together. All on-chain data update operations in the system can only be completed through intelligent contract calls.

And (3) authority management:

rights management is primarily established for the multi-block chain supported by the system herein. The Chain structure in the database System of the embodiment of the invention is divided into two types, namely System Chain and Data Chain, wherein the System Chain is a System Chain and is used for storing and managing the meta information of the whole cluster Data Chain; and the Data Chain is used for reading and writing user Data and initiating creation for the user. For convenience of description, one participating Node of Data Chain is described herein as a Member Node of the Chain, otherwise it is referred to as a non-Member Node of the Chain.

(1) Data Chain access right control, in view of better Data isolation and privacy protection, the access control right to the Data Chain is only reserved for the participating nodes in the Chain, and if a Node wants to access Data of other nodes maintaining the Chain, the Node needs to access through the access to the Member Node.

(2) And (3) controlling System Chain access authority, wherein the System Chain is used as a meta-information storage Chain of the whole System, is invisible to external users, and only allows the cluster member nodes to access by System requests. Firstly, voting is carried out on all member nodes in the whole cluster to achieve consensus, the construction of the Chain is completed, and the configuration information of all the members is stored in the Chain, wherein the information is written once when the System Chain is constructed, and only reading is allowed at the later stage, and modification and addition are not allowed again; secondly, when a certain Data Chain is created, the Data Chain message is written into the System Chain by the Member Node, and the System Chain verifies whether the writer is one of the Member nodes of the Data Chain.

On-chain transactions versus off-chain transactions:

in the existing blockchain system, data are stored in an account book and can be accessed by all nodes, and the privacy of the data cannot be guaranteed. For a business scenario (such as a financial system) requiring data privacy, only a part of private data can be stored out of the chain, and the rest of public data is linked up, so that an additional system is required to maintain the association consistency of the two parts of data. In the database system of the embodiment of the invention, in order to more effectively perform data isolation, a chain is defined according to DB granularity, each block chain is maintained as a partition channel, meanwhile, the whole cluster alliance can maintain a plurality of channels, and each node instance can simultaneously support two data storage types:

a) On-Chain: the on-chain DB, namely an on-chain block chain, stores on-chain data shared by nodes, all the nodes participate in maintenance, and each chain is collectively called a channel; when creating a DB, the system creates a channel according to the DB name; each channel is commonly identified and maintained by all the member nodes of the alliance;

b) Off-Chain: the link DB, namely the link local library, stores the link data private to the node and is only maintained by the creation node;

the whole cluster alliance supports multi-block chain coexistence and under-chain coexistence, and the whole member node maintains a built-in system chain for managing all user data chain information.

Based on the multi-chain design, the embodiment of the invention provides an integrated scheme for multi-type data management, and provides characteristics for transactional support between the multi-type data management and the multi-chain design:

1) chain-crossing transactions on the chain: ensuring atomicity of batch operation on data on multiple chains in one transaction, namely, updating on all chains is successful or updating on all chains is failed;

2) uplink and downlink transactions on the chain: ensuring atomicity of batch operations on-chain and off-chain data in one transaction, i.e. either all on-chain updates and included off-chain updates are successful or all fail;

the following describes in detail on-chain cross-chain transactions

When a certain node in the database system of the embodiment of the invention receives a user request and simultaneously comprises data updating operation on a plurality of chains, the node generates a cross-chain transaction for processing.

After the cross-chain transaction is generated, the service end node generates a transaction log in the Prepare stage of the transaction, the transaction log is split into single-chain parts according to the chain granularity, then the member nodes of each chain are searched through the system chain, endorsement consensus is respectively carried out by using the single-chain parts, and commit information of each chain consensus needs to be broadcast to all participating nodes. All the participating nodes take the results of all the chain consensus and count the results, and the transaction part of the chain maintained by the node can be submitted only when all the chain consensus is completed, so that the aim of ensuring that all the chain updates are either completely successful or completely failed for the whole cluster is finally achieved.

Next, the following describes the chain-up/down chain-crossing transaction

When a node in the database system of the embodiment of the invention receives a user request and simultaneously comprises a link uplink and downlink updating operation, the node generates a link uplink and downlink transaction for processing.

After the uplink and downlink transaction in the chain is generated, the service end node processes according to the above-mentioned transaction processing flow, and at the Prepare stage of the transaction, the generated transaction log is divided into two parts: (1) an intrachain moiety; (2) a portion under the chain; where the update oplog for data on the chain exists only in the on-chain portion.

When the endorsement consensus process is carried out, the node only uses the part on the chain (1) in the transaction log, after the endorsement consensus process passes, the node submits the chain (1) and the chain (2) at one time, and if the endorsement consensus process fails, the node rolls back, and finally achieves the atomic operation under the chain.

Example one

A system architecture diagram of a database system according to an embodiment of the present invention will be described with reference to fig. 1. As shown, the database system of the embodiment of the present invention can be divided into a client side 110 and a server side 120. The client 110 includes a plurality of clients of the client 110a, 110b, 110c … … 110n, and the server 120 includes a plurality of servers of the server node 120a, 120b, 120c … … 120 n. The server node may be a separate physical server or may be a virtual machine node.

Each of the clients 110 (110a, 110b, 110c … … 110n) has an application 111, an SDK/API module 112, and a signature module 113. The SDK/API module 112 is responsible for supporting database connection APIs, thereby enabling the database system to support other business systems. The signing module 113 issues a certificate through Triangle CA to complete login and request signing verification; during the handshake phase between the client 110 and the server 120, the security module 113 signs the login request information and attaches the signature information and the certificate to the request information. After receiving the login request message of the client 110, the server 120 will continue to perform the handshake flow only after completing the authentication, otherwise, the login fails.

Each node (120a, 120b, 120c … … 120n) in the server 120 includes the following modules:

the CA module 121 is mainly used for the authority management of the system and refers to a CA verification scheme. Firstly, a root certificate and a corresponding private key are generated, and then a common certificate and the corresponding private key are signed and issued by using the private key of the root certificate. The root certificate private key storage and certificate signing work needs the negotiation of the whole alliance member to complete. Each server contains a root certificate, which acts as the central authentication authority for the CA. All messages in the network must be attached with signature information and supporting certificates.

The security module 122: the signature verification method is used for verifying the signature in the endorsement request and adding the endorsement result signature after the endorsement is successful. And in the transaction endorsement stage, after receiving the copied message, other service nodes perform verification operation and then execute the endorsement process. After the endorsement is finished, when the endorsement result is returned, the endorsement result also needs to be signed by using a server-side private key, and then the signature and a matched certificate are attached to the endorsement result. In the consensus stage, verification work is required to be carried out when endorsement results of all nodes are collected. Only the result of the verification is regarded as valid endorsement information.

The SQL parsing module 123: the system is used for analyzing the SQL request from the client, analyzing the SQL statement in the request according to the SQL grammar rule, and converting the text into an abstract grammar tree.

Intelligent contract module 124: for managing user-installed smart contracts.

Endorsement consensus module 125: the system is responsible for endorsement and consistent copying of the node to the transaction request and has Byzantine fault tolerance capability. Compared with the traditional state copying machine, the database system of the embodiment of the invention adds the anti-tampering verification logic in the consensus module: 1) after receiving a request sent by a client, a request receiving node directly performs simulation execution on a local state machine to generate a simulation execution result, and the simulation execution result and user execution logic are packaged and copied to other nodes for tamper-proof inspection; (2) after receiving the message packet, other nodes in the network take out the user execution logic from the message packet to execute locally to generate a simulation execution result, and then compare the simulation execution results in the message packet; (3) if the two results are inconsistent, the data tampering condition is represented, and the verification failure is replied to the initiating node; if the two results are consistent, replying verification success to the initiating node; (4) after receiving enough verification replies, the verification initiating node performs summary judgment, directly discards the request for judging the verification failure, and performs PBFT consensus replication logic on the request for judging the verification success by simulating an execution result set until the state replication is finished or fails;

the storage engine module 126 is mainly used for data storage. Data is mainly classified into 3 types: system chain data, user chain data, and user private data. The specific data storage form is as follows:

system chain data: and configuring a system chain DB when the system is established, and storing meta information of all chains in the system. The DB contains two types of tables: 1. system member table: the table contains all node information, node ID, IP address and state information in the system, (the nodes may not belong to the same chain); 2. chain member table: and respectively creating a configuration table for each chain, wherein the table name is consistent with the chain name, such as: chain 1. This type of table contains all the node IDs, IP addresses, certificates, endorsement node flags and status information (online, offline, error) on the chain. And in the process that the user joins the system or joins the chain, initiating a transaction to update the system member table or the chain member table. In the process of creating the chain by the user, the system correspondingly creates a configuration table of the chain according to the chain created by the user and inserts the member node information of the chain. The system data chain has backup at all nodes, can be accessed by all nodes and maintained together, and the configuration information can be used for configuring endorsement strategies and cross-chain transactions;

user chain data: containing 3 parts of content, 1) user on-chain data: this part of the data is the real user traffic data in the system. If the node adds a plurality of chains, the user data on each chain respectively corresponds to one DB, and the data between the chains are isolated by the DB. Nodes belonging to the same chain commonly maintain user data on the chain, and nodes not in the chain have no backup of the part of data. Modifying data on the user chain into a corresponding block table and a history table; 2) historical snapshot chain data for tracing back transactional updates and 3) blockchain data for the chain. User chain data is stored in a blockchain DB of the system, each chain comprises a block table (named as $ { chain _ name } _ blockchain) and a plurality of history tables (each history table corresponds to a table in the user chain data DB and is named as $ { chain _ name } _ table _ name } _ chain), and if one node is added to the plurality of chains, a plurality of pieces of user chain data are maintained locally. The partial data only has backup on the nodes contained in the chain, and other nodes which are not added into the chain cannot access or operate the partial data;

user link down data: the part of data belongs to the private data of the node and exists independently on the node. If the node-initiated transaction involves operating user data down the chain, the system filters the content of the part and only synchronizes and copies the part of the data up the chain in the transaction. Meanwhile, the part of data is modified, so that a history record and a new block cannot be generated, and the data only takes effect locally at the node.

Referring to fig. 2, there is an example of a multi-chain co-existing in one server cluster. Node1, node2 and node 3 together maintain a system chain. Node1 maintains data on data chain1 in common with node2, while node2 and node 3 maintain data on data chain2 in common. Meanwhile, node1 and node 3 each maintain their respective downlink data.

Transaction block engine 127: the method is responsible for generating the blocks corresponding to the transaction requests, maintaining the update of the data of the whole block chain and ensuring the distributed transaction characteristics of the requests among the nodes.

In this embodiment, the data storage is performed through a chain structure, which is specifically as follows:

a transaction chain:

in the database system of the embodiment of the invention, each channel has a transaction chain for storing transaction logs, so that the system has tamper-resistant capability. When creating a channel, a corresponding transaction chain is automatically created, which is still kept in a table in a relational structure. The block table structure information is: block number, parent block hash, transaction initiation timestamp, client signature, all endorsement node signatures, the transaction content, execution result.

And after the consensus is completed, packaging the transaction logs completed by the consensus into blocks, wherein each transaction is used as one block. The transaction log is firstly analyzed, and information such as client transaction initiation time, transaction requests, endorsement execution results, client signatures, endorsement node signatures and the like is read. And then reading the content of a block in the chain structure, firstly adding one to the block number of the last block as the block number of the block, and then solving the hash of the whole block as a parent block hash value. All the above contents form the block of the current transaction according to the transaction block table structure. The chain structure is formed by the hash of each block containing the parent block.

After the block is generated, the transaction linked list is directly inserted. Since the transaction log is the result of the consensus of all nodes of the chain, i.e. the transaction log is guaranteed to be the same, it can be guaranteed that the contents of the blocks of each node are consistent. If the data is tampered, the parent block hash cannot be verified.

History snapshot chain:

the current relational database does not support the function of directly inquiring historical information, and cannot rapidly analyze and count through SQL grammar. In the database system of the embodiment of the invention, each data table is independently designed with a history snapshot chain for storing all history states of the table. The historical snapshot chain is also stored in the table according to a relational structure, and when a user creates the data table, a corresponding historical snapshot chain table is automatically created. The table structure information: and corresponding to all columns, block numbers, transaction numbers and upper strip record hash values of the data table. The table is created when the user creates the data table. Also, historical snapshot chains are stored using relational tables, one record for each transaction.

Each transaction of a transaction generates a record in the corresponding history snapshot chain as a block of the history block photo chain, and the block and the transaction chain block are generated simultaneously. When the transaction chain analyzes the transaction log, the execution result is analyzed again, and the transaction log is sorted according to transaction and split. For each transaction, reading information such as a data table of operation, modification content, transaction type and the like, and using the transaction individual number related to each table as a transaction number. And each transaction takes a parent quick hash value and simultaneously takes the block number of the transaction. And (4) all the information is grouped into blocks according to the history snapshot chain, and the hash values of the parent blocks are also grouped into a chain structure.

When the historical state information of certain data needs to be inquired for analysis and statistics, only SQL grammar is used for inquiring in the corresponding historical table. Transaction chain, history snapshot chain can prevent history data from being tampered.

In an embodiment of the present invention, as shown in fig. 3, a basic granularity of a processing flow in the embodiment of the present invention is a transaction, where one transaction includes a plurality of intelligent contracts and a plurality of calls of a common sql, and a main processing flow of the transaction is as follows:

s301, the client initiates a transaction, the SQL analysis 123 module analyzes the request, whether the transaction is the transaction for calling the intelligent contract is judged, and if the transaction is the transaction for calling the intelligent contract, the intelligent contract installed by the user is called from the intelligent contract module to be executed;

s302, firstly, the transaction is locally executed at the initiating node to generate a read-write set, the security module 122 of the node signs the transaction, and then the transaction request command, the local read-write set and the node signature are packaged;

s303, after the transaction is prepared, entering an endorsement consensus module 125, firstly carrying out an endorsement process (endrose), verifying that the world state before the transaction is executed and the execution logic of the transaction request command are not tampered, and the world states after the same command is executed are consistent, considering that the endorsement is successful, and then entering a PBFT consensus replication process;

s304, after the transaction is identified and copied by the nodes, the transaction block engine 127 of the node packs the transaction blocks to generate blocks and generates the history record of the history snapshot chain according to the transaction content;

s305, the storage engine module 126 writes the transaction into the disk, namely, updates the world state, and persists the blocks and the history chain records into the disk.

Example two

Fig. 4 is a flowchart illustrating an embodiment of the present invention, which can be applied to the database system shown in fig. 1, and can also be based on other system architectures according to the design concept of the present invention. The flow method describes how, in the database system of this embodiment, the transaction request of the client generates transaction data in the server and stores the transaction data in the database of the data node. In this embodiment, in combination with different embodiments, different node roles may be implemented by the same node or different nodes. For example, in some implementations, the node that executes the endorsement process and the node that stores the data are the same node, that is, the same node can implement both the function of the endorsement node and the function of the data node; for another example, in some implementations, some of the data nodes do not act as endorsement nodes, i.e., such nodes have only the functionality of data nodes and not the functionality of endorsement nodes.

The method of the embodiment comprises the following steps:

s401, the client side initiates a transaction instruction to the node.

In one implementation mode, the client is deployed on other terminals separated from the node, after a user carries out transaction operation through the client, the terminal sends a transaction instruction to the node, and the node carries out transaction through the network. In another implementation, the client is deployed on the node, and after the user performs the transaction operation through the client, the node can directly obtain the transaction instruction generated by the transaction operation.

The client generates a transaction instruction, the request content includes transaction execution logic in the form of SQL statements such as DML, DDL, etc., and the request content creates a record of the student basic information:

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

in the SQL command, the transaction instruction of the client instructs to write a table storing transaction information, and write a corresponding value to its entry.

In some implementations, signature information that proves the legitimate identity of the client is also included in the transaction instruction. The node can verify the signature information through the security module, so as to determine the client identity corresponding to the transaction instruction.

S402, the transaction initiating node receives the transaction instruction sent by the client, analyzes and locally executes the SQL statement in the transaction instruction.

In the node 120, the node that receives the transaction instruction sent by the client serves as a transaction initiating node. For example, in one embodiment, node 120a receives a transaction instruction sent by a client and initiates the transaction in node 120 as a transaction initiation node.

The transaction initiating node 120a parses the transaction instruction from the client through the SQL parsing module, parses the SQL statement in the transaction instruction according to the SQL syntax rules, and converts the text into the abstract syntax tree. Based on the parsed SQL statement, the transaction initiating node 120a executes the SQL statement locally, thereby generating a read-write set S (r, w) based on the local world state, where the read set and the write set respectively correspond to the world states before and after the execution of the transaction.

In some implementation manners, because the transaction instruction further includes signature information for proving the legal identity of the client, the transaction initiating node firstly verifies the signature information when receiving the transaction instruction, and only executes the SQL statement in the transaction instruction locally after determining the validity of the user identity based on the verification result.

In some implementations, the transaction initiating node signs the transaction after successful local execution, thereby generating signature information for the transaction initiating node.

And S403, the transaction initiating node sends SQL statements in the transaction instruction sent by the client and the read-write set S (r, w) generated by local execution to the endorsement node for endorsement.

Based on the endorsement policy of the database, the transaction initiating node needs to endorse the transaction.

Different from the blockchain system, in the embodiment, when the transaction initiating node initiates the endorsement operation, in addition to sending the SQL instruction including the transaction execution logic to the endorsement node, the transaction initiating node also sends the read-write set S (r, w) indicating the world state before and after the local execution of the SQL instruction by the transaction initiating node to the endorsement node. It is understood that, in different embodiments, the SQL instruction and the read-write set S (r, w) may be sent to the endorsement node through the same message or the same communication flow, or may be sent to the endorsement node through different messages or communication flows.

In some implementations, the transaction is signed by the transaction initiating node after successful local execution, thereby generating signature information for verifying the legitimate identity of the node. When the endorsement is carried out, the transaction initiating node also sends the signature information to the endorsement node.

S404, the endorsement node receives the endorsement request sent by the transaction initiating node and locally executes the SQL instruction in the endorsement request.

And the endorsement node locally executes the SQL statement, analyzes the SQL statement according to the SQL grammar rule and converts the text into an abstract grammar tree. Based on the parsed SQL statement, the node 120a executes the SQL statement locally, thereby generating a read-write set S' (r, w) based on the local world state, where the read set and the write set respectively correspond to the world states before and after the execution of the transaction.

In some implementation manners, because the transaction instruction further includes signature information for proving the legal identity of the client, the endorsement node firstly verifies the signature information when receiving the transaction instruction, and only executes the SQL statement in the transaction instruction locally after determining the validity of the user identity based on the verification result. In some implementations, because the transaction initiating node sends the signature information with the identity of the transaction initiating node to the endorsement node, the endorsement node first verifies the signature information, and only executes the SQL statement in the transaction instruction locally after determining the validity of the transaction initiating node based on the verification result.

S405, the endorsement node compares and verifies the read-write set S' (r, w) of the local execution transaction with the read-write set S (r, w) sent by the transaction initiation node.

In one implementation, when comparing and verifying the read-write set S' (r, w) for locally executing the transaction with the read-write set S (r, w) sent by the transaction initiating node, some implementations compare whether hash values are the same after hashing the two read-write sets respectively; other implementations include, but are not limited to, ways to directly compare binary codes of two read-write sets, etc.

After the comparison, if the results are the same, the endorsement node sends an indication message that the endorsement is successful to the transaction initiating node, and in some implementation modes, the endorsement node signs the transaction and sends the signature information to the transaction initiating node. And if the results are different, sending an instruction message of endorsement failure to the transaction initiating node.

S406, the transaction initiating node collects the endorsement results and judges whether the endorsement strategy is met. The endorsement policy may determine, based on the system configuration, which nodes the transaction execution needs to be confirmed by, the endorsement policy may specify all nodes as endorsements (transactions need to be confirmed by all nodes), most nodes as endorsements (e.g., transactions need to be confirmed by more than 2/3 nodes), and a node as endorsement (e.g., transactions need to be confirmed by node A, B, C), the node specified by the endorsement policy being the endorsement node. The endorsement policy is in units of chains, and if a node belongs to a plurality of chains, the endorsement policy needs to be specified for each chain.

In some implementations, the transaction initiating node may verify the signature sent by the endorsement node to determine the legitimate identity of the endorsement node to which the endorsement result corresponds.

S407, if the endorsement policy is met, entering a consensus module of the system for consensus; otherwise, indicating that the data may be inconsistent, discarding the transaction, and feeding back to the client: the transaction fails and the data may be tampered with requiring manual intervention. In the above flow, if the endorsement is not passed, the transaction related to the tampered data cannot pass the endorsement later, but the transaction related to other transactions can still be executed normally at the moment, and the usability of the system is not affected.

And S408, the transaction initiating node sends the endorsed transaction to the consensus module of the node and performs consensus with other nodes, and the consensus algorithm can adopt various existing consensus algorithms, such as a PBFT algorithm. The consensus module is responsible for authenticating and ordering distributed transactions. If agreement is reached, execution continues, otherwise the transaction is discarded.

In one embodiment, transactions are consensus based on PBFT. The consensus is mainly used for sequencing the transactions, and if the transactions conflict, the corresponding transaction consensus fails, and the transactions fail. In the database system of the embodiment of the invention, the PBFT requires three stages of networks.

(1) pre-prepare: after the endorsement is achieved, the consensus is initiated by the sequencing node. The sequencing node may be a transaction initiating node or other nodes in the server cluster. And initiating the transaction request and sending the transaction request to other nodes in the channel. And after receiving the request, other nodes judge whether the information such as the reading set and the like contained in the request conflicts, if no conflict exists, the other nodes agree to the request and send the request to other nodes in the channel.

(2) prepare: when more than 2f +1 node grant requests are received, the node grants the transaction commit. And sends the results to all other nodes.

(3) commit: if more than 2f +1 nodes are received to approve the transaction to be submitted, the consensus is finally achieved, and the transaction is submitted.

S409, after the consensus is completed, if the consensus is reached, each node enters a submission stage, so that the user data is updated

This process includes 3 parts:

1. the node generates a block according to the transaction request and a read-write set generated by executing the transaction: the newly generated block comprises the block number of the current block, transaction execution logic and an execution result; the process of generating the block further comprises the steps of obtaining the record of the previous block from the block table, carrying out hash operation, putting the calculated hash value into the previous hash field of the newly generated block, and then writing the block into the block table to form the chain structure of the block.

2. The node generates a history record according to the transaction request and the user data influenced by the transaction: the history records comprise updated user data content, block numbers, transaction initiator signatures, transaction endorser signatures and hash values of the previous history record, and the adjacent history records form a snapshot chain through the hash values;

3. and submitting the transaction and updating the user data.

EXAMPLE III

This embodiment contains a flow description between the on-chain transaction and the off-chain transaction. For convenience of description, the method flow of the present embodiment refers to the corresponding steps in the foregoing embodiments, and thus may be implemented based on the flow in the foregoing embodiments. However, the inventive content described in this embodiment may also be implemented in other database systems meeting the condition, and thus, the implementation manner in this embodiment is not necessarily limited by the foregoing embodiment.

If the transaction involves a chain uplink or downlink transaction or a chain cross transaction, the transaction is split in the endorsement flow before the transaction is forwarded: for the uplink and downlink transactions of the chain, only the SQL statements of the data on the operation chain and the generated read-write set are forwarded; for the cross-chain transaction, the system splits the transaction according to the granularity of the chain where the transaction is located, respectively forwards the SQL statement and the read-write set of the corresponding chain, and verifies the endorsement result according to the endorsement strategies of different chains in the configuration after receiving the endorsement result. This cross-chain transaction endorsement is considered successful only if the endorsement policies of all the chains involved in the cross-chain transaction are satisfied simultaneously.

Each node maintains a down-link data storage domain: OffChain is used for storing data under the chain, such data only exists in the node, and the private data belonging to the node is not required to be identified and copied to other nodes, but the data of the node maintains the affairs of the data under the chain and the data on the chain.

In this embodiment, the transaction assurance is provided for the operation under uplink, and with reference to fig. 5, the specific process is as follows:

s501, a client initiates an uplink and downlink transaction operation, wherein the transaction simultaneously comprises an uplink data updating operation set onchain op set and a downlink data updating operation set offchain op set;

s502, after receiving a request, a service-side transaction request receiving node starts a transaction manager, processes according to an operation sequence in the transaction request, performs transaction pre-submission on both the offshain op set and the onhain op set, generates two transaction processing logic log caches offshain r-w set and onhain r-w set, accesses other requests of the node at the moment, cannot see the update of the transaction because the requests are not really submitted, and simultaneously adds a transaction log generated by the onhain op set into a transaction cache pool on a chain, wherein the transaction log comprises a transaction execution logic onhain op set and an onhain r-w set;

s503, initiating an endorsement process by using a transaction log generated by the onchain op set (refer to the specific step in the first embodiment), if the endorsement process fails, requesting an accepting node to roll back the uplink and downlink transactions of the chain, rolling back the pre-submissions generated by the ofchain op set and the onchain op set at the same time, exiting the transaction failure, returning an error code to the client, and if the endorsement process succeeds, going to the next step;

s504, a request receiving node initiates a consensus process by using a transaction log generated by the onchain op set, if the consensus process fails, the request receiving node rolls back the uplink and downlink transactions on the chain, rolls back the pre-submissions generated by the ofchain op set and the onchain op set at the same time, exits the transaction failure, and returns an error code to the client, and if the consensus process succeeds, the next step is started;

s505, the request receiving node really submits the pre-submission generated by the offchain op set and the onchain op set, and other nodes only receive the onchain op set, so that only the onchain op set is submitted, and the request receiving node finishes the chain uplink and downlink transaction operation.

A specific example is described below in conjunction with fig. 6:

in the Tx prepare stage, a transaction including an uplink data operation and a downlink data operation is submitted to the Node 1(Node1), after the Node1 is executed in a simulation mode, a transaction log OnChain Tx log of the uplink data and a transaction log OffChain Tx log of the downlink data are obtained, and the transaction logs further include a read-write set after the data operation and the data simulation execution. In the endorsement and endorsement stage (endo & Consensus), the log OnChain tx log of the data on the chain is subjected to the Consensus and endorsement with the nodes 2 and 3, when the Consensus and endorsement are successful, the submission stage is entered, the node1 submits the transaction containing the data on the chain and the data under the chain, and the nodes 2 and 3 submit the transaction of the data on the chain. If the consensus and endorsement fail, node1 rolls back the simulation execution of the on-chain data and off-chain data operation transactions, while nodes 2 and 3 roll back the simulation execution of the on-chain data.

In some implementation manners, in consideration of stronger disaster tolerance capability, the OffChain data node is held, an additional node can be added by itself, and the OffChain data is changed into private OnChain data.

Example four

In another embodiment, it is described how the invention handles the cross-chain nature between transactions on a chain, i.e. the way when more than two data chains are involved for the same transaction. For convenience of description, the method flow of the present embodiment refers to the corresponding steps in the foregoing embodiments, and thus may be implemented based on the flow in the foregoing embodiments. However, the inventive content described in this embodiment may also be implemented in other database systems meeting the condition, and thus, the implementation manner in this embodiment is not necessarily limited by the foregoing embodiment.

In the prior art alliance chain, data isolation is generally realized through chains, and different chains have no interoperability and cannot access data mutually. But part of the transactions in a real business scenario involve atomicity in different chains: a transaction comprises transactions involving multiple chains that must succeed simultaneously while failing, i.e., cross-chain.

This embodiment supports the cross-chain feature, and with reference to fig. 7, a specific cross-chain flow is as follows:

s701, configuring a system chain, wherein the chain can be accessed by all nodes in the network and is used for recording member information of all chains in the network. When a new chain is created in the network, adding a record in the system chain; and a new node is added into the chain, and the member information of the chain is updated by the creator of the chain and is synchronized to the whole system.

S702, when the client sends a transaction instruction, the transaction related to cross-chain needs to be marked and the chain to which each transaction in the cross-chain transaction belongs is indicated. When receiving a cross-chain transaction request of a client, a server firstly numbers transactions in a transaction in sequence and splits all transactions in the transaction according to a chain to which the transactions belong.

S703, the service end node analyzes the transaction execution logic in the split result and locally executes the transaction execution logic to generate read-write sets corresponding to different chains; the node packages the split transaction execution logic, the read-write set and the signature of the node according to the chain to which the node belongs, and sends the packaged transaction execution logic, the read-write set and the signature of the node to the endorsement node on the chain corresponding to the transaction to perform endorsement, and the endorsement process can follow the endorsement process in the embodiment.

And S704, the service end transaction initiating node collects the collected endorsement results, and for the cross-chain transaction, when the endorsement results of all the split transactions in the transaction conform to the endorsement strategy of the chain, the transaction is regarded as successful in endorsement. And after the endorsement is successful, packaging and copying the request splitting result, each transaction number and the chain related to the cross-chain transaction to the node of the corresponding chain, and entering a consensus module of the system for consensus. Each transaction number and the cross-chain transaction relate to which chains need to be part of the transaction information, and the replication of all subsequent messages must be accompanied by both information.

S705, in the commit stage, after the current chain consensus is completed, the waiting state is entered, all nodes of the chain related to the cross-chain transaction are read, and the chain consensus result is sent to the nodes. Similarly, the chain also receives the consensus results of all other chains, and when the feedback that more than 50% of nodes of a certain chain pass the consensus is received, the chain is considered to pass the consensus. If the transaction involves all chains passing by consensus, it indicates that the chain passes by consensus. If a node contains multiple chains, each transaction needs to be submitted in turn according to the transaction number sequence. The submission of the cross-chain transaction follows the submission flow in the foregoing embodiment, the nodes on the chain submit only the transaction related to the chain in the transaction, and if the nodes join multiple chains related to the cross-chain transaction, the transactions related to the chain are submitted on different chains respectively according to the transaction sequence numbers.

The endorsement consensus process between multiple chains is specifically described below by way of an example in conjunction with fig. 8:

in fig. 8, Node 0(Node0) maintains only chain 1(chain1), Node 1(Node1) to Node 4(Node4) maintain both chain 1(chain1) and chain 2(chain2), and Node 5(Node5) maintains only chain 2(chain 2).

The endorsement consensus process is as follows:

1. pre-prepare stage: node1 receives a cross-chain transaction: separating the chain1Tx and the chain2Tx, performing transaction pre-operation on the node, if the pre-operation passes, delivering the chain1Tx into the blockchain1, and delivering the chain2Tx into the blockchain 2;

2. stage Prepare: endorsement is carried out on all nodes on blockchain1 to chain1Tx, the results are sent to all nodes in a voting mode, the voting results of all nodes on blockchain1 on the affairs are counted, the voting statistical rule is made to be >2f1, the statistical result of the nodes on the chain to chain1Tx is finally used as commit opinion voting to send a whole member, wherein the affair information is taken when the nodes on the chain are sent to the member nodes, the voting success or failure mark is taken when the nodes on the chain are sent to the nodes outside the chain, and all nodes on blockchain2 process chain2Tx similarly;

3. and a Commit stage: each node counts the commit opinion voting of all the sub-transactions in the whole cross-chain transaction, the node really commits the cross-chain transaction only when all the sub-transactions are counted as commit at the same time, the node0 commits the chain1tx part, the node1-node4 commits the chain1tx and the chain2tx at the same time, and the node5 commits the chain2tx part;

for ease of understanding, the cross-chain flow is illustrated by yet another practical example:

two chains, namely chain1 and chain2, coexist in the network, wherein chain1 comprises A, B, C three nodes and intelligent contract test1(), and chain2 comprises C, D, E three nodes and intelligent contract test2 (). This information is already stored in the system chain and is accessible to all nodes.

(1) The client initiates a transaction with the content of a cross-chain transaction, wherein the transaction comprises calling intelligent contract call test1() on the chain1 and calling intelligent contract call test2() on the chain 2;

(2) the server side receives the message and carries out numbering, splitting and forwarding;

sending { id:1, cmd: 'call test1 ()', chassis: 'chain 1, chain 2' } to A, B, C three nodes

Sending { id:2, cmd: 'call test2 ()', chassis: 'chain 1, chain 2' } to C, D, E three nodes

(3) After the consensus is completed, the consensus result is sent to other chains

For example, chain1 consensus passes, A, B, C node will send the consensus results to C, D, E at the same time.

C. D, E the same process is applied.

(4) C, D, E, if it receives more than 2(>1/2) messages that chain1 has agreed, it is deemed that chain1 has agreed. If chain2 also agrees to pass, the transaction call test2() is eventually committed.

A. B, C nodes work the same.

If both chain1 and chain2 agree, the C node will submit call test1() in turn according to the transaction order; call test2 ().

With reference to fig. 9, it is another example of the above-described execution flow:

in Tx prepare phase, a transaction including two data operations on the Chain is committed to a Node (Node2), after the simulation of the Node2 is executed, a transaction log Chain1Tx log of data 1 on the Chain and a transaction log Chain2Tx log of data 2 on the Chain are obtained, and the transaction logs further include read-write sets after the data operations and the data simulation are executed. In the endorsement and Consensus stage (Endorse & Consenssus), node2 endorses and agrees the transaction log Chain1tx log of data 1 on the Chain with node1, and endorses and agrees the transaction log Chain1tx log of data 2 on the Chain with node 3. In the consensus voting phase (Multi-consensus), the consensus results of all nodes for the transaction are counted, and after the consensus and endorsement are successful, the Commit phase (Tx Commit) is entered, the node2 commits the transaction including the data operations of the chain1 and the chain2, while the node1 commits the transaction of the data operation of the chain1 and the node 3 commits the transaction of the data operation of the chain 2. If the consensus and endorsement fail, node2 rolls back the transaction that includes the chain1 and chain2 data operations that the simulation executes, while node1 rolls back the transaction of the chain1 data operation and node 3 rolls back the transaction of the chain2 data operation.

EXAMPLE five

This embodiment describes the design of the smart contract of the present invention.

The database system in the embodiment of the invention is based on the traditional storage process (stored procedure), and designs and realizes the tamper-proof intelligent contract (smart contract). A group of stored procedures are stored in a database in order to complete SQL statement sets with specific functions, the stored procedures are called after first compiling and do not need to be compiled again, and a user executes the stored procedures by specifying names of the stored procedures and giving parameters. In a traditional distributed database system, a storage process is installed to all nodes in the system synchronously after being installed. However, the transaction calling the storage procedure is not at the "call level" when the replication is performed, that is, the transaction initiating node executes the transaction calling the storage procedure only locally to execute the storage procedure once, and other nodes directly replicate the data updated by the call during the replication instead of executing the same storage procedure again. Such a design would ensure strong consistency of data, but if the contents of the stored process are tampered with or even if the transaction is performed through the agreed stored process, other nodes cannot be aware and distinguish, which gives the malicious node the possibility to tamper with the data by modifying the contents of the stored process. The trusted data management system optimizes the replication process of the storage process, sets the replication of the storage process to be call level, and combines the endorsement process to realize the intelligent contract characteristic: the node executes the intelligent contract locally according to the contract name and the parameters. The specific process is as follows:

(1) the client invokes a transaction to execute the contract:

“call Smart_Contract(arg1,arg2)”

(2) the transaction receiving node of the server side executes an intelligent Contract named Smart _ Contract at local incoming parameters arg1 and arg2 to generate a read-write set S (r, w); then, the intelligent contract name, the parameters and the read-write set are packaged and forwarded to the endorsement node;

(3) and the endorsement node receives the endorsement request and calls the locally stored intelligent contract according to the intelligent contract name and the parameters in the request. If the intelligent contract can be successfully executed locally and generates a read-write set S' (r, w), the result of endorsement is returned by comparing with S (r, w) in the endorsement request.

If the endorsement node fails to execute the intelligent contract in the flow (3), the reason may be that the intelligent contract does not exist or the parameters are not matched, which indicates that the transaction initiating node executes a tampered intelligent contract. If the read sets in the read-write sets are not consistent, the data state before the intelligent contract is executed is tampered, and if the read sets are consistent and the write sets are not consistent, the logic of the intelligent contract is possibly tampered. Through the design in the method, the node can update data through a contracted program segment in an untrusted environment, and meanwhile, the intelligent contract logic is prevented from being tampered in the process.

EXAMPLE six

In this embodiment, the design of rights management in the embodiment of the present invention is described.

The database system of the embodiment of the invention adds the signature information (client signature and endorsement signature) and the verification process in the life cycle of the transaction request, the server can more effectively verify the legality of the user, and the request signature information is stored in the block along with the transaction information, so that the database system has stronger traceability and anti-repudiation. The specific processes of signature adding and signature checking are as follows:

(1) the client logs in by using the certificate, and the server judges whether the client has login authority or not by checking the legality of the certificate;

(2) the client signs the request to be sent using the held certificate. The server side checks the legality of the certificate and the signature and is used for judging whether the user has read-write permission required by data operation, if the user has the read-write permission, the user directly reports an error, otherwise, the signature information of the user is cached for subsequent recording into a block for use;

(3) after the endorsement node simulates and executes the transaction and checks the read-write set, the endorsement node uses the certificate held by the endorsement node to carry out endorsement signature, and the transaction is indicated to pass the endorsement of the node;

(4) and the transaction initiating node checks the endorsement signature, judges the validity of the endorsement signature and judges whether the endorsement strategy is met or not.

After the transaction in the system passes through the complete life cycle, the transaction structure recorded in the block will carry the signature of the initiating node: to prove that the node has the required rights to initiate transaction operation data. And the signature of the endorsement node for the transaction is also carried: the data used to prove that the transaction content and the data before and after execution are being authenticated by the endorsement node. The signature verification flow ensures the effectiveness of transaction execution and the consistency and non-tamper of the system. Once any dispute about the transaction occurs, the responsibility can be confirmed through the signature information, and the system is guaranteed to be resistant to repudiation.

The system realizes the management and the authority control of the table through an authority table: and when the data table is created, an authority record about the data table is added to insert authority table data, and the certificate information of the creator of the data table and the certificate information with read-write authority are recorded. And combining with the signature adding and checking process, when data is read and written in a transaction, the server side firstly verifies whether the certificate of the transaction initiator has corresponding authority, and if not, the transaction fails. The data table creator can modify the read-write permissions.

On the basis of the data table, the system adds a block table and a history table. The authority and insertion and update of the two types of tables are maintained by the system according to the operation of the user data transaction, the operation of the two types of tables is executed by the node local system, the node common identification synchronization on the chain is not needed, the operation is strongly related to the user data transaction, namely all service data of the nodes are kept consistent, and the two types of tables on all the nodes are also kept consistent.

In embodiments of the present invention, two types of chains may be included:

1) system chain of chains: the system chain belongs to a system built-in, and is a whole member participation chain which is used for synchronizing and managing configuration information of users, such as all user chains which coexist in the system, all nodes contained on each transaction chain and endorsement strategies of each user chain, and the information can be used for cross-chain transactions. When a new node needs to join the chain, a certain node in the system initiates a transaction for joining the chain on the system chain, and after all nodes on the system chain are identified together, the node information of the user chain corresponding to the new node to be joined in the system chain can be updated. And if the endorsement strategy is changed, updating the endorsement strategy information by using the same process.

2) user chain: the functions are consistent with the chains in the traditional block chain system, the operation of a user on the data system is recorded by using a chain structure, all nodes maintain the same account book, and the consistency and the non-tampering property of the whole system are ensured. Meanwhile, due to the adoption of the structured storage, great convenience is brought to data tracing, analysis and statistics.

EXAMPLE seven

The method of embodiments of the present invention is set forth above in detail and the apparatus of embodiments of the present invention is provided below.

The first embodiment described above is an example of design of functional modules of a server node of a database system when the technical effect of the present invention is achieved, and specifically, the functional modules may be implemented based on different database systems. That is, each functional module in this embodiment may be implemented by a software module or a hardware module, or by a combination of software and hardware in different system architectures.

As technology advances, designers almost always obtain corresponding hardware circuit structures by programming improved process flows into the hardware circuits. Thus, a method flow may also be implemented in hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Language, HDL, las, software, Hardware Description Language, and so on. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The above embodiments illustrate modules or units, which may be implemented in particular by a computer chip or an entity, or by an article of manufacture having a certain functionality. In the existing blockchain system, there are certain requirements on the computing power and network communication capability of the nodes, and therefore a typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a node, a laptop computer, or the like. However, as technology advances, the computing and communication capabilities of hardware devices continue to increase. Therefore, it is anticipated that in future technical implementation, various hardware devices with computing capability and communication capability may be used as node devices in the blockchain system. For example, a cellular phone, a smart phone, a personal digital assistant, a media player, a vehicle computer, an internet of things device, a navigation device, a gaming device, a tablet computer, a wearable device, or a combination of any of these devices may be one node device in the blockchain system.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, as shown in fig. 7, the node apparatus 70 according to the embodiment of the present invention includes a processor 701, a memory 702, and a transceiver 703, where the processor 701, the memory 702, and the transceiver 703 are connected to each other through a bus.

The Memory 702 includes, but is not limited to, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM), or a portable Read Only Memory (CD-ROM), and the Memory 702 is used for related instructions and data. The transceiver 703 is used for receiving and transmitting data with other node devices or with clients.

The processor 701 may be one or more Central Processing Units (CPUs), and in the case that the processor 701 is one CPU, the CPU may be a single-core CPU or a multi-core CPU.

The processor 701 in the device 70 is configured to read the program code stored in the memory 702 to execute the method steps in the foregoing method embodiments or to implement the various functional modules of the foregoing node embodiments. Therefore, the implementation of each operation of the node device of this embodiment may be described in the foregoing method embodiments.

One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims

1. A data storage method applied to a transaction initiating node in a cluster of database nodes, the method comprising:

acquiring a transaction instruction of a client, wherein the transaction instruction comprises a structured language (SQL) command;

simulating and executing the SQL command, and determining a first world state before simulating and executing the SQL command and a second world state after simulating and executing the SQL command;

sending the SQL command, the first world state and the second world state to an endorsement node;

acquiring an endorsement success instruction of the endorsement node, wherein the endorsement success instruction indicates that the world state of the endorsement node before the SQL command is simulated to be executed is consistent with the first world state, and the world state of the endorsement node after the SQL command is simulated to be executed is consistent with the second world state;

and according to the endorsement success instruction, performing consensus with at least one other node in the database node cluster to indicate the other node to execute the SQL command after the consensus is successful.

2. The method of claim 1, further comprising:

and after the consensus is successful, executing the SQL command.

3. The method according to claim 1 or 2, wherein simulating the execution of the SQL command and determining the first world state before the simulated execution of the SQL command and the second world state after the simulated execution of the SQL command specifically comprise:

and determining a first read-write set for locally executing the SQL command according to the SQL command, wherein the read set of the first read-write set corresponds to the first world state, and the write set of the first read-write set corresponds to the second world state.

4. The method of claim 3, wherein sending the SQL command, the first world state, and the second world state to an endorsement node comprises:

and sending the SQL command and the first read-write set to the endorsement node.

5. The method of claim 2, wherein the executing the SQL command specifically comprises:

and generating a first block according to the SQL command, wherein the first block comprises execution logic and execution results for executing the SQL command, and a hash value of a last block of the first block.

6. The method of claim 5, wherein said executing the SQL command further comprises:

and generating a second block according to the SQL command, wherein the second block comprises an execution result after the SQL command is executed and a hash value of a last block of the second block.

7. The method according to any one of claims 1 to 6, wherein the transaction instruction further includes a signature of the client;

the method further comprises the following steps:

and verifying whether the identity of the client meets a preset condition or not according to the signature of the client.

8. The method of any of claims 1 to 6, further comprising:

generating a signature of the transaction initiating node;

when the SQL command, the first world state, and the second world state are sent to an endorsement node, the method further comprises:

and sending the signature of the transaction node to the endorsement node.

9. The method according to any one of claims 1 to 6, wherein the endorsement success instruction further comprises a signature of the endorsement node;

the method further comprises the following steps:

and verifying whether the identity of the endorsement node meets a preset condition or not according to the signature of the endorsement node.

10. The method of any one of claims 1 to 6, further comprising:

generating a signature of the transaction initiating node;

and according to the endorsement success instruction, when the endorsement success instruction is identified with at least one other node in the database node cluster, sending the signature of the transaction initiating node to the other node.

11. A transaction endorsement method applied to an endorsement node in a cluster of database nodes, the method comprising:

acquiring an SQL command sent by a transaction initiating node, a first world state and a second world state, wherein the first world state is the world state before the transaction initiating node simulates and executes the SQL command, and the second world state is the world state after the transaction initiating node simulates and executes the SQL command;

simulating and executing the SQL command, and determining a third world state before the endorsement node simulates and executes the SQL command and a fourth world state after the SQL command is simulated and executed;

and if the first world state is consistent with the third world state and the second world state is consistent with the fourth world state, sending an endorsement success instruction to the transaction initiating node.

12. The method of claim 11, wherein the obtaining the SQL commands sent by the transaction initiation node, the first world state and the second world state specifically comprise:

and acquiring an SQL command and a first read-write set sent by a transaction initiating node, wherein the read set of the first read-write set corresponds to the first world state, and the write set of the first read-write set corresponds to the second world state.

13. The method according to claim 11 or 12, characterized in that the method further comprises:

acquiring a SQL command sent by a transaction initiating node, and acquiring a signature of the transaction initiating node when in a first world state and a second world state; and

and verifying whether the identity of the transaction initiating node meets a preset condition or not according to the signature of the transaction initiating node.

14. The method according to claim 11 or 12, characterized in that the method further comprises:

generating a signature of the endorsement node;

and when an endorsement success command is sent to the transaction initiating node, sending the signature of the endorsement node.

15. A data storage node, characterized in that it comprises at least one functional module for implementing the method as claimed in claims 1-10.

16. A data storage node, characterized in that it comprises at least one functional module for implementing the method as claimed in claims 11-14.

17. A data storage node, wherein the blockchain node comprises a processor and a memory,

the memory stores executable program instructions;

the processor reads the executable program instructions in the memory to perform the method of any one of claims 1-10.

18. A data storage node, wherein the blockchain node comprises a processor and a memory,

the memory stores executable program instructions;

the processor reads the executable program instructions in the memory to perform the method of any one of claims 11-14.

19. A blockchain system comprising a node according to any of the claims 15-18.