WO2023160095A1

WO2023160095A1 - Method and system for implementing structured data storage and queries in blockchain system

Info

Publication number: WO2023160095A1
Application number: PCT/CN2022/135638
Authority: WO
Inventors: 何家华; 俞本权; 田世坤
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-02-28
Filing date: 2022-11-30
Publication date: 2023-08-31
Also published as: CN114564500A

Abstract

The embodiments of the present description disclose a method and system for implementing structured data storage and queries in a blockchain system. The method comprises: during a transaction execution process, storing and querying data by using a relational database.

Description

Method and system for implementing structured data storage and query in blockchain system

This application claims the priority of the Chinese patent application with the application number 202210185170.6 and the title of the invention "Method and System for Realizing Structured Data Storage and Query in Blockchain System" submitted to the China Patent Office on February 28, 2022. The entire contents of which are incorporated by reference in this application.

technical field

This specification relates to the field of information technology, in particular to methods and systems for implementing structured data storage and query in blockchain systems.

Background technique

In the blockchain system, smart contracts are the carrier of business logic. Some blockchain systems only provide a k-v (key-value, key-value pair) query interface, that is, in a smart contract, only a single data query method that provides a key to query the value associated with the key is supported, lacking more efficient and flexible data Query methods (such as conditional query, range query, joint query across tables, etc.), lead to various restrictions on the development of business logic.

Therefore, it is hoped to provide a blockchain storage solution with stronger data query capabilities.

Contents of the invention

One of the embodiments of this specification provides a method for implementing structured data storage and query in a blockchain system, the method comprising: using a relational database for data storage and query during the execution of a blockchain transaction.

One of the embodiments of this specification provides a system for implementing structured data storage and query in a blockchain system, and the system for implementing structured data storage and query is used to: use relational Database for data storage and query.

One of the embodiments of this specification provides a device for implementing structured data storage and query in a blockchain system. The device includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, it realizes the structured data storage in the blockchain system as described in any embodiment of this specification and query methods.

One of the embodiments of this specification provides a blockchain transaction execution method. The method includes: obtaining one or more transactions to be executed; executing the one or more transactions, wherein state data related to the one or more transactions is read and written using a relational database.

One of the embodiments of this specification provides a blockchain transaction execution system. The system includes: a transaction acquisition module, used to acquire one or more transactions to be executed; a transaction execution module, used to execute the one or more transactions, wherein a relational database is used to pair with the one or more Transaction-related state data is read and written.

One of the embodiments of this specification provides a blockchain transaction execution device. The apparatus includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the blockchain transaction execution method described in any embodiment of this specification is implemented.

Description of drawings

FIG. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification;

Fig. 2 is an exemplary flow chart of a blockchain transaction execution method according to some embodiments of this specification;

Fig. 3 is an exemplary block diagram of a blockchain transaction execution system according to some embodiments of this specification;

Fig. 4 is a schematic diagram of a storage module for implementing structured data storage and query according to some embodiments of the present specification.

Detailed ways

In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the following briefly introduces the drawings that need to be used in the description of the embodiments. Apparently, the accompanying drawings in the following description are only some examples or embodiments of this specification, and those skilled in the art can also apply this specification to other similar scenarios. Unless otherwise apparent from context or otherwise indicated, like reference numerals in the figures represent like structures or operations.

It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, components, parts or assemblies of different levels. However, the words may be replaced by other expressions if other words can achieve the same purpose.

As indicated in this specification, words such as "a", "an", "an" and/or "the" are not specific to the singular and may include the plural unless the context clearly indicates an exception. Generally speaking, the terms "comprising" and "comprising" only suggest the inclusion of clearly identified steps and elements, and these steps and elements do not constitute an exclusive list, and the method or device may also contain other steps or elements.

The flowchart is used in this specification to illustrate the operations performed by the system according to the embodiment of this specification. It should be understood that the preceding or following operations are not necessarily performed in the exact order. Instead, various steps may be processed in reverse order or simultaneously. At the same time, other operations can be added to these procedures, or a certain step or steps can be removed from these procedures.

Fig. 1 is a schematic diagram of an application scenario of a blockchain system according to some embodiments of this specification. As shown in FIG. 1 , the blockchain system 100 may include a client 110 , a blockchain network 120 and a network 130 .

