A database system, node and method

Abstract

The present invention provides a transaction method and node design for a database system. When a transaction in a database involves on-chain and off-chain data operations, or multiple on-chain data operations, the transaction initiating node endorses and performs consensus operations on the on-chain data with the nodes of each data chain. When all on-chain data pass the endorsement and consensus process, the transaction is submitted, thereby ensuring the atomicity of transactions in the database.

Description

Technical Field

[0001] The present invention relates to database technology, and in particular to a database design based on blockchain technology. Background Art

[0002] Blockchain is a chain data structure that combines data blocks in a sequential manner, and is a distributed ledger that is cryptographically guaranteed to be tamper-proof and unforgeable. Based on a decentralized protocol, blockchain builds a distributed structure system that allows information on value exchange to be sent to the entire network through distributed communication, determines the content of information data through distributed accounting, generates block data after timestamping, and then sends it to each node through distributed communication to achieve distributed storage.

[0003] Smart contracts are a new feature that has emerged with the development of blockchain technology. Smart contracts are essentially coded instances of contracts between two parties to a transaction. They respond to received information according to the provisions of the contract between the two parties. They can receive and store value, as well as output information and value. They act as a trusted system that always performs operations according to pre-agreed rules.

[0004] A relational database is a database built on the basis of a relational model. It uses mathematical concepts and methods such as set algebra to process data in the database. Currently, the business relationships of most business systems can be defined using the relational database model. The standard data query language SQL is a language based on relational databases. This language can be used to retrieve and operate data in the database.

[0005] Based on the existing blockchain solution, it is impossible to realize the data management capabilities in relational databases, nor can it realize data transaction operations. Therefore, it is difficult to meet the data management needs of large data systems. Summary of the invention

[0006] The embodiment of the present invention provides a database system, including a transaction method and a node, which enables users to change the way they use traditional blockchains to database usage while maintaining the original way they use relational databases, and integrate the two into one system, which uniformly and collaboratively manages the two pieces of data. The database system of the present invention is compatible with most of the features in relational databases, including SQL support, relational structure storage, ACID transaction guarantees, etc. At the same time, more blockchain features are added, and the blockchain has anti-tampering features, including anti-tampering Byzantine consensus protocols, transaction blockchains, smart contracts and other features.

[0007] In the first aspect, the present invention provides a method for data storage: after receiving the request sent by the client, the request receiving node directly simulates the execution on the local state machine to generate a simulated execution result, and packages the simulated execution result with the user execution logic, and copies it to other nodes for anti-tampering verification; after receiving the message package, other nodes in the network take out the user execution logic from it and execute it locally to generate a simulated execution result, and then compare the simulated execution results in the message package; if the two results are inconsistent, it means that data tampering has occurred, and a verification failure is replied to the initiating node; if the two results are consistent, a verification success is replied to the initiating node; after the verification initiating node receives enough verification replies, it summarizes and judges, and the requests that are judged to have failed the verification are directly discarded, and the requests that are judged to have succeeded the verification are subjected to the pbft consensus replication logic with the simulated execution result set until the state replication ends or fails.

[0008] Compared with the existing technology, anti-tampering verification logic is added before consensus, and the verified simulation execution results are used for replication, which not only achieves anti-tampering design but also maintains the consistency of the state.

[0009] In the second aspect, the present invention provides a transaction processing method including on-chain and off-chain data: the client initiates an on-chain and off-chain transaction operation, and the transaction includes both an on-chain data update operation set and an off-chain data update operation set; after receiving the request, the server-side transaction request receiving node starts a transaction manager, processes it according to the operation sequence in the transaction request, pre-submits the transaction, generates two transaction processing logic log caches, and adds the transaction log generated by the on-chain transaction to the on-chain transaction cache pool at the same time, and the transaction log includes the transaction execution logic; the endorsement process is initiated with the transaction log generated by the on-chain transaction, and if the endorsement process is successful, the request receiving node starts a consensus process. If the consensus process is successful, the request receiving node will actually submit the pre-submission generated by the on-chain transaction and the off-chain transaction, and other nodes have only received the on-chain transaction, so only the on-chain transaction is submitted. At this point, the request receiving node has completed the on-chain and off-chain transaction operations.

[0010] Compared with the prior art, the present invention ensures the atomicity of transactions, so that the on-chain data and off-chain data of the same transaction can be updated based on the transaction processing logic.

[0011] In the third aspect, the embodiment of the present invention provides a transaction processing method including data on multiple chains: when the client sends a transaction, it is necessary to mark the transaction as involving a cross-chain and indicate which chain each transaction in the cross-chain transaction belongs to. When the server receives the cross-chain transaction request from the client, it first numbers the transactions in the transaction in sequence and splits all the transactions in the transaction according to the chain to which they belong. Each chain executes the endorsement process of the transaction involved in the chain, which is the single-chain endorsement process. The transaction initiating node on the server summarizes the collected endorsement results. For cross-chain transactions, when the endorsement results of all split transactions in the transaction meet the endorsement policy of the chain, the endorsement is deemed to be successful. After the endorsement is successful, the request splitting result, each transaction number, and the chains involved in the cross-chain transaction are packaged and copied to the nodes of the corresponding chain, and enter the consensus module of the system for consensus. Each chain independently performs the consensus process, which is the single-chain consensus process. Each transaction number and the chains involved in the cross-chain transaction need to be part of the transaction information, and all subsequent message copies must be accompanied by these two pieces of information. In the submission phase, after the current chain consensus is completed, it enters the waiting state, reads all the nodes of the chain involved in the cross-chain transaction, and sends the consensus results of the chain to these nodes. Similarly, the chain will also receive the consensus results of all other chains. When more than 50% of the nodes of a chain have passed the consensus feedback, it is considered that the consensus of this chain has passed. If all chains involved in the transaction have passed the consensus, it means that the cross-chain consensus has passed. If a node contains multiple chains, each transaction needs to be submitted in sequence according to the transaction number. The nodes on the chain only submit transactions related to the chain in the transaction. If the node joins multiple chains involved in the cross-chain transaction, the transactions related to the chain are submitted separately on different chains according to the transaction sequence number.

[0012] In some implementations, the method also configures a system chain that can be accessed by all nodes in the network and is used to record the member information of all chains in the network. When a new chain is created in the network, a record is added to the system chain; when a new node joins the chain, the creator of the chain updates the member information of the chain and synchronizes it to the entire system.

[0013] Compared with the prior art, the embodiments of the present invention ensure the atomicity of transactions, and multiple on-chain data of the same transaction are updated based on transaction processing logic.

[0014] In a fourth aspect, this embodiment further provides a data node, which includes a plurality of functional modules. Through the multifunctional modules, the node can implement the functions described in the first, second and third aspects above.

[0015] In a fifth aspect, an embodiment of the present invention further provides a computer system, which serves as a node in a database system. The computer system includes at least one processor and a memory, wherein the memory is used to store a software program, and when the software program is executed by the processor, the processor of the computer system is used to execute the method of the first, second, and third aspects or any one of the implementations.

[0016] In a sixth aspect, an embodiment of the present invention further provides a storage medium for storing a computer program, and when the computer program is executed by a processor, the processor is used to implement any one of the methods provided in the first, second, and third aspects. Specifically, the computer program may include one or more program units for implementing each step of the method.

[0017] It can be seen that the embodiments of the present invention provide a blockchain system transaction method and node. The integration of data management and anti-tampering mechanism in the database system is realized, and the cost of deployment, management and operation is reduced. At the same time, a system can support the transaction processing capabilities of multiple on-chain data and off-chain data, which improves the task coordination efficiency of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the background technology, the drawings required for use in the embodiments of the present invention or the background technology will be described below.

