A database system, node, and method

Abstract

This invention provides a transaction method and node design for a database system. Upon receiving a request from a client, a node directly simulates execution on its local state machine, generating a simulated execution result. This simulated execution result is then packaged with the user's execution logic and copied to other nodes for tamper-proof verification. Other nodes in the network, upon receiving the message packet, extract the user's execution logic, execute it locally to generate a simulated execution result, and then compare it with the simulated execution result in the message packet. If the two results are inconsistent, it indicates data tampering, and a verification failure response is sent to the initiating node. If the two results are consistent, a verification success response is sent to the initiating node. After receiving a sufficient number of verification responses, the verification initiating node summarizes and judges the results. Requests deemed to have failed verification are discarded, while requests deemed to have succeeded are used for PBFT consensus replication logic with the simulated execution result set until state replication ends or fails.

Description

Technical Field

[0001] This invention relates to database technology, and more particularly to a database design based on blockchain technology. Background Technology

[0002] Blockchain is a chain-like data structure that combines data blocks sequentially, and is a distributed ledger that is cryptographically guaranteed to be immutable and unforgeable. Based on decentralized protocols, blockchain constructs a distributed structural system that allows information for value exchange to be transmitted to the entire network through distributed propagation. The content of the information data is determined through distributed ledger recording, timestamped to generate block data, and then distributed to various nodes, achieving distributed storage.

[0003] Smart contracts are a new feature that has emerged with the development of blockchain technology. In essence, a smart contract is a coded instance of a contract between two parties. It responds to the information received according to the contract between the two parties. It can receive and store value, and it can also output information and value. It plays the role of a trustworthy system and always executes operations according to the pre-agreed rules.

[0004] Relational databases are databases built on the relational model, using mathematical concepts and methods such as set algebra to process data. The business relationships in most current business systems can be defined using the relational database model. The standard SQL query language is a language based on relational databases, allowing for the retrieval and manipulation of data within the database.

[0005] Existing blockchain solutions cannot achieve the data management capabilities of relational databases, nor can they perform data transaction operations. Therefore, they are insufficient to meet the data management needs of large-scale data systems. Summary of the Invention

[0006] This invention provides a database system, including transaction methods and nodes, enabling users to transition from traditional relational database usage to traditional blockchain usage while maintaining their existing relational database usage patterns. The system integrates both into a single, unified system for collaborative management of the two datasets. This database system is compatible with most features of relational databases, including SQL support, relational structure storage, and ACID transaction guarantees. It also incorporates more blockchain features, possessing anti-tampering characteristics such as a tamper-proof Byzantine consensus protocol, transactional blockchain, and smart contracts.

[0007] Firstly, this invention provides a data storage method: After receiving a request from a client, the request receiving node directly simulates execution on its local state machine to generate a simulated execution result, packages this simulated execution result with the user's execution logic, and copies it to other nodes for anti-tampering verification; after receiving the message packet, other nodes in the network extract the user's execution logic from it, execute it locally to generate a simulated execution result, and then compare it with the simulated execution result in the message packet; if the two results are inconsistent, it indicates that data tampering has occurred, and a verification failure reply is sent to the initiating node; if the two results are consistent, a verification success reply is sent to the initiating node; after receiving enough verification replies, the verification initiating node summarizes and judges, and requests that are judged to have failed verification are directly discarded, while requests that are judged to have succeeded verification are used for PBFT consensus replication logic with the simulated execution result set until state replication ends or fails.

[0008] Compared to existing technologies, this approach adds tamper-proof verification logic before consensus and uses verified simulated execution results for replication, achieving both tamper-proof design and maintaining state consistency.

[0009] Secondly, this invention provides a transaction processing method that includes on-chain and off-chain data: A client initiates an on-chain and off-chain transaction operation, which simultaneously includes a set of on-chain data update operations and a set of off-chain data update operations. Upon receiving the request, the server-side transaction request receiving node starts a transaction manager, processes the operations according to the order in the transaction request, performs a transaction pre-commit, generates two transaction processing logic log caches, and simultaneously adds the transaction log generated by the on-chain transaction to the on-chain transaction cache pool. The transaction log includes the transaction execution logic. An endorsement process is initiated using the transaction log generated by the on-chain transaction. If the endorsement process is successful, the request receiving node initiates a consensus process. If the consensus process is successful, the request receiving node actually commits the pre-committed data, which includes both on-chain and off-chain transactions. Other nodes, having only received the on-chain transaction, only commit the on-chain transaction. Thus, the request receiving node completes the on-chain and off-chain transaction operation.

[0010] Compared to existing technologies, this invention guarantees the atomicity of transactions, enabling on-chain and off-chain data within the same transaction to be updated based on transaction processing logic.

[0011] Thirdly, this invention provides a transaction processing method involving multiple on-chain data: When a client sends a transaction, it needs to mark that the transaction involves cross-chain and specify 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 sequentially and splits all transactions in the transaction according to their respective chains. Each chain executes its own endorsement process for the transactions involved, which is a single-chain endorsement process. The server-side transaction initiating node summarizes the collected endorsement results. For cross-chain transactions, when the endorsement results of all split transactions in the transaction conform to the endorsement policy of their respective chains, the endorsement is considered successful. After successful endorsement, the request splitting results, each transaction number, and which chains the cross-chain transaction involves are packaged and copied to the corresponding chain's node for consensus in the system's consensus module. Each chain performs its own consensus process, which is a single-chain consensus process. Each transaction number and which chains the cross-chain transaction involves need to be part of the transaction information, and all subsequent message copies must include this information. During the submission phase, after the current chain reaches consensus, it enters a waiting state, reads all nodes of the chains involved in the cross-chain transaction, and sends the consensus results of those chains to these nodes. Similarly, this chain will also receive consensus results from all other chains. When more than 50% of the nodes on a chain report consensus approval, that chain is considered to have passed consensus. If all chains involved in the transaction have passed consensus, the cross-chain consensus is considered successful. If a node contains multiple chains, each transaction must be submitted sequentially according to its transaction number. On-chain nodes only submit transactions related to their own chain. If a node is involved in multiple chains in a cross-chain transaction, it submits transactions related to each chain separately according to their transaction numbers.

[0012] In some implementations, this method also configures a system chain, accessible to all nodes in the network, to record member information for 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 a chain, the chain creator updates the chain's member information and synchronizes it throughout the system.

[0013] Compared to existing technologies, the embodiments of the present invention guarantee the atomicity of transactions, enabling multiple on-chain data within the same transaction to be updated based on transaction processing logic.