The client 110 may be a terminal using blockchain services, which may be linked to a certain node in the blockchain network 120 through the network 130 . The client 110 can initiate a transaction, that is, generate a transaction and send the generated transaction to the blockchain network 120 , so that the transaction is broadcast on the blockchain network 120 .

It should be noted that the transactions appearing in this specification specifically refer to blockchain transactions, which are used to trigger various events in the blockchain system 100 . For example, the event may include one or more of the joining of a new node, the exit of a node, transfer, data deposit, etc. In some embodiments, the certified data may include one or more of medical information, electronic contracts, electronic credentials, electronic orders, digital fingerprints, and the like.

Smart contracts (referred to as contracts) are modular, reusable, and automatically executed scripts that run on the blockchain. When the contract is deployed, the contract code (such as bytecode) is stored in each blockchain node, and each (part) contract corresponds to a contract address. When a predetermined condition occurs, a transaction pointing to the contract address can be generated, and all blockchain nodes in the blockchain network 120 can execute the contract code and write the execution result into the blockchain data. That is, the code in the smart contract can be triggered by a transaction, which can also be called the execution of the transaction. As an example only, a transfer transaction can trigger the update of the account balance of both parties to the transfer, a data deposit transaction can trigger the data to be deposited into the blockchain data, a data query transaction can trigger the reading of the blockchain data, etc. wait.

The blockchain network 120 may include multiple blockchain nodes, for example, node 120-1, node 120-2, node 120-3, . . . , node 120-n in FIG. 1 . After any blockchain node receives the transaction initiated by the client 110 , it can forward the transaction to other nodes, so that the transaction is broadcasted on the blockchain network 120 . A blockchain node may collect transactions broadcast in the blockchain network 120 and generate a block based on one or more transactions. Among them, the prerequisite for generating a valid block may include: the blockchain nodes participating in the consensus reach a consensus on the execution result of the transaction on which the block is generated (consensus is passed). In addition, blockchain nodes can also initiate transactions.

Based on the consensus mechanism, the blockchain data stored by each blockchain node in the blockchain network 120 can be consistent.

Blockchain data can include block data and state data.

Among them, the block data includes a data chain (that is, a block chain) in which multiple blocks are linked in order of generation time, and the block data has the property of being unmodifiable. A block may include two parts: a block header and a block body, where the key information (or summary information) of the block can be written in the block header, and the detailed information of the block can be written in the block body. For example, block timestamp, block hash value (of this block), block hash value of parent block (previous block), block height, and Merkle tree can be written in the block header. Root hash, etc., where the block timestamp can reflect the generation time of the block, the block hash value can be calculated based on the content in the block header, and the block height can reflect which block is generated . A transaction list, transaction receipt list, etc. can be written in the block body. The transaction list includes one or more transactions based on which the block is generated (which can be collectively referred to as transactions in the block). The transaction receipt list includes one or more transactions in the block. Receipts for multiple transactions.

Transactions can be written into the transaction list in the form of key-value pairs (k-v), key (key/keyword, can be abbreviated as k) is the transaction ID, and value (value, can be abbreviated as v) is each field of the transaction. As an example only, the various fields of the transaction may include the account address of the transaction initiator, the transaction timestamp, the amount the transaction initiator is willing to pay for the transaction, the account address of the calling smart contract, the name of the function in the calling smart contract, the provided Input to the function, etc.

State data is blockchain data that supports addition, deletion, query, and modification. Key-value pairs (k-v) can be used to store state data, k is the identification (name/ID) of state data, and v is the value (such as value) of state data. For example, state data may include the world state composed of the state of all blockchain accounts (account state). The account status can be stored in the form of k-v, where k is the account identifier (also called the account address), and v is the value of the account status. The account status can include the account balance. For the contract account associated with the smart contract, the account status can also include the hash value of the smart contract code and the status stored in the account of the smart contract.

Each smart contract (account) can have a corresponding storage, and correspondingly, the state data can also include the storage of the smart contract. The storage of smart contracts can include contract code (such as bytecode) and account storage. Among them, account storage can save contract variables. Contract variables can be stored in the form of k-v, where k is the variable name and v is the variable value. Specifically, the k of the contract variable can be the name (address) of the asset account, and the v of the contract variable can be the balance of the asset account. Further, the balance may include k-v corresponding to different asset types, k may be an asset type (such as RMB, USD, etc.), and v may be the balance of the asset type. Logically, state data in the form of key-value pairs (multiple key-value pairs) can be organized into the form of a Merkle tree. The underlying database can be constructed based on a Merkle tree, and this database can be called a Merkle tree-based database.