[0019] Figure 1 is a system architecture diagram of a database system provided by an embodiment of the present invention;

[0020] Figure 2 It is a schematic diagram of a storage structure of a database provided by an embodiment of the present invention;

[0021] Figure 3 is a flow chart of a data storage method of a database system provided by an embodiment of the present invention;

[0022] Figure 4 is a flowchart of another data storage method of a database system provided by an embodiment of the present invention;

[0023] Figure 5 is a flowchart of another data storage method of a database system provided by an embodiment of the present invention;

[0024] Figure 6 It is a schematic diagram of a process of performing transaction operations on on-chain and off-chain data in a database system provided by an embodiment of the present invention;

[0025] Figure 7 is a flowchart of another data storage method of a database system provided by an embodiment of the present invention;

[0026] Figure 8 It is a flowchart of endorsement and consensus of cross-chain transactions in another database system provided by an embodiment of the present invention;

[0027] Fig. 9 It is a schematic diagram of a process of performing transaction operations on cross-chain data in a database system provided by an embodiment of the present invention;

[0028] Fig.10 It is a schematic diagram of the hardware architecture of a node in a database system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The embodiments of the present invention are described below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0030] First, some concepts in the blockchain network architecture are introduced.

[0031] Client: Users can use the client in the blockchain system to create chain codes, initiate transactions, and other functions. The client can be deployed on any terminal and implemented through the corresponding SDK (Software Development Kit) of the blockchain system. The terminal communicates with the nodes in the blockchain network to implement the corresponding functions of the client.

[0032] Block: In blockchain technology, data is permanently stored in the form of electronic records. The files that store these electronic records are called "blocks". Blocks are generated one by one in chronological order. Each block records all the value exchange activities that occurred during its creation. All blocks are aggregated to form a chain of records.

[0033] Block Structure: The block records the transaction data within the block generation period. The block body is actually a collection of transaction information. The structural design of each blockchain may not be exactly the same, but the general structure is divided into two parts: the header and the body. The header is used to link to the previous block and provide integrity assurance for the blockchain database, while the body contains all verified records of value exchanges that occurred during the block creation process.

[0034] Peer: In the blockchain network, a distributed network system is constructed, so that all data in the database are updated in real time and stored in all network nodes participating in the record. At the same time, the blockchain network builds a complete set of protocol mechanisms, so that every node in the entire network can verify the correctness of the record results of other nodes while participating in the record. Only when the qualified nodes (such as all nodes, most nodes or specific nodes) simultaneously believe that the record is correct through the protocol mechanism, or when all nodes participating in the record have passed the comparison results, the authenticity of the record can be recognized by the entire network, and the record data is allowed to be written into the block. Therefore, in the blockchain network, all nodes together constitute a decentralized distributed database.

[0035] In different blockchain systems, in addition to storing block data, there are also some special nodes. For example, endorsement nodes and sorting nodes. Among them, endorsement nodes are used to execute smart contract state machines and simulate transaction execution. Endorsement nodes contain pre-specified endorsement policy sets. These endorsement policy sets install specific chain codes. All transactions must be conducted in accordance with the endorsement policy, because only transactions that have been endorsed are legal and recognized transactions. In the specific implementation, after receiving the transaction request from the client, the endorsement node executes a simulated transaction and generates an endorsement signature based on the result of the simulated transaction, thereby completing the endorsement of the transaction.

[0036] Relational Database (RDB): RDB database is a database based on the relational model, also called a relational database. In a computer, a relational database is a collection of data and database objects. The so-called database objects refer to tables, views, stored procedures, triggers, etc. The computer software that manages relational databases is the relational database management system (RDBMS). A relational database is composed of data tables and the relationships between them. In a relational database, table association is a very important component. Table association refers to the connection between data tables in the database using corresponding fields.

[0037] The business relationships of most business systems can be defined using the model of a relational database. Structured Query Language (SQL) is a language based on a relational database that can be used to retrieve and operate data in a database. Currently, many business systems have some demand for blockchain ledgers, such as supply chain item tracking ledgers, multi-party order ledgers in e-commerce platforms, etc., which require the anti-tampering and non-repudiation characteristics of blockchain technology to support their operation. Data that can be defined as such ledger data can be called on-chain data. At the same time, on-chain data will also have some strong correlations with other data in the original business (also called off-chain data), and usually it is necessary to maintain consistency and atomicity between them. However, simply splitting some data of the business system onto the blockchain to obtain the advantages brought by the blockchain ledger will make the joint management of on-chain data and off-chain data more difficult.

[0038] Relational database systems focus more on consistency, high availability, and high performance, while blockchain systems focus more on immutability, decentralization, and security. Based on the characteristics of both, the industry has seen the emergence of some system prototypes that integrate database technology with blockchain technology, such as BigChainDB, ChainSQL, and Catena. These prototypes all have the characteristics of decentralization, tamper-proofing, and Byzantine fault tolerance, which reflect the characteristics of blockchain, but there are significant differences in data management capabilities: 1) BigChainDB does not support SQL access, only supports KV type data structures, and does not support transactions; (2) ChainSQL synchronizes the unstructured data of the blockchain to a structured external database, supports limited SQL access, and does not support transactions because the state is stored in a newly added external database system, which also increases consistency maintenance issues; (3) Catena can be considered as a lightweight SQL support module added to the traditional public chain system. The SQL support capability is very limited and does not support transactions. Since the consensus is a non-deterministic algorithm, it is very far from the ACID transaction guarantee.

[0039] In this invention, the data management capabilities of traditional relational databases are combined with the trusted anti-tampering capabilities of blockchain technology, and are output through a general SQL interface. A system is implemented to solve users' demands for data management and anti-tampering, thereby reducing deployment, management, and operation and maintenance costs and shortening the learning curve. A system can support multi-chain and off-chain data storage without the need for third-party tool synchronization, directly providing on-chain and off-chain transactions and cross-chain transaction operations, and high collaborative analysis efficiency.

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

[0041] Endorsement consensus mechanism:

[0042] At present, some mainstream strong consistency distributed database systems mainly build state replication mechanisms between nodes based on non-Byzantine fault-tolerant consensus protocols similar to Paxos. The replication content of this type of mechanism can be: a) the execution result state set of a single node; b) request execution logic;

[0043] In type a, one of the nodes first simulates and executes the user request logic, obtains the simulated execution result, and then replicates the simulated execution result for consistency. After consistency is achieved, each participating node directly uses the simulated execution result to update its own status. This type of method is relatively easy to maintain the consistency of the cluster status, such as MySQL's row-based binlog and Zookeeper's CRUD operation log. This type of method is more like using the status of a single node to update the status of the entire cluster. If the simulated execution node is tampered with, the overall cluster status will be disordered.

[0044] Type b copies the original user execution logic to the entire cluster nodes, and then executes it separately on each node and updates its own status. This type is conducive to each node to independently maintain its own status and is more favorable for tampering. For example, there is MySQL's statement-based binlog. However, this type focuses on the replication process. In some implementations, the process may be random, such as random() logic, so execution on different nodes may cause inconsistency.

[0045] It can be seen from the above that simply using a and b cannot achieve the purpose of tamper-proofing and consistency at the same time. The database system of the embodiment of the present invention proposes an anti-tampering replication mechanism: (1) After receiving the request sent by the client, the request receiving node directly simulates the execution on the local state machine to generate a simulated execution result, and packages this simulated execution result with the user execution logic, and copies it to other nodes for anti-tampering verification; (2) After receiving the message packet, other nodes in the network extract the user execution logic from it and execute it locally to generate a simulated execution result, and then compare the simulated execution result in the message packet; (3) If the two results are inconsistent, it means that data tampering has occurred, and a verification failure is replied to the initiating node; if the two results are consistent, a verification success is replied to the initiating node; (4) After the verification initiating node receives enough verification replies, it summarizes and judges that the request that fails the verification is directly discarded, and the request that succeeds the verification is subjected to the pbft consensus replication logic with the simulated execution result set until the state replication ends or fails.