[0014] Fourthly, this embodiment also provides a data node, which includes multiple functional modules. Through these multifunctional modules, the node can realize the functions described in the first, second, and third aspects above.

[0015] Fifthly, embodiments of the present invention also provide a computer system that 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 software programs, and when the software programs are executed by the processor, the processor of the computer system is used to execute the methods of the first, second, and third aspects described above, or any implementation thereof.

[0016] Sixthly, embodiments of the present invention also provide a storage medium for storing a computer program, wherein 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 various steps of the method.

[0017] As can be seen, the embodiments of the present invention provide a blockchain system transaction method and node. This integrates data management and anti-tampering mechanisms within a database system, reducing deployment, management, and maintenance costs. Furthermore, a single system can support transaction processing capabilities for multiple on-chain and off-chain data, improving the system's task collaboration efficiency. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the background art, the accompanying drawings used in the embodiments of the present invention or the background art will be described below.

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

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

[0021] Figure 3 This is a flowchart of a data storage method for a database system provided in an embodiment of the present invention;

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

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

[0024] Figure 6 This is a schematic diagram of a process for 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 This is a flowchart of another data storage method for a database system provided in an embodiment of the present invention;

[0026] Figure 8 This is a schematic diagram of the endorsement and consensus process for cross-chain transactions in a database system provided by an embodiment of the present invention;

[0027] Figure 9 This is a schematic diagram of a process for cross-chain data transaction operations in a database system provided by an embodiment of the present invention;

[0028] Figure 10 This is a schematic diagram of the hardware architecture of a node in a database system provided by an embodiment of the present invention. Detailed Implementation

[0029] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0030] First, we will introduce some concepts in the blockchain network architecture.

[0031] Client: Users can create chaincode and initiate transactions through the blockchain system's client. The client can be deployed on any terminal and is implemented using the corresponding SDK (Software Development Kit) of the blockchain system. This terminal communicates with nodes in the blockchain network to achieve the client's functions.

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

[0033] Block Structure: A block records transaction data within the time period in which it was created. The block body is essentially a collection of transaction information. While the structural design of each blockchain may differ slightly, it generally consists of two parts: a header and a body. The header links to previous blocks and provides integrity guarantees for the blockchain database, while the body contains all verified records of value exchanges that occurred during the block's creation.

[0034] Nodes (peers): In a blockchain network, a distributed network system is constructed, ensuring that all data in the database is updated in real time and stored across all participating network nodes. Simultaneously, the blockchain network employs a set of protocol mechanisms, allowing every node in the network to verify the correctness of other nodes' records while participating in the recording process. Only when the protocol mechanism ensures that eligible nodes (e.g., all nodes, a majority of nodes, or specific nodes) simultaneously agree that the record is correct, or when all participating nodes' comparisons show consistent results, can the record's authenticity be recognized by the entire network, and only then can the recorded data be written into a block. Therefore, in a blockchain network, all nodes collectively constitute a decentralized distributed database.

[0035] In different blockchain systems, besides storing block data, some nodes also have special functions, such as endorsement nodes and ordering nodes. Endorsement nodes execute smart contract state machines, simulating transaction execution. They contain a pre-defined set of endorsement policies, which are equipped with specific chaincode. All transactions must adhere to these policies, as only endorsed transactions are legitimate and recognized. In practice, upon receiving a transaction request from a client, the endorsement node executes a simulated transaction and generates an endorsement signature based on the result, thus completing the endorsement of the transaction.

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

[0037] Most business relationships in business systems can be defined using relational database models. Structured Query Language (SQL) is a language based on relational databases, allowing for the retrieval and manipulation of data within the database. Many current business systems require blockchain ledgers, such as supply chain item tracking ledgers and multi-party order ledgers in e-commerce platforms. These require the tamper-proof and non-repudiation features of blockchain technology to support their operation. Data that can be defined as this type of ledger data can be called on-chain data. At the same time, on-chain data often exhibits strong correlations with other data in the original business (also known as off-chain data), typically requiring the maintenance of consistency and atomicity between them. However, simply splitting some data from a business system onto the blockchain to gain the advantages of a blockchain ledger makes the joint management of on-chain 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, some system prototypes that integrate database technology and blockchain technology have emerged in the industry, such as BigChainDB, ChainSQL, and Catena. These prototypes all possess the characteristics of blockchain, such as decentralization, tamper-proofness, and Byzantine fault tolerance, but there are significant differences in their data management capabilities: (1) BigChainDB does not support SQL access, only supports KV type data structures, and does not support transactions; (2) ChainSQL synchronizes unstructured blockchain data to a structured external database, supports limited SQL access, and does not support transactions because the state is stored in the newly added external database system, which also increases the consistency maintenance problem; (3) Catena can be considered as adding a lightweight SQL support module to the traditional public chain system. The SQL support capability is very limited, and it does not support transactions. Since the consensus is a non-deterministic algorithm, it is far from ACID transaction guarantee.

[0039] This invention combines the data management capabilities of traditional relational databases with the trustworthy and tamper-proof capabilities of blockchain technology, outputting data through a universal SQL interface. This provides a single system that addresses users' needs for data management and tamper-proofing, thereby reducing deployment, management, and maintenance costs and shortening the learning curve. The system supports multi-chain and off-chain data storage without requiring third-party synchronization tools, directly providing on-chain and off-chain transaction operations and cross-chain transaction operations, resulting in high efficiency for collaborative analysis.

[0040] To facilitate understanding of the present invention, some key concepts in the embodiments of the present invention will be explained below.

[0041] Endorsement consensus mechanism:

[0042] Currently, most mainstream strongly consistent distributed database systems primarily rely on Paxos-like non-Byzantine fault-tolerant consistency protocols to construct inter-node state replication mechanisms. The replicated content of this type of mechanism can be: a) the execution result state set of a single node; b) request execution logic;

[0043] Type A involves one node simulating the execution of a user request logic, obtaining the simulated execution result, and then performing consistent replication of the simulated execution result. Once consistency is achieved, each participating node directly uses this simulated execution result to update its own state. This type of approach is relatively easy to maintain cluster state consistency, such as MySQL's row-based binlog or ZooKeeper's CRUD operation logs. However, this type of approach is more like using the state of a single node to update the state of the entire cluster. If the simulated execution node is tampered with, the overall cluster state will become disordered.