A Merkle tree is a hash binary tree, which is a data structure for quickly summarizing and verifying the integrity of large-scale data. SPV (Simplified Payment Verification, simple payment verification) makes full use of this feature of the Merkle tree. In the case of saving less blockchain data, for example, when only the block header is saved but not the block body, the blockchain network The SPV node in 120 (also called light node/light client, which can be the client 110) can also perform relevant verification, such as verifying whether the transaction exists, whether the transaction belongs to a certain block, etc.

In some embodiments, the Merkle tree used to record state data may include one or more of a state tree, a transaction tree, a receipt tree, a storage tree, and the like. Among them, the state tree is used to save the state of the world. Each block can correspond to a transaction tree, and the transaction tree of each block is used to save all transactions in the block. Each block can correspond to a receipt tree, and the receipt tree of each block is used to save the execution results of all transactions in the block. Each smart contract can correspond to a storage tree, which is used to save the account storage of the smart contract.

In some embodiments, the Merkle tree used to record state data may include an MPT (Merkle Patricia Tree) tree, and the MPT tree combines the characteristics of a Merkle tree (Merkle Tree) and a compressed prefix tree (Patricia Tree). Reduce storage overhead and improve query efficiency.

The hash value of the root node of the Merkle tree (referred to as the root hash) is stored in the block (header). Any change to the state data recorded in the Merkle tree will cause a change in the root hash. Therefore, Merkle The tree can provide a data proof function (SPV function). For blockchain systems that rely on the k-v interface for data query, the single query mode of obtaining the complete value (that is, all fields of the state data) based on the key can only realize limited business logic, and (large) part of the business logic still needs to be implemented off-chain (Even reliability needs to be considered separately), causing problems such as development difficulties, inconsistent off-chain systems, and difficulty in upgrading.

To this end, the embodiment of this specification provides a method and system for implementing structured data storage and query in a blockchain system. During transaction execution, blockchain nodes can store and query data based on relational data. For the details of reading and writing involved in the transaction execution process and block generation process, you can refer to Figure 2 and its related descriptions, and will not repeat them here.

Relational databases are used to store structured data. Structured data is data that is logically expressed and realized by a two-dimensional table structure. In a two-dimensional table, each row can be used to store various fields of the same entry, and each column can correspond to a field. It can be understood that, for state data represented by key-value pairs, each row of the two-dimensional table may correspond to a key of the same state data, and each column in the table may correspond to a certain field of the state data. Taking transactions as an example, a relational database can include a transaction table, and each row of the transaction table can store various fields of the same transaction, such as the account address of the transaction initiator, the address of the destination contract account, and the transaction timestamp (indicating the generation time of the transaction) , cost information, etc.

Structured features make data easy to store and query. Relational databases can provide efficient storage according to the structural rules of blockchain data. Relational databases can also provide efficient and flexible query functions by indexing specific fields in the blockchain data. For example, conditional queries and range queries for specific fields can be realized through indexes. Just as an example, by indexing transaction timestamps, smart contract developers can write statements that query transactions generated in a specific time period, and then implement richer business logic in smart contracts.

In some embodiments, the interaction between the smart contract and the underlying relational database can be performed through an abstraction layer for data reading and writing. Specifically, developers can use APIs for data storage and query when writing contract codes. In this way, developers are provided with many conveniences, including but not limited to: developers do not need to worry about string escaping and other trivial matters, which are automatically handled by the machine; compile-time checks ensure type safety and reduce the chance of developers making mistakes; The interface is exposed in the form of a list to prevent developers from using unimplemented functions by mistake.

In some embodiments, the nodes in the client 110/block chain network 120 may include various types of computing devices, such as laptop computers, desktop computers, servers, and so on. Wherein, the server may be an independent server or a server group, and the server group may be centralized or distributed. In some embodiments, servers may be regional or remote. In some embodiments, the server may execute on a cloud platform. For example, the cloud platform may include one of private cloud, public cloud, hybrid cloud, community cloud, decentralized cloud, internal cloud, etc. or any combination thereof. In some embodiments, the client 110 and the blockchain node can be integrated on the same computing device.

