WO2021139109A1

WO2021139109A1 - Method and apparatus for writing into state database, electronic device, and storage medium

Info

Publication number: WO2021139109A1
Application number: PCT/CN2020/099087
Authority: WO
Inventors: 陈沐豪; 褚镇飞
Original assignee: 平安科技（深圳）有限公司
Priority date: 2020-01-09
Filing date: 2020-06-30
Publication date: 2021-07-15
Also published as: CN111241061A; CN111241061B

Abstract

A method and apparatus for writing into a state database, an electronic device, and a storage medium, which relate to blockchain technology. The method comprises: after receiving simulation results for multiple blocks that are sent by a sort node, acquiring block information of the multiple blocks; sequentially reading read and write sets of a target block, determining, on the basis of data in a cache and a state database, whether transaction data in the read and write sets of the target block is valid, and writing the read and write set corresponding to valid transaction data of the target block into the cache; and using a means of background execution to read from the cache the data corresponding to the target block and writing same into the state database. Thus, the efficiency and accuracy of writing into a state database are increased.

Description

State database writing method, device, electronic equipment and storage medium

This application claims the priority of the Chinese patent application filed with the Chinese Patent Office on January 9, 2020, the application number is CN202010024089.0, and the invention title is "state database writing method, data processing device and storage medium", all of which The content is incorporated in this application by reference.

Technical field

This application relates to the field of blockchain technology, and in particular to a method, device, electronic device, and storage medium for writing a state database.

Background technique

The block chain completes the transaction packaging, that is, after the consensus is completed, a new block is generated. Afterwards, it is necessary to pre-execute the transaction in the block to obtain the pre-execution result to complete the transaction and update the database, that is, to settle the account. The blockchain belongs to a chained data structure, and each block points to the previous block. Therefore, to verify the validity of the data, each block needs to be verified sequentially. In order to ensure that the assets in the transaction are consistent, the transactions in the block must be pre-executed in order, that is, the transactions related to the account need to be sequenced. In other words, for a node that newly joins the blockchain network, it needs to synchronize all historical block data and verify the validity one by one before starting to synchronize the latest block.

technical problem

The inventor realizes that historical block data is often very large, and therefore, the synchronization process takes a long time, resulting in a waste of time and machine performance.

Technical solutions

This application provides a method, device, electronic device, and computer-readable storage medium for writing a state database.

This application provides a method for writing a state database, and the method includes:

In the receiving step, after receiving the simulation results of several blocks sent by the ordering node, obtain the block information of the several blocks;

The first writing step is to sequentially read the read and write set of the target block from the block information of the several blocks, and determine the read and write set of the target block based on the data in the preset cache and the state database Whether the transaction data is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache the reads of valid transactions in each block in the blockchain network Writing set; and

The second writing step is to read the data corresponding to the target block from the cache in a background execution manner, and write the data corresponding to the target block into the state database.

This application also provides a device for writing a state database, the device including:

The receiving module is used to obtain the block information of the several blocks after receiving the simulation results of the several blocks sent by the ordering node;

The first write module is used to sequentially read the read and write set of the target block from the block information of the several blocks, and determine the read and write of the target block based on the data in the preset cache and the state database Whether the centralized transaction data is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache valid transactions in each block in the blockchain network Read and write set; and

The second writing module is configured to read the data corresponding to the target block from the cache in a background execution manner, and write the data corresponding to the target block into the state database.

The present application also provides an electronic device, the electronic device comprising: a memory, a processor, the memory stores a state database write program that can be run on the processor, and the state database write program is When the processor executes, the following steps are implemented:

The present application also provides a computer-readable storage medium that includes a state database writing program, and the state database writing program is executed by a processor to implement the following steps:

Description of the drawings

FIG. 1 is a flowchart of a preferred embodiment of a method for writing into a state database of this application;

FIG. 2 is a schematic diagram of a preferred embodiment of the electronic device of this application;

Fig. 3 is a schematic diagram of modules of the writing device of the state database of the present application.

The realization, functional characteristics, and advantages of the purpose of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings.

Embodiments of the present invention

It should be understood that the specific embodiments described here are only used to explain the present application, and are not used to limit the present application.

This application provides a method for writing a state database. Referring to FIG. 1, it is a flowchart of a preferred embodiment of a method for writing a state database according to this application. The method can be executed by an electronic device, and the electronic device can be implemented by software and/or hardware.