[0044] Type b replicates the original user execution logic across all cluster nodes, and then executes it separately on each node and updates its own state. This type is advantageous because each node can independently maintain its own state, and it is more beneficial in cases of tampering, such as MySQL's statement-based binlog. However, this type focuses on the replication process, and in some implementations, the process may involve randomness, such as the random() logic, so execution on different nodes may lead to inconsistencies.

[0045] As can be seen from the above, simply using a and b cannot simultaneously achieve the purpose of anti-tampering and consistency. The database system of this embodiment 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, 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 there is data tampering, and reply verification failure to the initiating node; if the two results are consistent, reply verification success to the initiating node; (4) After receiving enough verification replies, the verification initiating node summarizes and judges, and the requests that are judged to fail are directly discarded, and the requests that are judged to succeed are used to perform PBFT consensus replication logic with the simulated execution result set until the state replication ends or fails.

[0046] Compared to traditional state replication machines, the database system of this invention adds anti-tampering verification logic before consensus and uses verified simulated execution results for replication, thus achieving both anti-tampering design and maintaining state consistency.

[0047] Transactional blockchain:

[0048] Blockchain systems, through their chain structure, guarantee the immutability of historical transactions. Current relational databases only store historical operation logs in files for data recovery and other tasks; however, these log files do not guarantee immutability. Therefore, the database system in this embodiment of the invention uses the transaction log content to construct blocks and assemble them into a chain. Each block contains all committed transactions of that transaction, as well as additional content such as the block number, parent block hash, transaction number, timestamp, and various signature information. Similar to blockchain systems, the linked list in this embodiment of the database system ensures immutability through the parent block hash. Furthermore, it allows tracing the request initiator information through transaction signatures and the endorsement node information through endorsement signatures.

[0049] Smart Contracts:

[0050] Smart contracts, as the most crucial feature extending blockchain from a single digital currency function to various fields, ensure that all nodes can execute the same business logic. In relational databases, stored procedures already include similar functionality; however, traditional relational databases operate in a relatively trusted environment, so their process design is primarily based on single-point execution and multi-point replication, thus lacking tamper-proof capabilities. The database system of this invention combines the design features of stored procedures, extending them to include tamper-proof smart contract characteristics. During message replication, the call command and execution result are packaged and copied to all nodes for tamper-proof verification. Only calls that pass verification will proceed to subsequent steps. Furthermore, the database system of this invention supports multiple chains; one smart contract corresponds to one chain and is only installed on the corresponding chain's nodes. When a chain is deleted, its smart contracts are also cleaned up. All on-chain data update operations in the system can only be completed through smart contract calls.

[0051] Access control:

[0052] Access control is primarily designed for the multiple blockchains supported by the system described in this paper. The chain structure in the database system of this invention embodiment is divided into two categories: System Chain and Data Chain. System Chain is used for storing and managing the metadata of the entire cluster's data chain; Data Chain is used for user data reading and writing, and is created by users. For ease of description, a participating node in a Data Chain is described as a Member Node of that chain; otherwise, it is referred to as a Non-Member Node of that chain.

[0053] (1) Data Chain access control: In order to better data isolation and privacy protection, the access control right of DataChain is reserved only for the participating nodes in the chain. If a node wants to access the data maintained by other nodes, it must do so through access to the Member Node.

[0054] (2) System Chain Access Control: As the metadata storage chain for the entire system, the System Chain is invisible to external users and can only be accessed by cluster member nodes 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 can only be read later, and cannot be modified or appended again. Second, when a Data Chain is created, its Member Node writes the metadata of this Data Chain to the System Chain. The System Chain will verify whether the writer is one of the Member Nodes of the Data Chain.

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

[0056] In existing blockchain systems, data is stored on a ledger and accessible to all nodes, compromising data privacy. For business scenarios requiring data privacy (such as financial systems), only some private data can be stored off-chain, while the remaining publicly accessible data is stored on-chain. An additional system is needed to maintain the consistency between these two data sets. In the database system of this invention, to more effectively isolate data, a chain is defined at the database level (DB), and each blockchain is maintained as a partition channel. The entire cluster can maintain multiple channels, and each node instance can simultaneously support two data storage types.

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

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

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

[0060] Based on the above multi-chain design, this embodiment of the invention provides an integrated solution for managing multiple types of data, and offers features for transactional support between them:

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

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

[0063] The following section provides a detailed introduction to on-chain cross-chain transactions.

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

[0065] After a cross-chain transaction is generated, the server node generates a transaction log during the Prepare phase of the transaction and breaks it down into single-chain parts at the chain granularity. Then, it finds the member nodes of each chain through the system chain and uses the single-chain parts to perform endorsement consensus. The commit information of each chain consensus needs to be broadcast to all participating nodes. All participating nodes receive the consensus results of all chains and perform statistics. Only when the consensus of all chains is completed can the transaction part of the chain maintained by this node be committed. Ultimately, for the entire cluster, it is guaranteed that all chain updates either all succeed or all fail.

[0066] The following section details on-chain and off-chain cross-chain transactions.

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

[0068] After this on-chain and off-chain transaction is generated, the server node processes it 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; among which the update operation log for on-chain data only exists in the on-chain part.

[0069] During the endorsement consensus process, the node only uses the on-chain portion of (1) in the transaction log. After the endorsement consensus process is completed, (1) and (2) are committed at once. If the process fails, both are rolled back, ultimately achieving atomic operations on and off the chain.

[0070] Example 1

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

[0072] Each client (110a, 110b, 110c...110n) in 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, enabling the database system to support other business systems. The signature module 113 issues certificates through Triangle CA to complete login and request signature verification. During the handshake phase between client 110 and server 120, the security module 113 signs the login request information and attaches the signature information and accompanying certificate to the request information. After receiving the login request message from client 110, server 120 will only continue the handshake process if verification is completed; otherwise, login fails.

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

[0074] CA Module 121: Primarily used for system access control, referencing CA verification schemes. First, a root certificate and corresponding private key are generated. Then, ordinary certificates and their corresponding private keys are issued using the root certificate's private key. The storage of the root certificate's private key and the issuance of certificates require negotiation among all alliance members. Each server contains a root certificate, acting as the central verification authority for the CA. All messages on the network must be accompanied by signature information and a corresponding certificate.

[0075] Security Module 122: This module verifies the signature in the endorsement request and adds a signature to the endorsement result upon successful endorsement. During the transaction endorsement phase, other service nodes, upon receiving the replicated message, also perform verification before executing the endorsement process. After endorsement, when returning the endorsement result, the server's private key is used to sign the result, and then the signature and accompanying certificate are attached. During the consensus phase, verification is also required when collecting endorsement results from each node. Only verified results are considered valid endorsement information.