[0046] Compared with a traditional state replicator, the database system of the embodiment of the present invention adds tamper-proof verification logic before consensus, and uses verified simulation execution results for replication, which not only achieves tamper-proof design but also maintains state consistency.

[0047] Transactional blockchain:

[0048] The blockchain system can ensure the immutability of historical transactions through a chain structure. The current relational database only saves historical operation logs in files for data recovery and other tasks, but the log files cannot be guaranteed to be tampered with. To this end, the database system of the embodiment of the present invention uses the log content of the transaction to build blocks and assemble them into chains. In addition to all the submitted transactions of the transaction, the block also contains additional content such as block number, parent block hash value, transaction number, timestamp, various signature information, etc. Like the blockchain system, the linked table of the database system of the embodiment of the present invention ensures immutability through the parent block hash. At the same time, the request initiator information can be traced back through the transaction signature, and the endorsement approval node information can be traced back through the endorsement signature.

[0049] Smart Contracts:

[0050] As the most critical feature of blockchain extending from a single digital currency function to various fields, smart contracts ensure that each node can execute the same business logic. In relational databases, stored procedures already contain similar functions, but traditional relational databases are run in a relatively trusted environment, so the process design of stored procedures is still based on single-point execution and multi-point replication, so it is not tamper-proof. The database system of the embodiment of the present invention combines the design features of the stored procedure and expands it into a smart contract feature with tamper-proof properties. When the message is copied, the call command and the execution result will be packaged and copied to all nodes for tamper-proof verification first. Only the call that passes the verification will continue the subsequent steps. At the same time, the database system of the embodiment of the present invention supports multiple chains. One smart contract corresponds to one chain and is only installed on the node of the corresponding chain. When the chain is deleted, the smart contract on it is also cleared together. All operations on the chain data update in the system can only be completed through smart contract calls.

[0051] Permission management:

[0052] The authority management is mainly established for the multiple blockchains supported by the system in this article. The chain structure in the database system of the embodiment of the present invention in this article is divided into two categories: System Chain and Data Chain. The System Chain is a system chain, which is used for the storage and management of the metadata of the entire cluster data chain; the Data Chain is a data chain, which is used for user data reading and writing, and is initiated by the user. For the convenience of description, a participating node of a Data Chain is described here as a MemberNode of this chain, otherwise it is called a non-Member Node of this chain.

[0053] (1) Data Chain access control. Considering better data isolation and privacy protection, the access control of DataChain is only reserved for the participating nodes in the chain. If a node wants to access the data of other nodes maintaining the chain, it must access the Member Node.

[0054] (2) System Chain access control. System Chain is the metadata storage chain of the entire system. It is invisible to external users and only allows cluster member nodes to access it through system requests. First, all member nodes in the entire cluster reach a consensus through voting to complete the construction of this chain and store the configuration information of all members in this chain. This information is written once when the System Chain is built, and only reading is allowed later. No modification or appending is allowed. Secondly, when a Data Chain is created, its Member Node writes the metadata of this Data Chain to the System Chain. The System Chain verifies whether the writer is one of the Memebr Nodes of the Data Chain.

[0055] On-chain transactions and off-chain transactions:

[0056] In existing blockchain systems, data is stored in ledgers and can be accessed by all nodes, and data privacy cannot be guaranteed. For business scenarios that require data privacy (such as financial systems), only part of the private data can be stored off-chain, and the remaining public data can be put on-chain. An additional system is required to maintain the consistency of the association between the two parts of data. In the database system of the embodiment of the present invention, in order to more effectively isolate data, a chain is defined at the DB granularity, and each blockchain is maintained as a partitioned channel. At the same time, the entire cluster alliance can maintain multiple channels, and each node instance can support two data storage types at the same time:

[0057] a) On-Chain: On-chain DB, i.e. on-chain blockchain, stores on-chain data shared by nodes. All nodes participate in maintenance. Each chain is collectively referred to as a channel. Every time a DB is created, the system creates a channel based on the DB name. Each channel is maintained by consensus of all alliance member nodes.

[0058] b) Off-Chain: Off-chain DB, i.e. off-chain local library, stores private off-chain data of this node and is only maintained by the creating node;

[0059] The entire cluster alliance supports the coexistence of multiple blockchains and off-chain and off-chain coexistence. All member nodes maintain a built-in system chain to manage all user data chain information.

[0060] Based on the above multi-chain design, the embodiment of the present invention provides an integrated solution for multi-type data management, and provides features for transactional support between them:

[0061] 1) On-chain cross-chain transactions: ensure the atomicity of batch operations on multiple chain data in one transaction, that is, either all chain updates are successful or all chain updates fail;

[0062] 2) On-chain and off-chain transactions: ensure the atomicity of batch operations on on-chain and off-chain data in a transaction, that is, either all on-chain updates and included off-chain updates are successful, or all fail;

[0063] The following is a detailed introduction to on-chain cross-chain transactions

[0064] When a node in the database system of an embodiment of the present invention receives a user request that includes multiple on-chain data update operations, the node generates a cross-chain transaction for processing.

[0065] When a cross-chain transaction is generated, the server node generates a transaction log in the Prepare phase of the transaction, and splits it into single-chain parts according to the chain granularity. Then, the member nodes of each chain are found through the system chain, and the single-chain parts are used to perform endorsement consensus respectively. The commit information of each chain consensus needs to be broadcast to all participating nodes. All participating nodes obtain the results of all chain consensus and make statistics. Only when all chain consensuses are completed can the transaction part of the chain maintained by this node be submitted, which ultimately ensures that all chain updates are either fully successful or fully failed for the entire cluster.

[0066] The following is a detailed introduction to cross-chain transactions on and off the chain

[0067] When a node in the database system of an embodiment of the present invention receives a user request that includes both on-chain and off-chain update operations, the node will generate an on-chain and off-chain transaction for processing.

[0068] After the on-chain and off-chain transactions are generated, the server node processes them according to the transaction processing flow mentioned above. At the same time, during the Prepare phase of the transaction, the generated transaction log is divided into two parts: (1) the on-chain part; (2) the off-chain part. The update operation log for the on-chain data only exists in the on-chain part.

[0069] When performing the endorsement consensus process, the node only uses the on-chain part (1) in the transaction log. After the endorsement consensus process is passed, (1) and (2) are submitted at one time. If they fail, both are rolled back, ultimately achieving atomic operations on and off the chain.

[0070] Embodiment 1

[0071] Combine the following Figure 1 , a system architecture diagram of a database system according to an embodiment of the present invention is introduced. As shown in the figure, the database system according to the embodiment of the present invention can be divided into a client 110 side and a server 120 side. The client 110 includes multiple clients 110a, 110b, 110c...110n, and the server 120 includes multiple servers 120a, 120b, 120c...120n. The server node can be an independent physical server or a virtual machine node.

[0072] Each client (110a, 110b, 110c...110n) in the client 110 has an application 111, an SDK / API module 112 and a signature module 113. The SDK / API module 112 is responsible for supporting the database connection API, so that the database system supports other business systems. The signature module 113 completes the login and request signature verification through the certificate issued by Triangle CA; 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 supporting certificate to the request information. After receiving the login request message from the client 110, the server 120 will continue the handshake flow only after the verification is completed, otherwise the login fails.