The network 130 connects the various components of the system so that communication between the various components is possible. Networks between parts of the system may include wired and/or wireless networks. For example, network 130 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public Switched Telephone Network (PSTN), Bluetooth Network, ZigBee Network (ZigBee), Near Field Communication (NFC), In-Device Bus, In-Device Wire, Cable Connection, etc. or any combination thereof. The network connection between each two parts may adopt one of the above methods, or may adopt multiple methods. It can be understood that the network 130 and the blockchain network 120 do not have to have a clear boundary. In a more general application scenario, blockchain nodes and ordinary network nodes can be connected to the same physical network. form a blockchain network.

Fig. 2 is an exemplary flowchart of a blockchain transaction execution method according to some embodiments of this specification. Process 200 can be executed by any blockchain node. The process 200 can occur in multiple possible scenarios, for example, in the scenario of generating a new block based on one or more transactions, in the catch-up block (including executing one or more transactions based on the generation of the old block, to synchronize blockchain data) scenario. As shown in Figure 2, the process 200 may include:

Step 210, acquire one or more transactions to be executed.

In the scenario of generating a new block, the blockchain node may generate a new block based on one or more transactions received within a period of time, and the one or more transactions need to be executed during the process of generating the new block.

In the scenario of catching up with the block, the blockchain node also needs to execute one or more transactions on which the old block is generated, wherein the blockchain node can obtain the old block from other nodes in the blockchain network 120, And obtain one or more related transactions based on the old block.

Step 220, execute the one or more transactions, wherein state data related to the one or more transactions is read and written using a relational database.

It can be understood that the execution of any transaction may only include reading (query) or writing (adding) relevant state data, or both reading (query) and Contains write (new/modified) related state data. Wherein, the state data read and the state tree data written due to execution of the same transaction may be the same or different (only part of the same or no intersection at all). In addition, the execution of any transaction can also include deleting related state data from the relational database.

In some blockchain systems, blockchain nodes simulate execution of multiple transactions received. During the simulation execution process, the blockchain nodes execute the multiple transactions concurrently, during which the read-write sets of the multiple transactions are generated, and based on the read-write sets, the difference between different transactions (assumed to be the first transaction and the second transaction) is judged. Whether there is a read-write conflict, if yes, abandon the formal execution of one of the first transaction and the second transaction. For ease of description, the transaction can be regarded as the execution subject of reading and writing, which aims to indicate that reading and writing occurs due to the execution of which transaction. The read-write set of a transaction refers to the set of data stored in read-write during the execution of the transaction, including the read-set and write-set. The read set can contain the key of the state data read by the transaction, the write set can contain the key and its value of the state data written by the transaction, and the write set can also contain a key with a delete flag to indicate that the key is deleted. A read-write conflict means that the state data read by one transaction overlaps with the data written by another transaction, and it can be judged whether there is a read-write conflict based on the key in the read-write set of the two transactions.

After the client 110 confirms that the initiated transaction has been abandoned (officially) executed, it can re-initiate a transaction (hereinafter referred to as transaction retry), and some of the contents of the two transactions are the same (the content that the user can perceive and hope to be successful on the chain is the same). It can be understood that the blockchain nodes do not update the blockchain data during the simulated execution of the transaction, but update the blockchain data during the formal execution of the transaction (for example, after the consensus is passed). The mechanism of simulated execution prevents blockchain nodes from reading the state data written in the current block generation process, but can only read the state data submitted in the generation process of the previous block (valid block generated after the consensus was passed).

In contrast, since the relational database satisfies the ACID characteristics of transactions, using the relational database to read and write state data related to the one or more transactions can ensure the correctness and reliability of transaction execution. It can be understood that the execution of a transaction may include a transaction responsible for reading and writing state data.

Transactions and their ACID properties are explained below.

A transaction consists of one or more operations. Transactions must meet ACID characteristics, namely Atomicity, Consistency, Isolation and Durability.

Atomicity means: all operations in a transaction are either executed or not executed at all. If an error occurs during the execution of the transaction, the data should be rolled back (restored) to the state before the execution of the transaction, as if the transaction had never happened . For ease of description, a transaction can be regarded as the execution subject of the operations contained in the transaction.