[0076] SQL parsing module 123: Used to parse SQL requests from clients, parsing the SQL statements in the request according to SQL syntax rules, and converting 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 node's endorsement of transaction requests and consistent replication, and has Byzantine fault tolerance capability. Compared with the traditional state replication machine, the database system of this embodiment 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 take out the user execution logic from it, 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 there is data tampering, and reply verification failure to the initiating node; if the two results are consistent, reply verification success to the initiating node; (4) After receiving enough verification replies, the verification initiating node summarizes and judges, and the requests that are judged to fail are directly discarded, and the requests that are judged to succeed are used to perform PBFT consensus replication logic with the simulated execution result set until the state replication ends or fails;

[0079] Storage engine module 126's primary function is data storage. Data is mainly divided into three categories: system chain data, user chain data, and user private data. The specific data storage formats are as follows:

[0080] System Chain Data: When the system is established, a system chain database (DB) is configured to store meta information for all chains within the system. The DB contains two types of tables: 1. System Member Table: This table contains information about all nodes in the system, including node IDs, IP addresses, and status information (nodes may not belong to the same chain); 2. Chain Member Table: A separate configuration table is created for each chain, with the table name matching the chain name, such as `chain1`. This table contains the IDs, IP addresses, certificates, endorsement node flags, and status information (online, offline, error) of all nodes on that chain. When a user joins the system or a chain, they initiate a transaction to update the system member table or chain member table. When a user creates a chain, the system creates a configuration table for that chain based on the user's creation and inserts the member node information for that chain. The system data chain is backed up on all nodes, accessible to all nodes, and jointly maintained. The configuration information can be used to configure endorsement policies and cross-chain transactions.

[0081] User chain data consists of three parts: 1) User chain data: This part contains the actual user business data in the system. If a node joins multiple chains, the user data on each chain corresponds to a separate database (DB), and the data between chains is isolated by DB. Nodes belonging to the same chain jointly maintain the user data on that chain; nodes not on that chain do not have a backup of this data. Modifications to the user chain data are recorded in the corresponding block table and history table; 2) Historical snapshot chain data used to trace transaction updates; and 3) The blockchain data of that chain. User chain data is stored in the system's blockchain DB. Each chain contains one 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, it maintains multiple copies of the user chain data locally. This data is only backed up on nodes included in that chain; other nodes not joined to this chain cannot access or manipulate this data.

[0082] User off-chain data: This data is the node's private data and exists independently only on this node. If a transaction initiated by the node involves operations on user off-chain data, the system will filter this part of the content and only synchronize and replicate the on-chain data portion of the transaction. Furthermore, modifications to this data will not generate historical records or new blocks; they only take effect locally on the node.

[0083] refer to Figure 2This is an example of multiple chains coexisting in a server cluster. Nodes 1, 2, and 3 jointly maintain a system chain. Nodes 1 and 2 jointly maintain data on data chain 1, while nodes 2 and 3 jointly maintain data on data chain 2. Meanwhile, nodes 1 and 3 each maintain their own off-chain data.

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

[0085] Transaction Block Engine 127: Responsible for generating blocks corresponding to transaction requests, maintaining the update of the entire blockchain data, and ensuring the distributed transaction characteristics of requests among nodes.

[0086] In this embodiment, data storage is performed using a chain structure, as detailed below:

[0087] Transaction chain:

[0088] In the database system of this invention, each channel has a transaction chain used to store transaction logs, enabling the system to resist tampering. When a channel is created, a corresponding transaction chain is automatically created, and this chain is still stored in a table in a relational structure. The block table structure information includes: block number, parent block hash, transaction initiation timestamp, client signature, signatures of all endorsing nodes, transaction content, and execution result.

[0089] After consensus is reached, the transaction logs of the consensus-reached transactions are packaged into blocks, with each transaction constituting a block. First, the transaction logs are parsed to read information such as the client transaction initiation time, transaction request, endorsed execution result, client signature, and signatures of each endorsing node. Then, the content of the previous block in the chain structure is read. First, the block number of the previous block is incremented by one to obtain the block number of the current block. Then, the hash of the entire block is calculated to obtain the hash value of the parent block. All of the above content is used to construct the block for the current transaction according to the transaction block table structure. The chain structure is formed by each block containing the hash of its parent block.

[0090] After a block is generated, it is directly inserted into the transaction chain. Because the transaction log is the result of consensus among all nodes in the chain, meaning the transaction log is guaranteed to be identical, the block content of each node can be guaranteed to be consistent. If the data is tampered with, the parent block hash will fail verification.

[0091] Historical snapshot chain:

[0092] Current relational databases do not support direct querying of historical information, making it impossible to perform quick analysis and statistical work using SQL syntax. In the database system of this invention, each data table has a separate historical snapshot chain to store all historical states of that table. The historical snapshot chain is also stored in a table according to a relational structure. When a user creates a data table, a corresponding historical snapshot chain is automatically created. The table structure includes: all columns of the corresponding data table, block number, transaction number, and the hash value of the previous record. This table is created when the user creates the data table. Similarly, the historical snapshot chain uses a relational table for storage, with each transaction as one record.

[0093] Each transaction within a transaction generates a record in the corresponding historical snapshot chain, serving as a block in the historical block snapshot chain. This block is generated simultaneously with the transaction chain blocks. When parsing the transaction log in the aforementioned transaction chain, the execution results are then analyzed and organized by transaction and its breakdown. For each transaction, information such as the data table being operated on, the modified content, and the transaction type is read. Each table's related transactions are uniquely numbered as the transaction number. For each transaction, the hash value of its parent block is calculated, along with the transaction's block number. All of the above information is then grouped into blocks according to the historical snapshot chain, also forming a chain structure based on the parent block hash values.

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

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

[0096] S301. When a client initiates a transaction, the SQL parsing module 123 parses the request and determines whether it is a transaction that calls 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 on the initiating node, generating a read-write set. The security module 122 of this node signs the transaction, and then the transaction request command, the local read-write set, and the node signature are packaged together.

[0098] S303. After the transaction is ready, the endorsement consensus module 125 is entered. First, the endorsement process is carried out 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 that the world state after executing the same command remains consistent. This is considered a successful endorsement. Then, the PBFT consensus replication process is entered.

[0099] S304. After the transaction is replicated through node consensus, the node's transaction block engine 127 packages and generates a block, and at the same time generates a historical snapshot chain based on the transaction content.