[0073] Each node (120a, 120b, 120c...120n) in the server 120 includes the following modules:

[0074] CA module 121: Mainly used for system authority management, refer to CA verification scheme. First, generate a root certificate and the corresponding private key, and then use the root certificate private key to issue a common certificate and the corresponding private key. The root certificate private key storage and certificate issuance work must be completed through negotiation by all alliance members. Each server contains a root certificate, which acts as the central verification agency of the CA. All messages in the network must be attached with signature information and supporting certificates.

[0075] Security module 122: used to verify the signature in the endorsement request and add the endorsement result signature after the endorsement is successful. During the transaction endorsement phase, other service nodes also perform verification operations after receiving the copied message, and then execute the endorsement process after passing. After the endorsement is completed, when returning the endorsement result, it is also necessary to use the server private key to sign the endorsement result, and then attach the signature and supporting certificate to the endorsement result. During the consensus phase, when collecting the endorsement results of each node, verification work is also required. Only the results that pass the verification will be regarded as valid endorsement information.

[0076] SQL parsing module 123: used to parse the SQL request from the client, parse the SQL statement in the request according to the SQL grammar rules, and convert the text into an abstract syntax tree.

[0077] Smart contract module 124: used to manage smart contracts installed by users.

[0078] Endorsement consensus module 125: responsible for the endorsement and consistent replication of transaction requests by nodes, and has Byzantine fault tolerance. Compared with traditional state replicators, the database system of the embodiment of the present invention adds anti-tampering verification logic in the consensus module: 1) After receiving the request sent by the client, the request receiving node directly simulates the execution on the local state machine to generate a simulated execution result, and packages this simulated execution result with the user execution logic, and copies it to other nodes for anti-tampering verification; (2) After receiving the message packet, other nodes in the network extract the user execution logic from it and execute it locally to generate a simulated execution result, and then compare the simulated execution result in the message packet; (3) If the two results are inconsistent, it means that data tampering has occurred, and the verification failure is replied to the initiating node; if the two results are consistent, the verification success is replied to the initiating node; (4) After the verification initiating node receives enough verification replies, it summarizes and judges that the request that fails the verification is directly discarded, and the request that succeeds the verification is subjected to the PBFT consensus replication logic with the simulated execution result set until the state replication ends or fails;

[0079] The storage engine module 126 is mainly used for data storage. The data is mainly divided into three categories: system chain data, user chain data and user private data. The specific data storage forms are as follows:

[0080] System chain data: The system chain DB is configured when the system is established to store the meta information of all chains in the system. The DB contains two types of tables: 1. System member table: The table contains all the node information, node ID, IP address and status information in the system (the node may not belong to the same chain); 2. Chain member table: A configuration table is created for each chain, and the table name is consistent with the chain name, such as: chain1. This type of table contains all the node IDs, IP addresses, certificates, endorsement node flags and status information (online, offline, error) on the chain. When a user joins the system or joins the chain, a transaction is initiated to update the system member table or chain member table. In the process of a user creating a chain, the system creates a configuration table for this chain according to the chain created by the user, and inserts the member node information of this chain. The system data chain is backed up on all nodes, can be accessed and maintained by all nodes, and the configuration information can be used to configure endorsement strategies and cross-chain transactions;

[0081] User chain data: contains 3 parts, 1) User chain data: This part of data is the real user business data in the system. If a node joins multiple chains, the user data on each chain corresponds to a DB, and the data between chains are isolated by DB. Nodes on the same chain jointly maintain the user data on this chain, and nodes not on the chain do not have a backup of this part of the data. Modifications to user chain data will be accounted for in the corresponding block table and history table; 2) Historical snapshot chain data used to trace transaction updates and 3) blockchain data of the chain. User chain data is stored in the system's blockchain DB. Each chain contains a block table (named ${chain_name}_blockchain) and multiple history tables (each history table corresponds to a table in the user chain data DB, named ${chain_name}_${table_name}_chain). If a node joins multiple chains, multiple copies of user chain data are maintained locally. This part of the data is only backed up on the nodes contained in the chain, and other nodes that have not joined this chain cannot access or operate this part of the data;

[0082] User off-chain data: This part of data belongs to the private data of the node and exists only on this node. If the transaction initiated by the node involves operating the user's off-chain data, the system will filter this part of the content and only synchronize and copy the part of the on-chain data in the transaction. At the same time, modifying this part of the data will not generate historical records and new blocks, and it will only take effect locally on the node.

[0083] refer to Figure 2, is an example of multiple chains coexisting in a server cluster. Node 1, Node 2, and Node 3 jointly maintain a system chain. Node 1 and Node 2 jointly maintain the data on Data Chain 1, while Node 2 and Node 3 jointly maintain the data on Data Chain 2. At the same time, Node 1 and Node 3 each maintain their own off-chain data.

[0084] The entire cluster alliance supports the coexistence of multiple blockchains and off-chain and off-chain coexistence. All member nodes maintain a built-in system chain to manage all user data chain information.

[0085] Transaction block engine 127: responsible for the generation of blocks corresponding to transaction requests, maintaining the update of the entire blockchain data, and ensuring the distributed transaction characteristics of the request among nodes.

[0086] In this embodiment, data storage is performed through a chain structure, as follows:

[0087] Transaction chain:

[0088] In the database system of the embodiment of the present invention, each channel has a transaction chain for storing transaction logs, so that the system has tamper-proof capabilities. When a channel is created, a corresponding transaction chain is automatically created, and the chain is still stored in a table in a relational structure. The block table structure information is: block number, parent block hash, transaction initiation timestamp, client signature, signatures of all endorsement nodes, transaction content, and execution results.

[0089] After consensus is completed, the transaction logs completed by consensus are packaged into blocks, with each transaction as a block. First, the transaction log is parsed to read the client transaction initiation time, transaction request, endorsed execution result, client signature, signature of each endorsement node and other information. Then the content of the previous block in the chain structure is read. First, the block number of the previous block plus one is taken as the block number of this block, and then the hash of the entire block is calculated as the hash value of the parent block. All the above contents constitute the block of the current transaction according to the transaction block table structure. The chain structure is formed by each block containing the hash of the parent block.

[0090] After the block is generated, it is directly inserted into the transaction list. Because the transaction log is the result of the consensus of all nodes in the chain, that is, the transaction log is guaranteed to be the same, so the block content of each node can be guaranteed to be consistent. If the data is tampered with, the parent block hash cannot be verified.

[0091] Historical snapshot chain:

[0092] The current relational database does not support the function of directly querying historical information, and it is impossible to quickly perform analysis and statistics through SQL syntax. In the database system of an embodiment of the present invention, a historical snapshot chain is designed separately for each data table to save all historical states of the table. The historical snapshot chain is also saved in the table according to the relational structure. When the user creates a data table, a corresponding historical snapshot chain table is automatically created. The table structure information: all columns of the corresponding data table, block number, transaction number, and hash value of the previous record. The table will be created when the user creates the data table. Similarly, the historical snapshot chain is stored using a relational table, and each transaction is a record.

[0093] Each transaction of a transaction will generate a record in the corresponding historical snapshot chain as a block of the historical block chain. This block and the transaction chain block are generated at the same time. When the transaction chain parses the transaction log, it will parse the execution result and sort it out by transaction and split. For each transaction, read the data table of the operation, the modification content, the transaction type and other information. The transactions involved in each table are numbered separately as the transaction number. Each transaction takes the hash value of the parent block and the block number of the transaction. All the above information is organized into blocks according to the historical snapshot chain, and the chain structure is also formed by the hash value of the parent block.