In this embodiment, the method for writing the state database only includes steps S10-S30.

A method for writing a state database is applied to transaction nodes in a blockchain network, and the method includes:

Step S10, after receiving the simulation results of several blocks sent by the ordering node, obtain block information of the several blocks.

In the following embodiments, the electronic device corresponding to the transaction node is used as the execution subject to describe the embodiments of the present application. The blockchain network includes transaction nodes, submission nodes, and consensus nodes. The transaction process based on the blockchain network is roughly as follows:

1. The client creates a transaction proposal and sends it to the transaction node (the endorsement node corresponding to the smart contract (chaindode), that is, the peer node designated by the smart contract that can verify the transaction);

2. The transaction node executes the smart contract and generates a read and write operation set (fabric read and write set) based on the read and write keys;

3. The transaction node returns the proposal result (the simulation result generated when the transaction node executes the smart contract) to the client;

4. The client submits the transaction data to the consensus node (Orderer), and the transaction data includes the read-write set from the proposal;

5. The consensus node packs the sorted transaction into the block;

6. The block sends the proposal result to the submitting node (if the proposal result is successful, the proposal result is sent to the sorting node, and the sorting node will broadcast the transaction to other transaction nodes);

7. Submit the node to perform the following operations:

1) MVCC multi-version control (Multi-Version Concurrency Control), read the latest value in the state database (state db), and verify the validity of the transaction;

2) Write the new block to the block chain on the file system (the transaction data is packaged into blocks, and the block is written into the block chain), and the valid transactions in the block are written into the state database, and write Database checkpoint.

In the seventh step, each block executes steps 1 and 2 in sequence, and the performance is relatively low.

For example, now in the ledger, A=100 yuan, transaction P consumes 90 yuan, and the simulation result is A=10. When the result has not been submitted to the ordering node, transaction Q consumes 20 yuan, and the simulation result is A=80. At this time, The simulation results of the two transactions are submitted to the sorting node. When the MVCC is executed, it will be found that the transactions P and Q are based on the premise of A=100. Therefore, it will be determined that one of the transactions of P and Q has failed (among which, the first submitted to the sorting node The transaction is successful, and the submitted one is set as invalid).

The steps before improvement are as follows: input a block, the transaction node reads the read-write set in the block, compares the data in the read-write set with the latest data in the state database, and judges which data in the read-write set is valid , Which are invalid. Specifically, the transaction node obtains transaction information from the ordering node and verifies whether the transaction is valid. By obtaining the value in the read-write set, compare it with the local state database to determine whether the transaction is valid. This process is called MVCC. Then write the block information into the ledger. Then, update the read-write set information of valid transactions in the previous step to the state database. After the information of the block is written, write the checkpoint information. Then, repeat the above steps for the next block. However, the problem with the above steps is that the process of writing the state database is sequential, and writing the state database is an IO-intensive operation. If a single block is required to write the state database in order, the performance impact will be relatively large.

After the transaction node receives the simulation result (proposal result) sent by the ordering node, it obtains the block information of each block in the order of the block number of each block. Among them, the block information of each block includes: transaction information of multiple transactions, whether the transaction is valid, the read-write set corresponding to the transaction, the smart contract and the block chain corresponding to each transaction. In the blockchain network, one chain corresponds to a state database, all blocks correspond to the same cache, and the data in the cache is stored in the form of a map.

It should be noted that, before step S10, the method further includes: predetermining and saving the number of each block; for each new block, a new number is generated based on the maximum value of the existing number as the new number. Increase the number of the block. For example, the existing blocks are numbered according to business requirements, and blocks 1, 2, 3, ..., n are obtained. The order of each number is the order in which the block information of each block is obtained. In the process of generating a new block, the number of the new block is n+1, and so on.

Step S20: Read the read-write set of the target block from the block information of the several blocks in sequence, and determine the transaction data in the read-write set of the target block based on the data in the preset cache and the state database Whether it is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache the read-write set of valid transactions in each block in the blockchain network .

The process in the prior art is: if there are 3 blocks 1, 2, 3 in sequence. To verify whether the transaction in block 2 is valid, you need to rely on the result of block 1, and to verify whether the transaction in block 3 is valid, you need to rely on the results of block 1 and block 2, and verify one block at a time After that, the results are written into the state database. It can be understood that the state database that was written last time contains the latest data in the blockchain. When processing a new block, you can go to the state database to query. The problem with this process is that it needs to wait for each block in order to write the transaction results into the state database, that is, verifying the validity of the data will make the process of writing the state database very slow.