[0100] S305 and storage engine module 126 update the world state by writing transaction transactions to disk and persisting block and historical chain records to disk.

[0101] Example 2

[0102] refer to Figure 4 This is a flowchart illustrating an embodiment of the present invention, which can be applied to... Figure 1 The database system shown can also be based on other system architectures that conform to the design concept of this invention. This process describes how a client's transaction request generates transaction data in the server and stores it in the database of a data node in the database system of this embodiment. In this embodiment, depending on the specific implementation, different node roles may be implemented by the same node or by different nodes. For example, in some implementations, the node executing the endorsement process and the node storing the data are the same node; that is, the same node can perform both the function of an endorsement node and the function of a data node. As another example, in some implementations, some data nodes do not act as endorsement nodes; that is, these nodes only have the function of data nodes and do not have the function of endorsement nodes.

[0103] The method in this embodiment includes:

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

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

[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 could be to create a record of a student's basic information.

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

[0108] In the SQL command above, the client's transaction instruction instructs the table storing transaction information to be written, and the corresponding values ​​are written to its table entries.

[0109] In some implementations, the transaction instruction also includes signature information proving the client's legitimate identity. The node can verify this signature information using the aforementioned security module to determine the client's identity corresponding to the transaction instruction.

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

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

[0112] The transaction initiating node 120a uses the SQL parsing module to parse the transaction instructions from the client, parsing the SQL statements in the transaction instructions according to SQL syntax rules and converting the text into an abstract syntax tree. Based on the parsed SQL statements, the transaction initiating node 120a executes the SQL statements 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.

[0113] In some implementations, since the transaction instruction also includes signature information to prove the client's legitimate identity, the transaction initiating node will first verify the signature information upon receiving the transaction instruction. Only after determining the legitimacy of the user's identity based on the verification result will it execute the SQL statement in the transaction instruction locally.

[0114] In some implementations, after the transaction initiating node successfully executes the transaction locally, it signs the transaction, thereby generating a 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 local execution to the endorsing node for endorsement.

[0116] The database-based endorsement strategy requires the initiating node to endorse the transaction.

[0117] Unlike blockchain systems, in this embodiment, when the transaction initiating node initiates an endorsement operation, in addition to sending the SQL instruction containing the transaction execution logic to the endorser node, it also instructs the transaction initiating node to send the read-write set S(r, w) of the world state before and after the local execution of the SQL instruction to the endorser node. It is understood that in different implementations, the aforementioned SQL instruction and read-write set S(r, w) can be sent to the endorser node through the same message or the same communication process, or they can be sent to the endorser node through different messages or communication processes.

[0118] In some implementations, after a transaction initiating node successfully executes the transaction locally, it signs the transaction, generating signature information to verify the node's legitimacy. During endorsement, the transaction initiating node also sends this 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 instructions in the endorsement request locally.

[0120] The endorsing node executes the SQL statement locally, parsing it according to SQL syntax rules and converting 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 proving the client's legitimate identity, the endorsing node, upon receiving the transaction instruction, first verifies this signature information. Only after confirming the user's legitimacy based on the verification result does it execute the SQL statements in the transaction instruction locally. In other implementations, since the transaction initiating node sends signature information containing its identity to the endorsing node, the endorsing node first verifies this signature information. Only after confirming the transaction initiating node's legitimacy based on the verification result does it execute the SQL statements in the transaction instruction locally.

[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 hash the two read-write sets separately and then 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 comparison, if the results are the same, the endorsing node sends a successful endorsement message to the transaction initiating node. In some implementations, the endorsing node will also sign the transaction and send the signature information to the transaction initiating node. If the results are different, the endorsing node sends a failed endorsement message to the transaction initiating node.

[0125] S406: The transaction initiating node aggregates the collected endorsement results and determines whether the endorsement policy is satisfied. The endorsement policy can be determined based on system configuration, i.e., which nodes need to confirm the transaction execution. The endorsement policy can be specified as all-node endorsement (the transaction needs confirmation from all nodes), majority-node endorsement (e.g., the transaction needs confirmation from more than 2 / 3 of the nodes), or designated-node endorsement (e.g., the transaction needs confirmation from nodes A, B, and C). The nodes specified by the endorsement policy are the endorsing nodes. Endorsement policies are implemented on a chain-by-chain basis. If a node belongs to multiple chains, an 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 transaction proceeds to the system's consensus module for consensus. Otherwise, it indicates potential data inconsistency, the transaction is discarded, and feedback is sent to the client: Transaction failed, data may have been tampered with, manual intervention required. In the above process, if the endorsement fails, subsequent transactions involving tampered data will fail to be endorsed, but other transactions can still be executed normally, without affecting system availability.

[0128] In S408, the initiating node sends the endorsed transaction to its consensus module and reaches a consensus with other nodes. The consensus algorithm can be any existing algorithm, such as PBFT. The consensus module is responsible for authenticating and ordering distributed transactions. If consensus is reached, execution continues; otherwise, the transaction is discarded.

[0129] In one implementation, consensus on transactions is based on PBFT. Consensus is primarily used for transaction ordering; if transactions conflict, the consensus for the corresponding transaction fails, and the transaction becomes invalid. In the database system of this embodiment, PBFT requires a three-phase network.

[0130] (1) pre-prepare: After endorsement is reached, consensus is initiated by the ordering node. The ordering node can be the transaction initiating node or other nodes in the server cluster. It initiates the transaction request and sends it to other nodes in the channel. After receiving the request, other nodes determine whether there is a conflict in the information such as the read set contained in the request. If there is no conflict, they agree to the request and send it to other nodes in the channel.

[0131] (2) prepare: When more than 2f+1 nodes agree, 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, a consensus is finally reached and the transaction is committed.

[0133] S409: After consensus is reached, if an agreement is achieved, each node enters the commit phase, thereby updating the user data.

[0134] This process consists of three parts:

[0135] 1. Nodes generate blocks based on transaction requests and the read / write sets generated by executing transactions: 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 retrieving 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 into the block table to form a chain structure of blocks.

[0136] 2. Nodes generate historical records based on transaction requests and user data affected by transactions: Historical records include 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. Commit the transaction and update the user data.

[0138] Example 3

[0139] This embodiment includes a procedural description of the relationship between on-chain and off-chain transactions. For ease of description, the method flow of this embodiment references corresponding steps from the foregoing embodiments, and therefore can be implemented based on the processes in the foregoing embodiments. However, the invention described in this embodiment can also be implemented in other database systems that meet the requirements; therefore, the implementation method in this embodiment is not necessarily limited to the foregoing embodiments.

[0140] If a 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 on-chain data and the resulting read / write sets will be forwarded; for cross-chain transactions, the system will split the transaction according to the granularity of the chain in which the transaction is located, forwarding the corresponding chain's SQL statements and read / write sets separately. After receiving the endorsement result, it will be verified according to the endorsement strategies of different chains in the configuration. Only when the endorsement strategies of all chains involved in the cross-chain transaction are simultaneously satisfied will the cross-chain transaction be considered successfully endorsed.

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

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

[0143] S501: The client initiates on-chain and off-chain transaction operations, which simultaneously include 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 order in the transaction request. For both the offchain op set and the onchain op set, a transaction pre-commit is performed, generating two transaction processing logic log caches: offchain rw set and onchain rw set. At this time, other requests accessing this node will not see the update of this transaction because it has not been truly committed. At the same time, the transaction log generated by the 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 the endorsement process using the transaction log generated by the onchain op set (refer to the specific steps in Example 1 above). If the endorsement process fails, request the accepting node to roll back the on-chain and off-chain transactions, and roll back the pre-commit generated by both the offchain op set and the onchain op set. If the transaction fails, exit and return the error code to the client. If the endorsement process succeeds, proceed to the next step.

[0146] S504. The request receiving node initiates a consensus process using the transaction logs generated by the onchain op set. If the consensus process fails, the request receiving node rolls back the on-chain and off-chain transactions, and also rolls back the pre-commits generated by the offchain op set and the onchain op set. This transaction fails and exits, returning an error code to the client. If the consensus process succeeds, proceed to the next step.

[0147] S505, the requesting node will actually commit the pre-commit that includes both the offchain op set and the onchain op set. Other nodes only received the onchain op set, so they only commit the onchain op set. At this point, the requesting node has completed the on-chain and off-chain transaction operations.

[0148] The following is combined Figure 6 Let's illustrate this with a specific example:

[0149] During the Transaction prepare phase, a transaction containing both on-chain and off-chain data operations is submitted to Node 1. After Node 1 simulates execution, it obtains the OnChain tx log for on-chain data and the OffChain tx log for off-chain data. The transaction logs further include the read / write sets after the data operations and simulation execution. In the Endorse & Consensus phase, the OnChain tx log is used to reach consensus and be endorsed by Nodes 2 and 3. If consensus and endorsement are successful, the commit phase begins. Node 1 commits the transaction containing both on-chain and off-chain data, while Nodes 2 and 3 commit the transaction containing only on-chain data. If consensus and endorsement fail, Node 1 rolls back the simulated on-chain and off-chain data operations, while Nodes 2 and 3 roll back the simulated on-chain data operations.

[0150] In some implementations, to enhance disaster recovery capabilities, the OffChain data node can automatically add additional nodes and convert the OffChain data into private OnChain data.

[0151] Example 4

[0152] In another embodiment, this invention describes how to handle cross-chain characteristics between on-chain transactions, i.e., how to handle the same transaction when it involves more than two data chains. For ease of description, the method flow of this embodiment references the corresponding steps in the foregoing embodiments, and therefore can be implemented based on the flows in the foregoing embodiments. However, the invention described in this embodiment can also be implemented in other database systems that meet the conditions, therefore, the implementation method in this embodiment is not necessarily limited to the foregoing embodiments.

[0153] In existing consortium blockchains, data isolation is generally achieved through the blockchain itself; different blockchains are not interoperable and cannot access each other's data. However, in real-world business scenarios, some transactions involve the atomicity of different blockchains: a transaction may contain transactions involving multiple blockchains, and these transactions must succeed and fail simultaneously, i.e., cross-chain transactions.

[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 to record 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 chain creator updates the member information of that chain and synchronizes it to the entire system.

[0156] S702. When a client sends a transaction instruction, it needs to mark that the transaction involves cross-chain and specify which chain each transaction in the cross-chain transaction belongs to. When the server receives a cross-chain transaction request from the client, it first numbers the transactions in the transaction sequentially and then splits all the transactions in the transaction according to their respective chains.

[0157] S703. The server node parses the transaction execution logic in the splitting result and executes it locally to generate read and write sets corresponding to different chains. The node packages the split transaction execution logic, read and write sets and its own signature according to the chain it belongs to 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 server-side transaction initiating node aggregates the collected endorsement results. For cross-chain transactions, endorsement is considered successful when the endorsement results of all split transactions within the transaction conform to the endorsement policy of their respective chains. After successful endorsement, the request splitting results, each transaction number, and the chains involved in the cross-chain transaction are packaged and copied to the corresponding chain nodes for consensus processing in the system's consensus module. Each transaction number and the chains involved in the cross-chain transaction must be included as part of the transaction information, and all subsequent message copies must include this information.

[0159] S705, Submission Phase: After the current chain reaches consensus, it enters a waiting state, reads all nodes of the chains involved in the cross-chain transaction, and sends the consensus results of those chains 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 reach consensus, it is considered that the consensus of that chain has passed. If all chains involved in the transaction reach consensus, it indicates that the cross-chain consensus has passed. If a node contains multiple chains, each transaction needs to be submitted sequentially according to the transaction number. The submission of cross-chain transactions follows the submission process in the aforementioned embodiment. On-chain nodes only submit transactions related to their own chain within the transaction. If a node has joined multiple chains involved in the cross-chain transaction, it submits transactions related to each chain on different chains according to the transaction sequence number.

[0160] The following is combined Figure 8 The following example illustrates the endorsement consensus process between multiple chains:

[0161] exist Figure 8 In the process, node 0 only maintains chain 1, nodes 1 through 4 maintain both chain 1 and chain 2, and node 5 only maintains chain 2.

[0162] The consensus-building process is as follows:

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

[0164] 2. Prepare phase: All nodes on blockchain1 endorse chain1 transaction and send the result to all nodes in the form of a vote. The voting results of all nodes on blockchain1 for this transaction are counted, with >2f1 as the voting rule. Finally, the statistical result of this node for chain1 transaction is sent to all members as the commit opinion. When sending to members of this chain, the transaction information is included, while when sending to external nodes, only the success or failure of the vote is included. All nodes on blockchain2 handle chain2 transaction in a similar way.

[0165] 3. Commit Phase: Each node counts the commit opinions of all sub-transactions in the entire cross-chain transaction. Only when all sub-transactions are counted as commits will the node actually commit the cross-chain transaction. Node0 commits the chain1 transaction part, nodes1-4 commit chain1 transaction and chain2 transaction at the same time, and node5 commits the chain2 transaction part.

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

[0167] The network consists of two chains, chain1 and chain2. Chain1 contains three nodes (A, B, and C) and the smart contract test1(), while chain2 contains three nodes (C, D, and E) and the smart contract test2(). This information is stored in the system chain and is accessible to all nodes.

[0168] (1) The client initiates a transaction that is 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 the string {id:1, cmd: 'call test1()', chains: 'chain1, chain2'} to nodes A, B, and C.

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

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

[0173] For example, once chain1 consensus is passed, nodes A, B, and C will simultaneously send the consensus result to nodes C, D, and E.

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

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

[0176] The same applies to nodes A, B, and C.

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

[0178] Combination Figure 9 This is another example of the execution process described above:

[0179] In the Tx prepare phase, a transaction containing two on-chain data operations is submitted to node 2. After Node 2 simulates execution, it obtains the transaction logs for on-chain data 1 (Chain1 tx log) and on-chain data 2 (Chain2 tx log). These transaction logs further include the data operations and the read / write sets after the simulated execution. In the endorsement and consensus phase, Node 2 endorses and reaches consensus on the transaction log for on-chain data 1 (Chain1 tx log) with Node 1, and endorses and reaches consensus on the transaction log for on-chain data 2 (Chain1 tx log) with Node 3. In the consensus voting phase (Multi-consensus voting), the consensus results of all nodes on this transaction are tallied. Once consensus and endorsement are successful, the commit phase begins. Node 2 commits the transaction containing data operations for both Chain 1 and Chain 2, while Node 1 commits the transaction containing data operations for Chain 1, and Node 3 commits the transaction containing data operations for Chain 2. If consensus and endorsement fail, node 2 will roll back the transaction that simulated the execution of data operations on chain 1 and chain 2, while node 1 will roll back the transaction that simulated the data operations on chain 1, and node 3 will roll back the transaction that simulated the data operations on chain 2.

[0180] Example 5

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

[0182] The database system in this invention is based on traditional stored procedures and incorporates tamper-proof smart contracts. A stored procedure is a set of SQL statements designed to perform a specific function, stored in the database. After the initial compilation, it does not require recompilation before execution; users execute it by specifying the stored procedure's name and providing parameters. In traditional distributed database systems, stored procedures are synchronously installed on all nodes after installation. However, transactions calling stored procedures are not replicated at the "call level" (stored procedure calls are replicated at the statement level rather than at the call level). This means that when the node initiating the transaction executes a transaction that calls a stored procedure, it only executes the stored procedure once locally. Other nodes directly copy the data updated by this call, rather than executing the same stored procedure again. This design ensures strong data consistency, but if the stored procedure content is tampered with, or if the transaction is executed through a pre-defined stored procedure, other nodes cannot detect or distinguish this. This provides an opportunity for malicious nodes to tamper with the data by modifying the stored procedure content. The trusted data management system described in this paper optimizes the replication process of stored procedures by setting the replication of stored procedures to the call level. Combined with the endorsement process, it implements smart contract features: nodes execute smart contracts locally based on the contract name and parameters. The specific process is as follows:

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

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

[0185] (2) The server-side transaction receiving node executes a smart contract named Smart_Contract by passing in parameters arg1 and arg2 locally, generating a read-write set S(r, w); then it packages the smart contract name, parameters and read-write set and forwards them to the endorsing node.

[0186] (3) When the endorsing node receives the endorsement request, it calls the smart contract stored locally according to the smart contract name and parameters in the request. If the smart contract can be successfully executed locally and generate 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] In process (3), if the endorsement node fails to execute the smart contract, 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 and write set are 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 paper, it is possible to achieve that in an untrusted environment, the node updates the data through a pre-agreed program segment, while ensuring that the logic of the smart contract is not tampered with during this process.

[0188] Example 6

[0189] This embodiment describes the design of permission management in this invention.

[0190] The database system described in this invention incorporates signature information (client signature, endorsement signature) and a verification process into the lifecycle of a transaction request. This allows the server to more effectively verify the user's legitimacy and stores the request signature information in the block along with the transaction information, providing stronger traceability and non-repudiation. The specific signature and verification process is as follows:

[0191] (1) The client uses a certificate to log in, and the server verifies the validity of the certificate to determine whether the client has login privileges;

[0192] (2) The client uses its certificate to sign the request to be sent. The server verifies the validity of the certificate and signature to determine whether the user has the read and write permissions required to operate the data. If the signature is invalid, an error is reported directly; otherwise, the signature information is cached for later use in the block.

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

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

[0195] After a transaction completes its full lifecycle, the transaction structure recorded in the block will include the signature of the initiating node: this proves that the node has the necessary permissions to initiate the transaction. It will also include the signatures of endorsing nodes: this proves that the transaction content and the data before and after execution have been authenticated by the endorsing nodes. This signature verification process ensures the validity of transaction execution and the consistency and immutability of the system. In the event of any dispute regarding a transaction, liability can be determined through the signature information, guaranteeing the system's non-repudiation capability.

[0196] This system manages tables and controls access through a permissions table: When a data table is created, a new permissions record is inserted into the permissions table, recording the table creator's certificate information and the certificate information of those with read and write permissions. Combined with the signature verification process, when a transaction reads or writes data, the server first verifies whether the transaction initiator's certificate has the corresponding permissions; if not, the transaction fails. The table creator can modify read and write permissions.

[0197] In addition to the data tables, this system adds block tables and historical tables. The permissions, insertion, and updates for these two types of tables are maintained by the system based on user data transaction operations. Operations on these tables are executed by the local system of each node, without requiring on-chain node consensus synchronization. They are strongly correlated with user data transactions; that is, if all business data on a node remains consistent, then these two types of tables on all nodes will also necessarily remain consistent.

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

[0199] 1) System Chain: The system chain is built into the system and involves all users. It is used to synchronize and manage user configuration information, such as all user chains existing 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 within the system initiates a join transaction on the system chain. After consensus among all nodes on the system chain, the node information of the user chain to which the new node wants to join can be updated. If the endorsement policy changes, the same process is used to update the endorsement policy information.

[0200] 2) User Chain: Functionally consistent with the chain in traditional blockchain systems, it records user operations on the data system using a chain structure. All nodes maintain the same ledger, ensuring the consistency and immutability of the entire system. The structured storage used also greatly facilitates data traceability, analysis, and statistics.