[0094] When you need to query the historical status information of a certain data for analysis and statistics, you only need to use SQL syntax to query the corresponding historical table. Transaction chain and historical snapshot chain can prevent historical data from being tampered with.

[0095] In one embodiment of the present invention, Figure 3 As shown, the basic granularity of the processing flow of the embodiment of the present invention is a transaction. A transaction includes several smart contracts and several ordinary SQL calls. The main processing flow of the transaction is shown in the figure below. The interaction flow of each module in the above server 120 is as follows:

[0096] S301, the client initiates a transaction, and the SQL parsing 123 module parses the request to determine whether it is a transaction to call a smart contract. If so, the smart contract installed by the user is called from the smart contract module for execution;

[0097] S302, the transaction is first executed locally at the initiating node to generate a read-write set, and the security module 122 of the node signs the transaction, and then packages the transaction request command, the local read-write set and the node signature;

[0098] S303: After the transaction is ready, it enters the endorsement consensus module 125. First, the endorsement process (endorse) is performed to verify that the world state before the transaction is executed and the execution logic of the transaction request command have not been tampered with, and the world state after executing the same command remains consistent. The endorsement is considered successful, and then the PBFT consensus replication process is entered;

[0099] S304. After the transaction is replicated by the node consensus, the transaction block engine 127 of the node packages it into a block and generates a historical record of the historical snapshot chain according to the transaction content;

[0100] S305. The storage engine module 126 writes the transaction to the disk, updates the world state, and persists the block and history chain records to the disk.

[0101] Embodiment 2

[0102] refer to Figure 4 is a flow chart of an embodiment of the present invention, which can be applied in Figure 1 In the database system shown, it can also be based on other system architectures that conform to the design ideas of the present invention. The process method describes how the transaction request of the client generates transaction data in the server and saves it in the database of the data node in the database system of this embodiment. In this embodiment, in combination with different specific implementation methods, different node roles may be implemented by the same node or by different nodes. For example, in some implementations, the node that executes the endorsement process and the node that stores data are the same node, that is, the same node can realize the function of both the endorsement node and the data node; for example, in some implementations, some data nodes do not serve as endorsement nodes, that is, such nodes only have the function of data nodes but not the function of endorsement nodes.

[0103] The method of this embodiment includes:

[0104] S401, the client initiates a transaction instruction to the node.

[0105] In one implementation, the client is deployed on a terminal separate from the node. After the user performs a transaction through the client, the terminal sends a transaction instruction to the node, and the node executes the transaction instruction through the network. In another implementation, the client is deployed on the node. After the user performs a transaction through the client, the node can directly obtain the transaction instruction generated by the transaction operation.

[0106] The transaction instructions generated by the client include transaction execution logic in the form of SQL statements such as DML and DDL. For example, the request content creates a record of basic information of a student:

[0107] INSERT INTO student('name','age','id')VALUES('Alice','20','001');

[0108] In the above SQL command, the client's transaction instruction instructs to write into the table storing the transaction information and write the corresponding value into its table item.

[0109] In some implementations, the transaction instruction also includes signature information proving the legal identity of the client. The node can verify the signature information through the aforementioned security module to determine the identity of the client corresponding to the transaction instruction.

[0110] S402, the transaction initiating node receives the transaction instruction sent by the client, parses and locally executes the SQL statement in the transaction instruction.

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

[0112] The transaction initiation 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 grammar rules, and converts the text into an abstract syntax tree. Based on the parsed SQL statement, the transaction initiation node 120a executes the SQL statement locally, thereby generating a read-write set S(r,w) based on the local world state. The read set and the write set correspond to the world state before and after the execution of this transaction, respectively.

[0113] In some implementations, since the transaction instruction also includes signature information that proves the legal identity of the client, the transaction initiating node will first verify the signature information after receiving the transaction instruction, and only execute the SQL statement in the transaction instruction locally after determining the legitimacy of the user's identity based on the verification result.

[0114] In some implementations, after the transaction initiating node successfully executes the transaction locally, it will sign the transaction, thereby generating signature information of the transaction initiating node.

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

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

[0117] Different from the blockchain system, in this embodiment, when initiating an endorsement operation, the transaction initiating node not only sends the SQL instruction containing the transaction execution logic to the endorsing node, but also sends the read-write set S(r,w) indicating the world state before and after the transaction initiating node executes the SQL instruction locally to the endorsing node. It can be understood that in different implementations, the aforementioned SQL instruction and the read-write set S(r,w) can be sent to the endorsing node through the same message or the same communication process, or can be sent to the endorsing node through different messages or communication processes.

[0118] In some implementations, after the transaction initiating node successfully executes the transaction locally, it will sign the transaction, thereby generating signature information for verifying the legal identity of the node. When endorsing, the transaction initiating node will also send the signature information to the endorsing node.

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

[0120] The endorsement node executes the SQL statement locally, parses the SQL statement according to the SQL syntax rules, and converts the text into an abstract syntax tree. Based on the parsed SQL statement, node 120a executes the SQL statement locally, thereby generating a read-write set S'(r,w) based on the local world state. The read set and write set correspond to the world state before and after the execution of this transaction, respectively.

[0121] In some implementations, since the transaction instruction also includes signature information that proves the legal identity of the client, the endorsement node will first verify the signature information after receiving the transaction instruction, and only execute the SQL statement in the transaction instruction locally after determining the legitimacy of the user identity based on the verification result. In some implementations, since the transaction initiating node will send the signature information with the identity of the transaction initiating node to the endorsement node, the endorsement node will first verify the signature information, and only execute the SQL statement in the transaction instruction locally after determining the legitimacy of the transaction initiating node based on the verification result.

[0122] S405, the endorsing node compares and verifies the read-write set S'(r, w) of the locally executed transaction with the read-write set S(r, w) sent by the transaction initiating node.

[0123] In one implementation, when comparing and verifying the read-write set S'(r, w) of the locally executed transaction with the read-write set S(r, w) sent by the transaction initiating node, some implementations are to hash the two read-write sets separately and compare whether the hash values ​​are the same; other implementations include but are not limited to directly comparing the binary codes of the two read-write sets.

[0124] After the comparison, if the results are the same, the endorsing node sends an endorsement success indication message to the transaction initiating node. In some implementations, the endorsing node will sign the transaction and send the signature information to the transaction initiating node. If the results are different, an endorsement failure indication message is sent to the transaction initiating node.

[0125] S406, the transaction initiating node summarizes the collected endorsement results and determines whether the endorsement policy is met. The endorsement policy can be determined based on the system configuration, that is, which nodes need to confirm the transaction execution. The endorsement policy can be specified as endorsement by all nodes (the transaction needs to be confirmed by all nodes), endorsement by most nodes (such as: the transaction needs to be confirmed by more than 2 / 3 nodes) and endorsement by designated nodes (such as: the transaction needs to be confirmed by nodes A, B, and C). The nodes specified by the endorsement policy are the endorsing nodes. The endorsement policy is based on the chain. If the node belongs to multiple chains, the endorsement policy needs to be specified for each chain.

[0126] In some implementations, the transaction initiating node verifies the signature sent by the endorsing node to determine the legitimate identity of the endorsing node corresponding to the endorsement result.

[0127] S407, if the endorsement policy is met, the consensus module of the system is entered for consensus; otherwise, it indicates that the data may be inconsistent, the transaction is discarded, and feedback is given to the client: the transaction failed, the data may have been tampered with, and manual intervention is required. In the above process, if the endorsement is not passed, subsequent transactions involving tampered data will not be able to pass the endorsement, but other transactions can still be executed normally at this time, and the availability of the system will not be affected.