In order to improve the efficiency of data verification, a new cache is added for storing the read-write set of valid transactions in each block in the blockchain network. In this embodiment, the judging whether the transaction data in the read-write set of the target block is valid based on the data in the cache and the state database includes:

Determine the reference block corresponding to the target block, obtain the data corresponding to the reference block from the cache, and compare the read/write set of the target block with the reference block in the cache The data is compared, and if there is data corresponding to the read-write set of the target block, it is determined that the transaction data in the read-write set of the target block is valid; if there is no read-write set with the target block Corresponding data, the data corresponding to the reference block is obtained from the state database, and the read-write set of the target block is compared with the data corresponding to the reference block in the state database. The data corresponding to the read-write set of the target block determines that the transaction data in the read-write set of the target block is valid.

It should be noted that the reference block corresponding to the target block is determined based on the sequence of block numbers. Taking blocks 1, 2, and 3 as an example, block 1 has no reference block, the reference block of block 2 is block 1, and the reference block of block 3 is block 1 and block 2. For example, after the transaction node has checked the read-write set in block 1, it writes the read-write set corresponding to the valid transaction data into the cache. When block 1 is or has not yet begun to write the state database, block 2 first Compare the read and write set in the block information with the data in block 1 in the cache. If there is no data in block 1 in the cache, compare it with the latest data in the state database, so that block 2 can be correctly judged Whether the transaction data in the read-write set is valid. In other words, to check the read and write set of a target block, not only compare the data in the state database, but also compare the data in the cache.

In this embodiment, the order of writing the read-write set in the block information of each block into the cache is serialized according to the block number. For example, if the order of block 1, 2, 3,..., n is block 1, block 1, block 3,..., block n, then write the cache of block 1 first, and then write the cache of block 2. Caching,..., and so on.

In step S30, the data corresponding to the target block is read from the cache in a background execution manner, and the data corresponding to the target block is written into the state database.

In this embodiment, the operation of writing the data corresponding to the target block into the state database is executed concurrently, so as to make full use of the performance of the computer.

Each block has its own block number. Associate the block number with the read-write set of valid transactions in the block. The block number is used to index the data corresponding to each target block from the cache, that is, the read-write set corresponding to the valid transaction data in each target block.

In this embodiment, the read and write set corresponding to the valid transaction data of part of the target block can be written into the cache, and the operation of writing the state database can also be started after the valid transaction data of all target blocks is read and written. After the set is written into the cache, the operation of writing the state database is started. Therefore, it can be understood that step S20 and step S30 can be performed at the same time after writing the cache of the first target block.

In order to make full use of computer performance and improve the efficiency of writing the state database, in this embodiment, after the read-write set corresponding to the valid transaction data of the first target block is written into the cache, the first target block is started in the background. The block performs write state database operations. For example, after the read-write set corresponding to the valid transaction data of block 1 is written into the cache, it is determined whether the transaction data of the read-write set of block 2 is valid, and at the same time, the operation of writing the state database to block 1 is started in the background.

It should be noted that both the write cache and the write state database are executed by the transaction node. The difference is that the write cache and the write state database are completed by different coroutines of the transaction node. For example, the write cache is completed by the first coroutine created by the transaction node. The writing of the state database is completed by the second coroutine created by the transaction node to realize the operation of writing the state database in the background.

In the method for writing the state database proposed in the above embodiment, by adding a new cache, the read and write set of valid blocks are written into the cache, and subsequent blocks can obtain relevant data from the cache during the process of verifying data. For verification, the next block can be processed without waiting for the previous block to complete writing to the state database. Since the write cache speed is much faster than the write state database, the efficiency of subsequent block data verification can be improved; at the same time, By separating the write cache from the write state database, and execute the process of writing the state database in the background, the computer performance is fully utilized and the processing progress of the write state database is accelerated.

In view of the large number of blocks, the effective read and write set of each block stored in the cache will occupy a certain amount of memory. In order to make full use of the storage space and improve data processing efficiency, in other embodiments, the step S30 further includes:

After the data corresponding to the target block is written into the state database, the data corresponding to the target block is released from the cache.