[0201] Example 7

[0202] The methods of the embodiments of the present invention have been described in detail above, and the apparatus of the embodiments of the present invention is provided below.

[0203] The example shown in Embodiment 1 illustrates a functional module design for a server node of a database system in achieving the technical effects of this 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, hardware modules, or a combination of both.

[0204] With technological advancements, designers almost universally achieve hardware circuit structures by programming improved methodologies into hardware circuits. Therefore, a methodology can also be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user's programming of the device. Designers can program a digital system onto a PLD themselves, eliminating the need for chip manufacturers to design and fabricate dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog are the most commonly used. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0205] The above embodiments illustrate modules or units that can be implemented by computer chips or physical entities, or by products with certain functions. In existing blockchain systems, certain requirements are placed on the computing power and network communication capabilities of nodes; therefore, a typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a node, a laptop computer, etc. However, with technological advancements, the computing and communication capabilities of hardware devices will continue to improve. Therefore, it is foreseeable that in future technological implementations, various hardware devices with computing and communication capabilities can serve as node devices in blockchain systems. For example, cellular phones, smartphones, personal digital assistants, media players, in-vehicle computers, IoT devices, navigation devices, gaming devices, tablet computers, wearable devices, or any combination of these devices can all serve as node devices in a blockchain system.

[0206] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

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