[0128] S408, the transaction initiating node sends the endorsed transaction to the consensus module of this node and reaches consensus with other nodes. The consensus algorithm can adopt a variety of existing consensus algorithms, such as the PBFT algorithm. The consensus module is responsible for authenticating and sorting distributed transactions. If consensus is reached, the transaction will continue to be executed, otherwise the transaction will be discarded.

[0129] In one implementation, consensus is reached on transactions based on PBFT. Consensus is mainly used for ordering transactions. If transactions conflict, the corresponding transaction consensus fails and the transaction becomes invalid. In the database system of the embodiment of the present invention, PBFT requires a total of three phases in the network.

[0130] (1) Pre-prepare: After the endorsement is reached, the ordering node initiates the consensus. The ordering node can be the transaction initiating node or other nodes in the server cluster. The transaction request is initiated and sent to other nodes in the channel. After receiving the request, other nodes determine whether the read set and other information contained in the request conflict. If there is no conflict, the request is approved and sent to other nodes in the channel.

[0131] (2) prepare: When more than 2f+1 nodes agree to the request, the node agrees to commit the transaction and sends the result to all other nodes.

[0132] (3) commit: If more than 2f+1 nodes agree to commit the transaction, consensus is finally reached and the transaction is committed.

[0133] S409: After consensus is completed, if consensus is reached, each node enters the submission phase to update user data.

[0134] This process consists of 3 parts:

[0135] 1. The node generates a block based on the transaction request and the read-write set generated by the transaction execution: the newly generated block contains the block number of the current block, the transaction execution logic and the execution result; the process of generating a block also includes obtaining the record of the previous block from the block table and performing a hash operation, putting the calculated hash value into the previousHash field of the newly generated block, and then writing the block to the block table to form a chain structure of blocks.

[0136] 2. The node generates a historical record based on the transaction request and the user data affected by the transaction: the historical record contains the updated user data content, block number, transaction initiator signature, transaction endorser signature, and the hash value of the previous historical record. Adjacent historical records form a snapshot chain through this hash value;

[0137] 3. Submit the transaction and update the user data.

[0138] Embodiment 3

[0139] This embodiment includes a procedural description between on-chain transactions and off-chain transactions. For ease of description, the method flow of this embodiment refers to the corresponding steps in the aforementioned embodiments, so it can be implemented based on the process in the aforementioned embodiments. However, the invention described in this embodiment can also be implemented in other database systems that meet the conditions, so the implementation method in this embodiment is not necessarily limited to the aforementioned embodiments.

[0140] If the transaction involves on-chain or off-chain transactions or cross-chain transactions, the endorsement process will split the transaction before forwarding it: for on-chain or off-chain transactions, only the SQL statements that operate on-chain data and the generated read-write sets will be forwarded; for cross-chain transactions, the system will split the transaction according to the granularity of the chain where the transaction is located, and forward the SQL statements and read-write sets of the corresponding chains separately. After receiving the endorsement result, it will be verified according to the endorsement policies of different chains in the configuration. Only when the endorsement policies of all chains involved in the cross-chain transaction are met at the same time, the endorsement of this cross-chain transaction will be considered successful.

[0141] Each node maintains an off-chain data storage domain: OffChain, which is used to store off-chain data. This type of data only exists in this node and is private data of this node. It does not require consensus and will not be copied to other nodes. However, the data of this node maintains the transactionality of on-chain data and off-chain data.

[0142] This embodiment provides transaction guarantees for on-chain and off-chain operations. Figure 5 , the specific process is as follows:

[0143] S501. The client initiates an on-chain and off-chain transaction operation. The transaction includes both the onchain data update operation set onchain op set and the offchain data update operation set offchain op set.

[0144] S502, after receiving the request, the server-side transaction request receiving node starts a transaction manager and processes it according to the operation sequence in the transaction request. For both offchain op set and onchain op set, the transaction is pre-committed, and two transaction processing logic log caches, offchain rw set and onchain rw set, are generated. At this time, other requests accessing this node cannot see the update of this transaction because it has not been truly committed. At the same time, the transaction log generated by onchain op set is added to the on-chain transaction cache pool. The transaction log includes the transaction execution logic onchain op set and onchain rw set.

[0145] S503, initiate an endorsement process with the transaction log generated by the onchain op set (refer to the specific steps of the first embodiment above). If the endorsement process fails, the request receiving node rolls back the on-chain and off-chain transactions, and rolls back the pre-commits generated by the offchain op set and the onchain op set. This transaction fails and exits, and an error code is returned to the client. If the endorsement process succeeds, proceed to the next step.

[0146] S504, request the receiving node to initiate a consensus process with the transaction log generated by onchain op set. If the consensus process fails, request the receiving node to roll back the on-chain and off-chain transactions, and roll back the pre-commits generated by offchain op set and onchain op set. This transaction fails and exits, and returns an error code to the client. If the consensus process succeeds, proceed to the next step.

[0147] S505. The request receiving node actually commits the pre-commit generated by the offchain op set and the onchain op set. Other nodes only receive the onchain op set, so they only commit the onchain op set. At this point, the request receiving node completes the on-chain and off-chain transaction operations.

[0148] Combine the following Figure 6 Let's take a specific example to illustrate:

[0149] In the Tx prepare phase, a transaction including on-chain data operations and off-chain data operations is submitted to Node 1 (Node1). After Node 1 simulates execution, it obtains the transaction logs OnChain tx log of on-chain data and OffChain tx log of off-chain data. The transaction logs also include the read-write set after data operations and data simulation execution. In the endorsement and consensus phase (Endorse & Consensus), the on-chain data log OnChain tx log is consensused and endorsed with Node 2 and Node 3. When consensus and endorsement are successful, it enters the submission phase. Node 1 submits transactions including on-chain data and off-chain data, while Node 2 and Node 3 submit transactions for on-chain data. If consensus and endorsement fail, Node 1 will roll back the simulated on-chain data and off-chain data operation transactions, while Node 2 and Node 3 will roll back the simulated on-chain data.

[0150] In some implementations, considering stronger disaster recovery capabilities, nodes holding OffChain data can add additional nodes and change OffChain data to private OnChain data.

[0151] Embodiment 4

[0152] In another embodiment, the present invention is described to handle the cross-chain characteristics between on-chain transactions, that is, the processing method for the same transaction when it involves more than two data chains. For the convenience of description, the method flow of this embodiment refers to the corresponding steps in the aforementioned embodiment, so it can be implemented based on the process in the aforementioned embodiment. However, the invention described in this embodiment can also be implemented in other database systems that meet the conditions, so the implementation method in this embodiment is not necessarily limited to the aforementioned embodiment.

[0153] In existing alliance chains, data isolation is generally achieved through chains, and different chains are not interoperable and cannot access each other's data. However, in real business scenarios, some transactions involve the atomicity of different chains: a transaction contains transactions involving multiple chains, and these transactions must succeed and fail at the same time, that is, cross-chain.

[0154] This embodiment supports cross-chain features, combined with Figure 7 , the specific cross-chain process is as follows:

[0155] S701. Configure a system chain that can be accessed by all nodes in the network and is used to record the member information of all chains in the network. When a new chain is created in the network, a record is added to the system chain; when a new node joins the chain, the creator of the chain updates the member information of the chain and synchronizes it to the entire system.

[0156] S702: When the client sends a transaction instruction, it needs to mark that the transaction involves cross-chain and indicate which chain each transaction in the cross-chain transaction belongs to. When the server receives the client's cross-chain transaction request, it first numbers the transactions in the transaction in sequence and splits all transactions in the transaction according to the chain they belong to.