After the effective read-write set of a block is written into the state database, the data in the cache is no longer needed, so data that is no longer needed in the cache can be deleted to free up storage space.

In order to ensure that the data in the state database is consistent with the data in the blockchain, it is necessary to prevent the peer node from going down during the process of writing the state database. Therefore, after writing the block's read-write set to the state database, A checkpoint needs to be written to determine the uncompleted blocks when the write state database is restored.

However, the current steps for writing a checkpoint are: input a block, check the block data, write the valid read and write set of the block into the state database, write the checkpoint, and then repeat the same steps for the next block. It should be noted that after the blocks concurrently write their respective read and write sets to the state database, if the write checkpoint operation still follows the write state database, the checkpoint function at this time will become invalid. For example, because the state database of block 1, block 2, and block 3 is written concurrently, if the state database of block 2 is written and the checkpoint is written to 2, then the peer hangs down and restarts the peer When the checkpoint is 2, the program will start to restore from block 2, and restore the data in block 3 and beyond. It is impossible to find that the data of block 1 has not been written into the state database, which will cause the data in the filling database to be lost, resulting in inconsistencies with the data in the state database of other nodes.

Therefore, in order to ensure data consistency, in other embodiments, the writing method of the state database further includes:

Step S40: After the data corresponding to the target block is written into the state database, a checkpoint write request is sent to the checkpoint coroutine, the request includes the block number corresponding to the target block, and the checkpoint is controlled The coroutine writes checkpoints for the target block based on the block number and preset analysis rules.

To write a checkpoint is to write the block number corresponding to the checkpoint into the state database. Each time a block is written, the checkpoint is written once, so that it is clear that the state database stores valid reads of blocks 0~xx Write set.

In this embodiment, the operation of writing the checkpoint is separated from the operation of writing the state database. The transaction node sets up a separate coroutine (third coroutine) for writing checkpoints, which can be understood as a new process of the transaction node.

In this embodiment, the checkpoint coroutine writes checkpoints for the target block based on the block number and preset analysis rules, including:

a1. After receiving the request, the checkpoint coroutine obtains the block number of the target block, and determines whether the number is the expected number;

a2. If yes, write a checkpoint for the target block and update the expected number;

a3. If not, write the request into the waiting queue in the order of numbers, and determine whether the expected number exists in the waiting queue; if so, perform step a2 to write a checkpoint for the block corresponding to the expected number, if not, Go to step a1.

After the effective read-write set of the target block is written into the state database, a write checkpoint request carrying the block number is sent to the checkpoint coroutine. The checkpoint coroutine only receives the sequential number (ie the expected number), Will actually write the checkpoint information. Since each block is written into the state database concurrently in this application, there may be discontinuous numbers. When there are discontinuous numbers, wait for the expected number before writing. Every time a checkpoint is written, the previous checkpoint will be overwritten, and only the latest value will be retained.

For example, the effective read and write sets of block 0, block 1, and block 5 are all written into the state database, while the effective read and write sets of block 2, block 3, and block 4 have not been written into the state database. Therefore, when writing a checkpoint for block 5, it is necessary to ensure that block 2, block 3, and block 4 have been written into the state database. Therefore, the request numbered 5 is written into the waiting queue, and the number is to be numbered. After writing the checkpoint for the request of 4, write the checkpoint for the request of No. 5.

The expected number is the number of the last checkpoint written plus one. For example, the last time the checkpoint of the request with number 1 is written, the expected number at this time is 1+1. When the request with block number 2 is received, the checkpoint is written for block 2. If the received None of the requests are 2, write these requests into the waiting queue in order of numbers, and write checkpoints for the blocks corresponding to the expected numbers until the expected numbers appear. Even if the peer is down at this time, the data in block 2 and beyond can be restored correctly.

The writing method of the state database proposed in the above embodiment writes the effective read-write set of each block into the state database through the background concurrently, and after the state database is written, the blocks corresponding to the expected numbers are sequentially listed in the order of the block numbers. Write checkpoints to avoid the situation that the peer cannot recover data correctly after the peer is down, and improve the efficiency and accuracy of writing the state database.

Refer to FIG. 2, which is a schematic diagram of a preferred embodiment of the electronic device 1 of this application.

In this embodiment, the electronic device 1 is an electronic device corresponding to a transaction node in the blockchain network. The electronic device 1 may be a terminal device with data processing functions such as a server, a smart phone, a tablet computer, a portable computer, a desktop computer, etc. The server may be a rack server, a blade server, a tower server or a cabinet server .