[0208] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0209] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0210] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0211] In a typical configuration, such as Figure 7 As shown, a node device 70 provided in an embodiment of the present invention includes a processor 701, a memory 702 and a transceiver 703, which are interconnected via a bus.

[0212] The memory 702 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM). This memory 702 is used for related instructions and data. The transceiver 703 is used to receive and send data with other node devices or clients.

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

[0214] The processor 701 in the device 70 is used to read the program code stored in the memory 702 to execute the method steps in the foregoing method embodiments, or to implement the various functional modules in the foregoing node embodiments. Therefore, the implementation of each operation of the node device in this embodiment can be as described in the corresponding descriptions in the foregoing method embodiments.

[0215] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A data storage method, characterized by, The method is applied to a transaction initiating node in a database node cluster, and the method comprises: obtaining a transaction instruction of a client, the transaction instruction comprising a structured language SQL command; simulating execution of the SQL command to determine a first world state before simulating execution of the SQL command and a second world state after simulating execution of the SQL command; sending the SQL command, the first world state and the second world state to an endorsement node; obtaining an endorsement success instruction of the endorsement node, the endorsement success instruction indicating that a world state before simulating execution of the SQL command by the endorsement node is consistent with the first world state, and a world state after simulating execution of the SQL command by the endorsement node is consistent with the second world state; according to the endorsement success instruction, performing consensus with at least one other node in the database node cluster to instruct the other node to execute the SQL command after successful consensus.