[0157] S703. The server node parses the transaction execution logic in the split result, and executes it locally to generate read-write sets corresponding to different chains; the node packages the split transaction execution logic, read-write set and the signature of the node according to the chain to which they belong and sends them to the endorsement node on the chain corresponding to the exchange for endorsement. The endorsement process can follow the endorsement process in the aforementioned embodiment.

[0158] S704. The transaction initiating node on the server side summarizes the collected endorsement results. For cross-chain transactions, when the endorsement results of all split transactions in the transaction comply with the endorsement policy of the chain, the endorsement is considered successful. After the endorsement is successful, the request split result, each transaction number, and the chains involved in the cross-chain transaction are packaged and copied to the nodes of the corresponding chain, and enter the consensus module of the system for consensus. Each transaction number and the chains involved in the cross-chain transaction need to be part of the transaction information, and all subsequent message copies must be accompanied by these two pieces of information.

[0159] S705, submission phase, after the current chain consensus is completed, enter the waiting state, read all the nodes of the chain involved in the cross-chain transaction, and send the consensus results of the chain to these nodes. Similarly, the chain will also receive the consensus results of all other chains. When more than 50% of the nodes of a chain pass the consensus feedback, it is considered that the consensus of this chain has passed. If all chains involved in the transaction have passed the consensus, it means that the cross-chain consensus has passed. If a node contains multiple chains, each transaction needs to be submitted in sequence according to the transaction number. The submission of cross-chain transactions follows the submission process in the aforementioned embodiment. The nodes on the chain only submit transactions related to the chain in the transaction. If the node joins multiple chains involved in the cross-chain transaction, the transactions related to the chain are submitted separately on different chains according to the transaction sequence number.

[0160] Combine the following Figure 8, an example is used to illustrate the endorsement consensus process between multiple chains:

[0161] exist Figure 8 In the example, Node 0 only maintains chain 1, Node 1 to Node 4 simultaneously maintain chain 1 and chain 2, and Node 5 only maintains chain 2.

[0162] The endorsement consensus process is as follows:

[0163] 1. Pre-prepare stage: Node1 receives the cross-chain transaction: chain1 Tx and chain2 Tx, splits them, and performs transaction pre-operation on this node. If the pre-operation passes, chain1 Tx is delivered to blockchain1, and chain2 Tx is delivered to blockchain2;

[0164] 2. Prepare stage: All nodes on blockchain1 endorse chain1 Tx, and send the result to all nodes in the form of voting, and count the voting results of all nodes on blockchain1 for this transaction, with >2f1 as the voting statistics rule, and finally send the statistical results of chain1 Tx by this node as the commit opinion vote to all members. When sending to the member nodes of this chain, it carries the transaction information, and when sending to the nodes outside the chain, it only carries the voting success or failure mark. All nodes on blockchain2 process chain2 tx similarly;

[0165] 3. Commit stage: Each node counts the commit votes of all sub-transactions in the entire cross-chain transaction. Only when all sub-transactions are counted as commit at the same time, the cross-chain transaction is actually committed at this node. Node0 commits the chain1 tx part, node1-node4 commits chain1 tx and chain2 tx at the same time, and node5 commits the chain2 tx part;

[0166] To make it easier to understand, let’s use another practical example to illustrate the cross-chain process:

[0167] There are two chains in the network, chain1 and chain2. Chain1 contains three nodes A, B, and C and the smart contract test1(), and chain2 contains three nodes C, D, and E and the smart contract test2(). This information has been saved in the system chain and can be accessed by all nodes.

[0168] (1) The client initiates a cross-chain transaction, which includes calling the smart contract call test1() on chain1 and calling the smart contract call test2() on chain2;

[0169] (2) The server receives the message, numbers it, splits it, and forwards it;

[0170] Send {id:1,cmd:'call test1()',chains:'chain1,chain2'} to nodes A, B, and C

[0171] Send {id:2,cmd:'call test2()',chains:'chain1,chain2'} to nodes C, D, and E

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

[0173] For example, if the consensus of chain1 is passed, nodes A, B, and C will send the consensus result to C, D, and E at the same time.

[0174] The same applies to C, D, and E.

[0175] (4) If C, D, and E receive more than 2 (>1 / 2) messages that the chain1 consensus has passed, the chain1 consensus is considered to have passed. If the chain2 consensus has also passed, the transaction call test2() is finally submitted.

[0176] The same goes for nodes A, B, and C.

[0177] If both chain1 and chain2 pass consensus, node C will submit call test1(); call test2() in the order of transactions.

[0178] Combination Fig. 9 , is another example of the above execution flow:

[0179] In the Tx prepare phase, a transaction containing two on-chain data operations is submitted to the node (Node2). After the simulation execution, Node 2 obtains the transaction logs Chain1 tx log of on-chain data 1 and Chain2 tx log of on-chain data 2. The transaction logs also contain the data operations and read-write sets after the data simulation execution. In the endorsement and consensus phase (Endorse & Consensus), Node 2 endorses and agrees with Node 1 on the transaction log Chain1 tx log of on-chain data 1, and endorses and agrees with Node 3 on the transaction log Chain1 tx log of on-chain data 2. In the consensus voting phase (Multi-consensus voting), the consensus results of all nodes on this transaction are counted. When the consensus and endorsement are successful, the submission phase (Tx Commit) is entered. Node 2 submits the transaction containing chain 1 and chain 2 data operations, while Node 1 submits the transaction of chain 1 data operations, and Node 3 submits the transaction of chain 2 data operations. If consensus and endorsement fail, Node 2 will roll back the simulated transaction that includes data operations on Chain 1 and Chain 2, while Node 1 will roll back the transaction for data operations on Chain 1 and Node 3 will roll back the transaction for data operations on Chain 2.

[0180] Embodiment 5

[0181] This embodiment introduces the design of the smart contract of the present invention.

[0182] The database system in the embodiment of the present invention is based on the traditional stored procedure, and a tamper-proof smart contract is designed and implemented. The stored procedure is a set of SQL statements to complete a specific function, which is stored in the database. After the first compilation, it does not need to be compiled again. The user executes it by specifying the name of the stored procedure and giving parameters. In the traditional distributed database system, the stored procedure will be installed synchronously to all nodes in the system after installation. However, the transaction that calls the stored procedure is not replicated at the "call level" (stored procedure calls are replicated at the statement level rather than at the call level), that is, when the transaction initiating node executes a transaction that calls the stored procedure, it will only execute the stored procedure once locally, and other nodes will directly copy the data updated by this call when replicating, instead of executing the same stored procedure again. Such a design will ensure strong consistency of data, but if the content of the stored procedure is tampered with or even whether the transaction is executed through the agreed stored procedure, other nodes cannot detect and distinguish, which gives the possibility of malicious nodes to tamper with data by modifying the content of the stored procedure. The trusted data management system in this article optimizes the replication process of the stored procedure, sets the replication of the stored procedure to the call level, and implements the smart contract feature in combination with the endorsement process: the node executes the smart contract locally according to the contract name and parameters. The specific process is as follows:

[0183] (1) The client calls the transaction to execute the contract:

[0184] "call Smart_Contract(arg1,arg2)"

[0185] (2) The server-side transaction receiving node locally passes in parameters arg1 and arg2 to execute the smart contract named Smart_Contract and generates a read-write set S(r,w); then the smart contract name, parameters, and read-write set are packaged and forwarded to the endorsing node;

[0186] (3) The endorsing node receives the endorsement request and calls the locally stored smart contract according to the smart contract name and parameters in the request. If the smart contract can be successfully executed locally and generates a read-write set S'(r, w), it is compared with S(r, w) in the endorsement request and the endorsement result is returned.