The electronic device 1 includes a memory 11, a processor 12 and a network interface 13.

The memory 11 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, and the like. The memory 11 may be an internal storage unit of the electronic device 1 in some embodiments, such as a hard disk of the electronic device 1. In other embodiments, the memory 11 may also be an external storage device of the electronic device 1, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), and a secure digital (Secure Digital) equipped on the electronic device 1. , SD) card, flash card (Flash Card), etc. Further, the memory 11 may also include both an internal storage unit of the electronic device 1 and an external storage device.

The memory 11 can be used not only to store application software and various data installed in the electronic device 1, for example, the write program 10 of the state database, etc., but also to temporarily store data that has been output or will be output.

The processor 12 may be a central processing unit (Central Processing Unit) in some embodiments. Processing Unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips are used to run the program code or processing data stored in the memory 11, for example, the write program 10 of the state database.

The network interface 13 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The components 11-13 of the electronic device 1 communicate with each other via a communication bus.

FIG. 2 only shows the electronic device 1 with the components 11-13. Those skilled in the art can understand that the structure shown in FIG. 2 does not constitute a limitation on the electronic device 1, and may include fewer or more components than shown in the figure. Multiple components, or a combination of certain components, or different component arrangements.

Optionally, the electronic device 1 may further include a user interface. The user interface may include a display (Display) and an input unit such as a keyboard (Keyboard). The optional user interface may also include a standard wired interface and a wireless interface.

Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an organic light-emitting diode (Organic Light-Emitting Diode, OLED) touch device, etc. Among them, the display may also be called a display screen or a display unit, which is used to display the information processed in the electronic device 1 and to display a visualized user interface.

Referring to FIG. 3, this is a schematic diagram of modules of a preferred embodiment of an apparatus 100 for writing a state database according to this application. In this embodiment, the apparatus 100 for writing a state database may only include modules 110-130.

The receiving module 110 is configured to obtain the block information of the several blocks after receiving the simulation results of the several blocks sent by the ordering node;

After receiving the simulation result (proposal result) sent by the ordering node, the receiving module 110 obtains the block information of each block in the order of the block number of each block. Among them, the block information of each block includes: transaction information of multiple transactions, whether the transaction is valid, the read-write set corresponding to the transaction, the smart contract and the block chain corresponding to each transaction. In the blockchain network, one chain corresponds to a state database, all blocks correspond to the same cache, and the data in the cache is stored in the form of a map.

It should be noted that the number of each block is predetermined and stored, and each time a new block is added, a new number is generated based on the maximum value of the existing number as the number of the newly added block. For example, the existing blocks are numbered according to business requirements, and blocks 1, 2, 3, ..., n are obtained. The order of each number is the order in which the block information of each block is obtained. In the process of generating a new block, the number of the new block is n+1, and so on. .

The first write module 120 is configured to read the read and write set of the target block from the block information of the several blocks in sequence, and determine the read of the target block based on the data in the preset cache and the state database Whether the transaction data in the write set is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache the valid blocks in the blockchain network The read-write set of the transaction.

The process in the prior art needs to wait for each block to write the transaction result into the state database in order, that is, verifying the validity of the data will make the process of writing the state database very slow.

In order to improve the efficiency of data verification, in this embodiment, the judging whether the transaction data in the read-write set of the target block is valid based on the data in the cache and the state database includes:

In this embodiment, the order in which the first write module 120 writes the read and write sets in the block information of each block into the cache is serialized according to the block number. For example, if the order of block 1, 2, 3,..., n is block 1, block 1, block 3,..., block n, then write the cache of block 1 first, and then write the cache of block 2. Caching,..., and so on.

The second write module 130 is configured to read the target area from the cache in a background execution manner after the first write module 110 writes the read and write set corresponding to the valid transaction data of the target block into the cache Data corresponding to the block, and write the data corresponding to the target block into the state database.

In this embodiment, the operation of writing the data corresponding to the target block into the state database by the second writing module 130 is performed concurrently, so as to make full use of the performance of the computer.

In this embodiment, the read and write set corresponding to the valid transaction data of part of the target block can be written into the cache, and the operation of writing the state database can also be started after the valid transaction data of all target blocks is read and written. After the set is written into the cache, the operation of writing the state database is started. Therefore, it can be understood that the write cache and the write state database can be performed at the same time after the cache of the first target block is written.