2. The method of claim 1, wherein, The method further comprises: after the successful consensus, executing the SQL command.

3. The method of claim 1 or 2, wherein, The simulating execution of the SQL command to determine a first world state before simulating execution of the SQL command and a second world state after simulating execution of the SQL command specifically comprises: determining, according to the SQL command, a first read-write set for locally executing the SQL command, wherein a read set of the first read-write set corresponds to the first world state, and a write set of the first read-write set corresponds to the second world state.

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

5. The method of claim 2, wherein, The executing the SQL command specifically comprises: generating, according to the SQL command, a first block, the first block comprising execution logic and an execution result of executing the SQL command, and a hash value of a previous block of the first block.

6. The method of claim 5, wherein, The executing the SQL command further comprises: generating, according to the SQL command, a second block, the second block comprising an execution result after executing the SQL command, and a hash value of a previous block of the second block.

7. The method of claim 1 or 2, wherein, The transaction instruction further comprises a signature of the client; The method further comprises: verifying, according to the signature of the client, whether an identity of the client satisfies a preset condition.

8. The method of claim 1 or 2, wherein, The method further comprises: generating a signature of the transaction initiating node; When the SQL command, the first world state and the second world state are sent to the endorsement node, the method further comprises: sending the signature of the transaction initiating node to the endorsement node.

9. The method of claim 1 or 2, wherein, The endorsement success instruction further comprises a signature of the endorsement node; The method further comprises: verifying, according to the signature of the endorsement node, whether an identity of the endorsement node satisfies a preset condition.

10. The method of claim 1 or 2, wherein, The method further comprises: generating a signature of the transaction initiating node; When the consensus is performed with at least one other node in the database node cluster according to the endorsement success instruction, the signature of the transaction initiating node is sent to the other node.

11. A method of endorsing a transaction, the method comprising: The method is applied to an endorsement node in a database node cluster, and the method comprises: obtaining an SQL command, a first world state and a second world state sent by a transaction initiating node, wherein the first world state is a world state before the transaction initiating node simulates execution of the SQL command, and the second world state is a world state after the transaction initiating node simulates execution of the SQL command; simulating execution of the SQL command to determine a third world state before the endorsement node simulates execution of the SQL command and a fourth world state after the endorsement node simulates execution of the SQL command; if the first world state is consistent with the third world state and the second world state is consistent with the fourth world state, sending an endorsement success instruction to the transaction initiating node.

12. The method of claim 11, wherein, The obtaining of the SQL command, the first world state and the second world state sent by the transaction initiating node specifically comprises: obtaining an SQL command and a first read-write set sent by a transaction initiating node, wherein a read set of the first read-write set corresponds to the first world state, and a write set of the first read-write set corresponds to the second world state.

13. The method of claim 11 or 12, wherein, The method further comprises: when obtaining the SQL command, the first world state and the second world state sent by the transaction initiating node, also obtaining a signature of the transaction initiating node; and verifying whether an identity of the transaction initiating node meets a preset condition according to the signature of the transaction initiating node.

14. The method of claim 11 or 12, wherein, The method further comprises: generating a signature of the endorsement node; when sending the endorsement success instruction to the transaction initiating node, sending the signature of the endorsement node.

15. A data storage node, characterized by The node comprises at least one functional module, and the functional module is used to implement the method in claims 1-10.

16. A data storage node, characterized by The node comprises at least one functional module, and the functional module is used to implement the method in claims 11-14.

17. A data storage node, characterized by The node comprises 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 in any one of claims 1-10.

18. A data storage node, characterized by, The node comprises 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 in any one of claims 11-14. 19.A blockchain system, characterized in that, The blockchain system comprises the node in any one of claims 15-18.

Images