Consistency means: before and after the transaction, the constraints on the data will not be broken, that is, the data written to the database must comply with all preset rules, which can include data accuracy, seriality, and subsequent database can spontaneously Complete the scheduled work. For example, if you want to transfer 100 from account A to account B, you must subtract 100 from account A and add 100 to account B, and the problem of unequal increase and decrease cannot occur.

Isolation means that a transaction is invisible to other transactions until all the modifications involved are completed, that is, it is impossible to know the intermediate state in the process of executing the transaction while executing other transactions.

Persistence means that after a transaction is completed, the execution result of the transaction must be persisted. Even if the database crashes, the execution result of the committed transaction will not be lost after the database is restored.

Among them, isolation means that multiple concurrent operations are isolated from each other (do not interfere). Isolation is crucial in database operations. If isolation is not considered, problems such as dirty reads, non-repeatable reads, and phantom reads may occur.

Dirty read refers to: transaction T1 reads the uncommitted data of transaction T2, and as a result, a state rollback is performed for transaction T2, resulting in transaction T1 getting dirty data.

Non-repeatable reading means that after transaction T1 reads data D, data D is updated by transaction T2, resulting in inconsistent data when data D is read again during the execution of transaction T1.

Phantom reading means: transaction A reads data according to certain conditions, during which transaction B inserts new data that meets the same search conditions, and when transaction A reads data according to the conditions again, it finds the newly inserted data of transaction B.

In response to the above problems, the database can provide four isolation levels from low to high: Read uncommitted, Read Committed, Repeated Read, and Serializable. Among them, read uncommitted cannot ensure that any problem will not occur, read committed (Read Committed) can ensure that dirty read problems will not occur, repeatable reads can ensure that dirty reads and non-repeatable reads will not occur, and serialization can ensure that Dirty, non-repeatable reads, and phantom reads do not occur.

In some embodiments, when the one or more transactions include two or more transactions, the blockchain nodes may execute the two or more transactions concurrently. For different transactions among the two or more transactions (assumed to be the first transaction and the second transaction), the blockchain node can determine whether there is a read-write conflict between the first transaction and the second transaction. If not, the two transactions are successfully executed concurrently, which can ensure the efficient execution of the transaction. If yes, perform state rollback for one of the first transaction and the second transaction, and re-execute one of the first transaction and the second transaction after the execution of the other transaction is completed. That is, reads and writes to the same state data are isolated through transaction serialization. For the read-write set of transactions and read-write conflicts, you can also refer to the relevant descriptions above.

As an example only, assume that transaction A and transaction B trigger the update of the balance of the same account. The balance of the account is represented by amount (ie key/key). Before executing transaction A and transaction B, amount=100. The specific deduction logic is If the account balance is sufficient, 60 will be deducted, otherwise the deduction will fail. Obviously, if the isolation is not considered, it may happen that before any transaction is deducted, the account balance is found to be sufficient (that is, greater than 60), so both transaction A and transaction B subtract 60 from the account balance, causing the account balance to become negative number. If transaction A and transaction B are executed according to the isolation requirements, the blockchain nodes can execute transaction A and transaction B concurrently. After discovering that both transaction A and transaction B trigger the update of the amount, the blockchain node can perform a state rollback for one of the transactions (maybe set it as transaction A), and execute transaction B again after transaction A is executed. In this way, when transaction B is executed again, the blockchain node will find that the account balance is insufficient, and then the deduction will fail, which will not cause the account balance to become negative.

It can be seen that compared with simulated execution, transaction concurrency based on transaction isolation can reduce transaction retries and provide support for Read-Your-Writes semantics. Read-Your-Writes means "read what you write", which means that after a node updates a piece of data (such as the aforementioned amount), it can always access the latest value it has updated.

In some embodiments, if the blockchain system needs to support the SPV function, while the blockchain node stores the state data related to the one or more transactions based on the relational database, it can also store the state data related to the one or more transactions based on the Merkel The tree's database stores state data associated with the one or more transactions. Among them, storing generally refers to adding state data, deleting existing state data, and modifying existing state data (modifying value). That is, the dual writing of state data is realized through a relational database and a Merkle tree-based database to meet SPV requirements while providing powerful data query capabilities.