The electronic device 1 proposed in the above embodiment adds a cache to write the read and write set of valid blocks into the cache, and subsequent blocks can obtain relevant data from the cache for verification during the process of verifying data. , The next block can be processed without waiting for the previous block to finish writing the state database. Since the write cache speed is much faster than the write state database, the efficiency of subsequent block data verification can be improved; at the same time, by writing The cache is separated from the write state database, and the process of writing the state database is executed in the background, making full use of the computer performance and speeding up the processing progress of the writing state database.

In view of the large number of blocks, the effective read and write set of each block stored in the cache will occupy a certain amount of memory. In order to make full use of the storage space and improve the efficiency of data processing, in other embodiments, the second write module 130 also It is used to release the data corresponding to the target block from the cache after the data corresponding to the target block is written into the state database.

Therefore, in order to ensure data consistency, in other embodiments, the apparatus 100 for writing a state database further includes:

The third write module 140 is configured to receive a write checkpoint request sent by the second write module 130, where the request includes a block number corresponding to the target block, and is based on the block number and a preset analysis rule as the The target block write checkpoint.

In this embodiment, the operation of writing the checkpoint is separated from the operation of writing the state database. To write a checkpoint is to write the block number corresponding to the checkpoint into the state database. Every time the second writing module 130 finishes writing a block, the third writing module 140 writes the checkpoint once, so that it is clear that the state is stored in the database. It is the effective read and write set of blocks 0~xx.

In this embodiment, writing a checkpoint for the target block based on the block number and a preset analysis rule includes:

After the second writing module 130 writes the effective read-write set of the target block into the state database, it sends a write checkpoint request carrying the block number to the third writing module 140, and the third writing module 140 only receives the sequential number (That is, the expected number), the checkpoint information is actually written. Since each block is written into the state database concurrently in this application, there may be discontinuous numbers. When there are discontinuous numbers, wait for the expected number before writing. Every time a checkpoint is written, the previous checkpoint will be overwritten, and only the latest value will be retained.

The electronic device 1 proposed in the above embodiment concurrently writes the effective read-write set of each block into the state database through the background, and after writing the state database, write checkpoints for the blocks corresponding to the expected numbers in the order of the block numbers , To avoid the situation that the data cannot be recovered correctly after the peer is down, and to improve the efficiency and accuracy of writing the state database.

In addition, the embodiment of the present application also proposes a computer-readable storage medium. The computer-readable storage medium may be volatile or non-volatile. The computer-readable storage medium includes the writing of the state database. Program 10, when the state database writing program 10 is executed by the processor, the following operations are implemented:

The first writing step: read the read-write set of the target block sequentially from the block information of the several blocks, and determine the read-write set of the target block based on the data in the preset cache and the state database Whether the transaction data is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache the reads of valid transactions in each block in the blockchain network Write set

The second writing step: after the read-write set corresponding to the valid transaction data of the target block is written into the cache, the data corresponding to the target block is read from the cache in a background execution manner, and the data corresponding to the target block is read The data corresponding to the target block is written into the state database; and

The third writing step: receiving a request for writing a checkpoint, the request including a block number corresponding to the target block, and writing a checkpoint for the target block based on the block number and a preset analysis rule.

The specific implementation of the computer-readable storage medium of the present application is substantially the same as the specific implementation of the above-mentioned state database writing method, and will not be repeated here.

The serial numbers of the foregoing embodiments of the present application are for description only, and do not represent the advantages and disadvantages of the embodiments.

It should be noted that in this article, the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, device, article or method including a series of elements not only includes those elements, It also includes other elements not explicitly listed, or elements inherent to the process, device, article, or method. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, device, article, or method that includes the element.

Through the description of the above implementation manners, those skilled in the art can clearly understand that the above-mentioned embodiment method can be implemented by means of software plus the necessary general hardware platform, of course, it can also be implemented by hardware, but in many cases the former is better.的实施方式。 Based on this understanding, the technical solution of this application essentially or the part that contributes to the existing technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium (such as ROM/RAM) as described above. , Magnetic disks, optical disks), including several instructions to make a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) execute the methods described in the various embodiments of this application.