[0187] Among them, if the smart contract execution fails at the endorsement node in process (3), the reason may be that the smart contract does not exist or the parameters do not match, indicating that the transaction initiating node has executed a tampered smart contract. If the read set in the read-write set is inconsistent, it means that the data state before the execution of the smart contract has been tampered with. If the read set is consistent but the write set is inconsistent, it means that the logic of the smart contract may have been tampered with. Through the design in this article, it is possible to achieve in an untrusted environment that the node updates the data through a pre-agreed program segment, while ensuring that the smart contract logic is not tampered with during this process.

[0188] Embodiment 6

[0189] This embodiment introduces the design of rights management in the embodiment of the present invention.

[0190] The database system of the embodiment of the present invention herein adds signature information (client signature, endorsement signature) and verification process to the life cycle of the transaction request. The server can more effectively verify the legitimacy of the user and store the request signature information along with the transaction information in the block, which has stronger traceability and non-repudiation. The specific signature and verification process is as follows:

[0191] (1) The client logs in using a certificate, and the server verifies the legitimacy of the certificate to determine whether the client has login permission;

[0192] (2) The client uses the certificate it holds to sign the request to be sent. The server verifies the legitimacy of the certificate and signature to determine whether the user has the read and write permissions required to operate the data. If it is illegal, it will directly report an error. Otherwise, the signature information will be cached for subsequent use in the block.

[0193] (3) After simulating the transaction and verifying the read-write set, the endorsing node uses its own certificate to endorse and sign, indicating that the transaction has been endorsed by this node;

[0194] (4) The transaction initiating node verifies the endorsement signature, determines the legitimacy of the endorsement signature, and thereby determines whether the endorsement policy is satisfied.

[0195] After the transaction in this system has gone through a complete life cycle, the transaction structure recorded in the block will contain the signature of the initiating node: used to prove that this node has the authority required to initiate the transaction operation data. It also contains the signature of the endorsing node endorsing this transaction: used to prove that the content of this transaction and the data before and after execution have been authenticated by the endorsing node. The signature verification process ensures the validity of transaction execution and the consistency and immutability of the system. Once any dispute about the transaction occurs, the responsibility can be determined through the signature information, ensuring the anti-repudiation of the system.

[0196] The system implements table management and permission control through permission tables: when creating a data table, a permission record for this data table is added and inserted into the permission table data, recording the certificate information of the table creator and the certificate information with read and write permissions. Combined with the signature verification process, when a transaction reads and writes data, the server first verifies whether the certificate of the transaction initiator has the corresponding permission. If not, the transaction fails. The creator of the data table can modify the read and write permissions.

[0197] Based on the data table, this system adds block table and history table. The permissions, insertion and update of these two types of tables are maintained by the system according to the operation of user data transactions. The operation of these two types of tables is performed by the local system of the node, without the need for on-chain node consensus synchronization, and is strongly related to user data transactions. That is, if all business data of the node is consistent, then these two types of tables on all nodes must also be consistent.

[0198] In the embodiment of the present invention, two types of chains may be included:

[0199] 1) System chain: The system chain is built into the system and everyone participates in the chain. It is used to synchronize and manage user configuration information, such as all user chains coexisting in the system, all nodes contained in each transaction chain, and the endorsement policy of each user chain. This information can be used for cross-chain transactions. When a new node wants to join the chain, a node in the system initiates a transaction to join the chain on the system chain. After consensus among all nodes on the system chain, the node information of the user chain that the new node wants to join can be updated on the system chain. If the endorsement policy changes, the endorsement policy information is updated using the same process.

[0200] 2) User chain: The function is consistent with the chain in the traditional blockchain system. By using a chain structure to record the user's operation on the data system, all nodes maintain the same account book to ensure the consistency and non-tamperability of the entire system. At the same time, the structured storage used has brought great convenience to data tracing, analysis and statistics.

[0201] Embodiment 7

[0202] The method of the embodiment of the present invention is described in detail above, and the device of the embodiment of the present invention is provided below.

[0203] The example in the first embodiment is a functional module design example of a server node of a database system when realizing the technical effect of the present invention. Specifically, it can be implemented based on different database systems. That is, each functional module in this embodiment can be implemented in different system architectures through software modules or hardware modules, or a combination of software and hardware.

[0204] With the development of technology, designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, a method flow can also be implemented by a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0205] The above embodiments illustrate that the modules or units can be implemented by computer chips or entities, or by products with certain functions. In the existing blockchain system, there are certain requirements for the computing power and network communication capabilities of the nodes, so a typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a node, a laptop computer, etc. However, with the development of technology, the computing power and communication capabilities of hardware devices will continue to increase. Therefore, it is foreseeable that in future technical implementations, all types of hardware devices with computing power and communication capabilities can be used as node devices in the blockchain system. For example, cellular phones, smart phones, personal digital assistants, media players, car computers, Internet of Things devices, navigation devices, gaming devices, tablet computers, wearable devices, or a combination of any of these devices can be used as a node device in the blockchain system.

[0206] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0207] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0208] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0209] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0210] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0211] In a typical configuration, such as Fig.10 As shown, a node device 100 provided in an embodiment of the present invention is shown. The device 100 includes a processor 1001, a memory 1002, and a transceiver 1003. The processor 1001, the memory 1002, and the transceiver 1003 are interconnected via a bus.

[0212] The memory 1002 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 1002 is used for related instructions and data. The transceiver 1003 is used to receive and send data with other node devices or clients.

[0213] The processor 1001 may be one or more central processing units (CPUs). When the processor 1001 is a CPU, the CPU may be a single-core CPU or a multi-core CPU.

[0214] The processor 1001 in the device 100 is used to read the program code stored in the memory 1002 to execute the method steps in the aforementioned method embodiment, or to implement the various functional modules of the aforementioned node embodiment. Therefore, the implementation of each operation of the node device of this embodiment can be described in the corresponding description of the aforementioned method embodiment.

[0215] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

Claims

1. A data storage method, characterized in that: The method is executed on a transaction initiation node in a database server cluster, and comprises: Obtaining a transaction instruction, where the transaction instruction includes a first transaction and a second transaction, where the first transaction and the second transaction belong to the same transaction, where the first transaction is an on-chain transaction, and where the second transaction is an off-chain transaction; A consensus is reached between the first transaction and other nodes in the database server cluster; When the first transaction successfully reaches consensus with other nodes in the database server cluster, the transaction is committed to instruct the transaction initiating node to execute the first transaction and the second transaction.

2. The method according to claim 1, characterized in that: The method further comprises: Before reaching consensus on the first transaction with other nodes in the database server cluster, endorsing the first transaction with an endorsing node in the database server cluster; When the first transaction is successfully endorsed by the endorsing node, a consensus is reached between the first transaction and other nodes in the database server cluster.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: After obtaining the transaction instruction, pre-submit the transaction; When the first transaction fails to reach consensus with other nodes in the database server cluster, the transaction is rolled back.

4. The method according to claim 2, characterized in that: The method further comprises: After obtaining the transaction instruction, pre-submit the transaction; When the first transaction fails to be endorsed by the endorsing node, the transaction is rolled back.

5. A data storage node, characterized in that: The data storage node comprises at least one functional module, and the functional module is used to implement the method described in any one of claims 1 to 4.

6. A data storage node, characterized in that: The data storage node includes a processor and a memory, The memory stores executable program instructions; The processor reads the executable program instructions in the memory to execute the method described in any one of claims 1-4.

7. A blockchain system, comprising the data storage node described in any one of claims 5-6.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store a computer program, and the computer program is used to execute the method according to any one of claims 1 to 4.

9. A computer program product, characterized in that The computer program product comprises program codes, and when a computer runs the computer program product, the computer executes the method according to any one of claims 1 to 4.

Images