In the scenario of generating a new block, the blockchain nodes may also perform consensus on the execution results of the one or more transactions to generate a block. Understandably, the purpose of consensus is to generate identical and correct (valid) blocks. After the consensus is passed, each blockchain node can add the same block to the blockchain.

In some embodiments, the blockchain node may also write the read-write set of the one or more transactions into a block, for example, into a block body. In this way, arbitrary data tampering will cause the consensus to fail, thus ensuring the immutability of the blockchain.

It should be noted that, the above descriptions about the process are only for illustration and description, and do not limit the scope of application of this specification. For those skilled in the art, various modifications and changes can be made to the flow under the guidance of this specification. However, such modifications and changes are still within the scope of this specification.

Fig. 3 is a block diagram of a blockchain transaction execution system according to some embodiments of this specification. As shown in FIG. 3 , the system 300 may include a transaction acquisition module 310 and a transaction execution module 320 .

The transaction obtaining module 310 may be used to obtain one or more transactions to be executed.

Transaction execution module 320 may be configured to execute the one or more transactions. Wherein, the transaction execution module 320 may use a relational database to read and write status data related to the one or more transactions.

In some embodiments, the system 300 may further include a storage module as shown in FIG. 4 , which is used for data storage and query using a relational database during transaction execution. That is, the transaction execution module 320 can call the storage module to read and write state data during the execution of the transaction. The function of the storage module can be further refined, that is, the storage module can be regarded as a subsystem in the system 300, which is used to implement structured data storage and query in the blockchain system 100.

It can be understood that the system 300 can be included in a larger system, such as included in a block generation system, and the block generation system can also include a consensus module, which is used to verify the execution results of the one or more transactions Consensus is performed to generate blocks.

For more details about the system 300 and its modules, refer to FIG. 2 and its related descriptions.

It should be understood that the system and its modules shown in FIG. 3 can be implemented in various ways. For example, in some embodiments, the system and its modules may be implemented by hardware, software, or a combination of software and hardware. Wherein, the hardware part can be implemented by using dedicated logic; the software part can be stored in a memory and executed by an appropriate instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above can be implemented using computer-executable instructions and/or contained in processor control code, for example on a carrier medium such as a magnetic disk, CD or DVD-ROM, such as a read-only memory (firmware ) or on a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification can not only be realized by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc. , can also be realized by software executed by various types of processors, for example, and can also be realized by a combination of the above-mentioned hardware circuits and software (for example, firmware).

It should be noted that the above description of the system and its modules is only for convenience of description, and does not limit this description to the scope of the illustrated embodiments. It can be understood that for those skilled in the art, after understanding the principle of the system, it is possible to combine various modules arbitrarily, or form a subsystem to connect with other modules without departing from this principle. For example, in some embodiments, the transaction acquisition module 310 and the transaction execution module 320 may be different modules in one system, or one module may realize the functions of these two modules. Such deformations are within the protection scope of this specification.

The possible beneficial effects of the embodiments of this specification include but are not limited to: (1) Using a relational database to store structured blockchain data can provide efficient and flexible data storage and query functions; (2) The relational database meets The ACID characteristics of transactions can ensure the correctness and reliability of transaction execution; (3) transaction concurrency based on transaction isolation can reduce transaction retries and provide support for Read-Your-Writes semantics; (4) through Relational databases and databases based on Merkle trees implement double writing of state data, which can meet SPV requirements while providing powerful data query capabilities. It should be noted that different embodiments may have different beneficial effects. In different embodiments, the possible beneficial effects may be any one or a combination of the above, or any other possible beneficial effects.

The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only an example, and does not constitute a limitation to the embodiment of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and amendments to the embodiments of this specification. Such modifications, improvements and corrections are suggested in the embodiments of this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

Meanwhile, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and/or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that two or more references to "an embodiment" or "an embodiment" or "an alternative embodiment" in different places in this specification do not necessarily refer to the same embodiment . In addition, certain features, structures or characteristics in one or more embodiments of this specification may be properly combined.

In addition, those skilled in the art will understand that all aspects of the embodiments of this specification can be illustrated and described by several patentable categories or situations, including any new and useful process, machine, product or combination of substances, or Any new and useful improvements to them. Correspondingly, various aspects of the embodiments of this specification may be completely executed by hardware, may be completely executed by software (including firmware, resident software, microcode, etc.), or may be executed by a combination of hardware and software. The above hardware or software may be referred to as "block", "module", "engine", "unit", "component" or "system". In addition, aspects of the embodiments of this specification may be embodied as a computer product on one or more computer-readable media, the product including computer-readable program code.