The above are only the preferred embodiments of the application, and do not limit the scope of the patent for this application. Any equivalent structure or equivalent process transformation made using the content of the description and drawings of the application, or directly or indirectly applied to other related technical fields , The same reason is included in the scope of patent protection of this application.

Claims

A method for writing a state database is applied to the electronic equipment of a transaction node in a blockchain network, the blockchain network further includes an ordering node, wherein the method includes:

In the receiving step, after receiving the simulation results of several blocks sent by the ordering node, obtain the block information of the several blocks;

The first writing step is to sequentially read the read and write set of the target block from the block information of the several blocks, and determine the read and write set of the target block based on the data in the preset cache and the state database Whether the transaction data is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache the reads of valid transactions in each block in the blockchain network Writing set; and

The second writing step is to read the data corresponding to the target block from the cache in a background execution manner, and write the data corresponding to the target block into the state database.
The method for writing a state database according to claim 1, wherein the judging whether the transaction data in the read-write set of the target block is valid based on the data in the cache and the state database comprises:

Determine the reference block corresponding to the target block, obtain the data corresponding to the reference block from the cache, and compare the read/write set of the target block with the reference block in the cache Data comparison;

If there is data corresponding to the read-write set of the target block, it is determined that the transaction data in the read-write set of the target block is valid; and

If there is no data corresponding to the read-write set of the target block, the data corresponding to the reference block is obtained from the state database, and the read-write set of the target block is compared with the reference in the state database. The data corresponding to the blocks are compared, and if there is data corresponding to the read-write set of the target block, it is determined that the transaction data in the read-write set of the target block is valid.
The method for writing a state database according to claim 1, wherein the second writing step further comprises:

After the data corresponding to the target block is written into the state database, the data corresponding to the target block is released from the cache.
The method for writing a state database according to any one of claims 1 to 3, wherein the method for writing the state database further comprises:

In the third writing step, after the data corresponding to the target block is written into the state database, a checkpoint write request is sent to the checkpoint coroutine, and the request includes the block number corresponding to the target block, and controls the The checkpoint coroutine writes checkpoints for the target block based on the block number and preset analysis rules.
The method for writing a state database according to claim 4, wherein the checkpoint coroutine writes a checkpoint for the target block based on the block number and a preset analysis rule, comprising:

a1. After receiving the request, the checkpoint coroutine obtains the block number of the target block, and determines whether the number is the expected number;

a2. If yes, write a checkpoint for the target block and update the expected number;

a3. If not, write the request into the waiting queue in the order of numbers, and determine whether the expected number exists in the waiting queue; if so, perform step a2 to write a checkpoint for the block corresponding to the expected number, if not, Go to step a1.
The method for writing a state database according to claim 2, wherein, before the receiving step, the method further comprises:

The number of each block is determined and saved in advance, and each time a new block is added, a new number is generated based on the maximum value of the existing number as the number of the newly added block.
7. The method for writing a state database according to claim 6, wherein the reference block corresponding to the target block is determined based on a block coding order.
A writing device for a state database, wherein the device includes:

The receiving module is used to obtain the block information of the several blocks after receiving the simulation results of the several blocks sent by the ordering node;

The first write module is used to sequentially read the read and write set of the target block from the block information of the several blocks, and determine the read and write of the target block based on the data in the preset cache and the state database Whether the centralized transaction data is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache valid transactions in each block in the blockchain network Read and write set; and

The second writing module is configured to read the data corresponding to the target block from the cache in a background execution manner, and write the data corresponding to the target block into the state database.
An electronic device, wherein the electronic device includes a memory and a processor, the memory stores a state database writing program that can be run on the processor, and the state database writing program is controlled by the state database. When the processor executes, the following steps can be implemented:

Receiving step: after receiving the simulation results of several blocks sent by the ordering node, obtain block information of the several blocks;

The first writing step: read the read-write set of the target block sequentially from the block information of the several blocks, and determine the read-write set of the target block based on the data in the preset cache and the state database Whether the transaction data is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache the reads of valid transactions in each block in the blockchain network Writing set; and

The second writing step: read the data corresponding to the target block from the cache in a background execution manner, and write the data corresponding to the target block into the state database.
The electronic device according to claim 9, wherein the judging whether the transaction data in the read-write set of the target block is valid based on the data in the cache and the state database comprises:

Determine the reference block corresponding to the target block, obtain the data corresponding to the reference block from the cache, and compare the read/write set of the target block with the reference block in the cache Data comparison;