A computer storage medium may contain a propagated data signal embodying a computer program code, for example, in baseband or as part of a carrier wave. The propagated signal may have various manifestations, including electromagnetic form, optical form, etc., or a suitable combination. A computer storage medium may be any computer-readable medium, other than a computer-readable storage medium, that can be used to communicate, propagate, or transfer a program for use by being coupled to an instruction execution system, apparatus, or device. Program code residing on a computer storage medium may be transmitted over any suitable medium, including radio, electrical cable, fiber optic cable, RF, or the like, or combinations of any of the foregoing.

The computer program codes required for the operation of each part of the embodiments of this specification can be written in any one or more programming languages, including object-oriented programming languages such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET , Python, etc., conventional programming languages such as C language, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may run entirely on the user's computer, or as a stand-alone software package, or run partly on the user's computer and partly on a remote computer, or entirely on the remote computer or processing device. In the latter case, the remote computer can be connected to the user computer through any form of network, such as a local area network (LAN) or wide area network (WAN), or to an external computer (such as through the Internet), or in a cloud computing environment, or as a service Use software as a service (SaaS).

In addition, unless clearly stated in the claims, the sequence of processing elements and sequences, the use of numbers and letters, or the use of other names in the embodiments of this specification are not used to limit the sequence of the processes and methods of the embodiments of this specification. While the foregoing disclosure has discussed by way of various examples some embodiments of the invention that are presently believed to be useful, it should be understood that such detail is for illustrative purposes only and that the appended claims are not limited to the disclosed embodiments, but rather, the claims The claims are intended to cover all modifications and equivalent combinations that fall within the spirit and scope of the embodiments of this specification. For example, while the system components described above may be implemented as hardware devices, they may also be implemented as a software-only solution, such as installing the described system on an existing processing device or mobile device.

Similarly, it should be noted that, in order to simplify the description of the disclosure of the embodiments of this specification, so as to facilitate the understanding of one or more embodiments of the invention, in the foregoing descriptions of the embodiments of this specification, sometimes multiple features are combined into one implementation examples, drawings or descriptions thereof. However, this method of disclosure does not imply that the embodiments of the present specification require more features than those recited in the claims. Indeed, embodiment features are less than all features of a single foregoing disclosed embodiment.

Each patent, patent application, patent application publication, and other material, such as article, book, specification, publication, document, etc., cited in this specification is hereby incorporated by reference in its entirety. Application history documents that are inconsistent with or conflict with the content of this specification are excluded, and documents (currently or later appended to this specification) that limit the broadest scope of the claims of this specification are also excluded. It should be noted that if there is any inconsistency or conflict between the descriptions, definitions, and/or terms used in the accompanying materials of this manual and the contents of this manual, the descriptions, definitions and/or terms used in this manual shall prevail .

Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other modifications may also fall within the scope of the embodiments of this specification. Therefore, by way of illustration and not limitation, alternative configurations of the embodiments of this specification may be considered consistent with the teachings of this specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly introduced and described in this specification.

Claims

A method for implementing structured data storage and query in a blockchain system, including:

A relational database is used for data storage and query during the execution of blockchain transactions.
The method of claim 1, further comprising:

The read-write set of blockchain transactions is written to the block during block generation.
The method according to claim 1 or 2, wherein a Merkle tree-based database is also used for data storage during the block generation process.
The method according to claim 1, wherein the use of a relational database for data storage and query during the execution of blockchain transactions includes:

For the first block chain transaction and the second block chain transaction in two or more block chain transactions executed concurrently, it is judged whether there is Read and write conflicts, if so, execute state rollback for one of the first block chain transaction and the second block chain transaction, and re-execute the first block chain transaction after the execution of the other block chain transaction one of the block chain transaction and said second block chain transaction.
A system for implementing structured data storage and query in a block chain system, wherein the system for implementing structured data storage and query is used for:

A relational database is used for data storage and query during the execution of blockchain transactions.
A device for implementing structured data storage and query in a blockchain system, including a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the implementation of claim 1 The method described in any one of ~4.