If there is data corresponding to the read-write set of the target block, it is determined that the transaction data in the read-write set of the target block is valid; and

If there is no data corresponding to the read-write set of the target block, the data corresponding to the reference block is obtained from the state database, and the read-write set of the target block is compared with the reference in the state database. The data corresponding to the blocks are compared, and if there is data corresponding to the read-write set of the target block, it is determined that the transaction data in the read-write set of the target block is valid.
The electronic device according to any one of claims 9 to 10, wherein when the state database writing program is executed by the processor, the following steps are further implemented:

The third writing step: receiving a request for writing a checkpoint, the request including a block number corresponding to the target block, and writing a checkpoint for the target block based on the block number and a preset analysis rule.
11. The electronic device of claim 11, wherein the writing a checkpoint for the target block based on the block number and a preset analysis rule comprises:

a1. After receiving the request, the checkpoint coroutine obtains the block number of the target block, and determines whether the number is the expected number;

a2. If yes, write a checkpoint for the target block and update the expected number;

a3. If not, write the request into the waiting queue in the order of numbers, and determine whether the expected number exists in the waiting queue; if so, perform step a2 to write a checkpoint for the block corresponding to the expected number, if not, Go to step a1.
The electronic device according to claim 9, wherein the second writing step further comprises:

After the data corresponding to the target block is written into the state database, the data corresponding to the target block is released from the cache.
The electronic device according to claim 10, wherein, before the receiving step, the following steps are further implemented when the state database writing program is executed by the processor:

The number of each block is determined and saved in advance, and each time a new block is added, a new number is generated based on the maximum value of the existing number as the number of the newly added block.
15. The electronic device according to claim 14, wherein the reference block corresponding to the target block is determined based on a block coding order.
A computer-readable storage medium, wherein the computer-readable storage medium includes a state database writing program, and when the state database writing program is executed by a processor, the following steps are implemented:

In the receiving step, after receiving the simulation results of several blocks sent by the ordering node, obtain the block information of the several blocks;

The first writing step is to sequentially read the read and write set of the target block from the block information of the several blocks, and determine the read and write set of the target block based on the data in the preset cache and the state database Whether the transaction data is valid, and write the read-write set corresponding to the valid transaction data of the target block into the cache, where the cache is used to cache the reads of valid transactions in each block in the blockchain network Writing set; and

The second writing step is to read the data corresponding to the target block from the cache in a background execution manner, and write the data corresponding to the target block into the state database.
The computer-readable storage medium according to claim 16, wherein the judging whether the transaction data in the read-write set of the target block is valid based on the data in the cache and the state database comprises:

Determine the reference block corresponding to the target block, obtain the data corresponding to the reference block from the cache, and compare the read/write set of the target block with the reference block in the cache Data comparison;

If there is data corresponding to the read-write set of the target block, it is determined that the transaction data in the read-write set of the target block is valid; and

If there is no data corresponding to the read-write set of the target block, the data corresponding to the reference block is obtained from the state database, and the read-write set of the target block is compared with the reference in the state database. The data corresponding to the blocks are compared, and if there is data corresponding to the read-write set of the target block, it is determined that the transaction data in the read-write set of the target block is valid.
The computer-readable storage medium according to claim 16, wherein the second writing step further comprises:

After the data corresponding to the target block is written into the state database, the data corresponding to the target block is released from the cache.
The computer-readable storage medium according to any one of claims 16 to 18, wherein the following steps are further implemented when the write program of the state database is executed by the processor:

In the third writing step, after the data corresponding to the target block is written into the state database, a checkpoint write request is sent to the checkpoint coroutine, and the request includes the block number corresponding to the target block, and controls the The checkpoint coroutine writes checkpoints for the target block based on the block number and preset analysis rules.
18. The computer-readable storage medium of claim 19, wherein the checkpoint coroutine writes a checkpoint for the target block based on the block number and a preset analysis rule, comprising:

a1. After receiving the request, the checkpoint coroutine obtains the block number of the target block, and determines whether the number is the expected number;

a2. If yes, write a checkpoint for the target block and update the expected number;

a3. If not, write the request into the waiting queue in the order of numbers, and determine whether the expected number exists in the waiting queue; if so, perform step a2 to write a checkpoint for the block corresponding to the expected number, if not, Go to step a1.