A method and apparatus for storing block headers

Abstract

This application provides a block header storage method and apparatus. The method includes: sending a block header retrieval request to a blockchain network via a decentralized application (DApp), the request carrying a requested block header height range; receiving block header information within the requested height range from the blockchain network; determining block header information associated with the DApp from the retrieved block header information; and storing the block header associated with the DApp in the DApp. This application facilitates the timely retrieval of block header information via a DApp.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, and in particular to a method and apparatus for storing block headers. Background Technology

[0002] Decentralized applications (DApps) are internet applications that differ from traditional apps in that they run on decentralized networks, specifically blockchain networks. Blockchain networks do not have centralized nodes that can fully control DApps, ensuring their complete open-source nature and autonomy.

[0003] Currently, DApps need to obtain block header information from the blockchain network before using it and delete it after use. Obviously, there is a certain delay in each block header retrieval, causing DApps to not obtain the necessary block header information in a timely manner. Therefore, how to enable DApps to obtain block header information promptly has become an urgent problem to be solved. Summary of the Invention

[0004] This invention provides a method and device for storing block headers, which facilitates timely acquisition of block header information.

[0005] In a first aspect, embodiments of the present invention provide a method for storing block headers, the method comprising:

[0006] A decentralized application (DApp) sends a block header retrieval request to the blockchain network, and the block header retrieval request carries the block header height range to be retrieved.

[0007] Receive block header information within the block header height range from the blockchain network;

[0008] Identify the block header information associated with the DApp from the obtained block header information;

[0009] Save the block header associated with the DApp to the DApp.

[0010] In one implementation, based on the transaction hash value in the acquired block header information, target block header information related to transactions initiated and / or received by the DAPP is determined from the acquired block header information; the target block header information is determined as the block header information associated with the DAPP.

[0011] In one implementation, after saving the block header associated with the DApp to the DApp, a transaction request initiated by the DApp is received. The transaction request is used to request the initiation of a first transaction to the blockchain network. A second transaction associated with the first transaction is determined. The success of the second transaction is verified based on the block header information saved by the DApp. When the second transaction is verified to be successful, the first transaction is initiated to the blockchain network.

[0012] In one implementation, after the last time a block header was included in the DApp, the first number of transactions in the DApp is determined. The first number of transactions is the number of transactions initiated by the DApp, the number of transactions received by the DApp, or the sum of the number of transactions initiated by the DApp and the number of transactions received by the DApp. It is then determined whether the first number of transactions is greater than a preset value. If the first number of transactions is greater than the preset value, a request to obtain the block header is sent to the blockchain network through the decentralized application DApp.

[0013] In one implementation, a third transaction is initiated to the blockchain network via a DAPP; it is determined whether the time interval between the current time and the initiation time of the third transaction reaches a preset interval; if so, a request to obtain the block header is sent to the blockchain network via the decentralized application (DAPP).

[0014] In one implementation, after saving the block header associated with the DAPP to the DAPP, the success of the third transaction is verified based on the block header information saved by the DAPP. If the third transaction is verified to be successful, the importance level of the third transaction is determined. If the importance level of the third transaction is lower than a preset level, the first block header information is deleted from the block header information saved by the DAPP. The first block header information is the block header information associated with the third transaction in the block header information saved by the DAPP.

[0015] In one implementation, it is determined whether a fourth transaction exists among the transactions initiated and / or received by the DAPP, the fourth transaction being different from the third transaction and related to the first block header information; if the fourth transaction does not exist, the first block header information is deleted from the DAPP.

[0016] Secondly, embodiments of this application provide a block header storage device, the device comprising:

[0017] The sending module is used to send a block header retrieval request to the blockchain network through a decentralized application (DApp). The block header retrieval request carries the block header height range to be retrieved.

[0018] The receiving module is used to receive block header information within the block header height range from the blockchain network;

[0019] The processing module is used to determine the block header information associated with the DAPP from the acquired block header information;

[0020] A storage module is used to save the block header associated with the DAPP to the DAPP.

[0021] Thirdly, embodiments of this application provide a block header cache storage device, which includes a processor and a memory connected to each other. The memory is used to store a computer program, which includes program instructions. The processor is configured to call the program instructions to perform the operations involved in the first aspect.

[0022] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the method described in the first aspect.

[0023] In this embodiment, the block header storage device initiates a block header retrieval request to the blockchain network. This request includes a block header height range, allowing the device to receive block header information within that range from the blockchain network. The device can then determine the block header information associated with the DApp based on the transaction hash value within the acquired block header information and save this associated information to the DApp. If further verification of transaction information associated with the DApp is required, the corresponding block header information can be readily obtained and verified using the locally stored block header information within the DApp. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A schematic diagram of a network architecture provided for an embodiment of this application;

[0026] Figure 2 A schematic diagram of a block header saving process provided in an embodiment of this application;

[0027] Figure 3 A schematic diagram of a Merkle tree provided for an embodiment of this application;

[0028] Figure 4This is a schematic diagram illustrating a first scenario for initiating a block header retrieval request, as provided in an embodiment of this application.

[0029] Figure 5 This is a schematic diagram illustrating a second scenario for initiating a block header retrieval request, as provided in an embodiment of this application.

[0030] Figure 6 A schematic diagram of a block header storage device module provided in an embodiment of this application;

[0031] Figure 7 This is a simplified schematic diagram of the physical structure of a block header storage device provided in an embodiment of this application. Detailed Implementation

[0032] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0033] This application provides a block header caching method and device, which can synchronize the block headers associated with a decentralized application (DAPP) to the DAPP, which is beneficial for timely acquisition of block header information associated with the DAPP.

[0034] To better understand the embodiments of this application, the network architecture applicable to the embodiments of this application will be described below.

[0035] Please see Figure 1 , Figure 1 This is a network architecture diagram provided for an embodiment of this application. (For example...) Figure 1 As shown, the network includes a blockchain network and a block header storage device. The blockchain network also includes full nodes 1 to 3, and the block header storage device includes DApps. In practical applications, the blockchain network can also include three or more full nodes; this embodiment does not limit this. The full nodes are interconnected to form the blockchain network. Each full node stores all the blocks in the blockchain and can receive and process information from DApp nodes.

[0036] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. A blockchain consists of a series of blocks sequentially generated in chronological order. Each block includes a block header and a block body.

[0037] The block header stores the block's header information, including the version number, the hash value of the previous block, the difficulty value, the block timestamp, the nonce string, and the Merkle root. The parameters in the block header specify the exact position of each ledger on the chain, allowing unrelated ledgers to form a blockchain with a strictly defined sequence, immutability, and continuous growth.

[0038] A Merkle tree is a binary tree consisting of a root node, a set of intermediate nodes, and some leaf nodes. Intermediate nodes are derived by hashing the leaf nodes, and this process of hashing continues layer by layer until a final hash value is obtained – this hash value is the Merkle root. The Merkle root is stored in the block header, while the intermediate and leaf nodes are stored in the block body. The leaf nodes store various transaction information from the blockchain network. Whenever a certain number of transactions are recorded, they are packaged into a block body, which, together with the block header, forms a new block and is linked to the blockchain. The root hash storage method of the Merkle tree allows the blockchain to quickly detect information tampering and quickly locate specific transaction information.

[0039] In a blockchain network, interconnected full nodes refer to nodes that store the complete blockchain, and can include data nodes and consensus nodes. Consensus nodes receive new transaction information from the blockchain network. Once the number of transactions reaches a preset threshold, they generate a new block and connect it to the existing blockchain according to the longest chain principle. If more new blocks are generated, they are connected to the blockchain in the order of their generation. Each block contains several transactions. Data nodes can receive request messages from other nodes to read transaction information from a specified block. In essence, consensus nodes write new blocks to the blockchain, while data nodes read block information from the blockchain.

[0040] In a blockchain network, when two users engage in a transaction, the network generates a transaction record, documenting the transaction's destination and funds. This transaction information can include the transaction amount, sender information, and recipient information. The sender can be an individual user, and the recipient can be an individual user or a public user, such as a tax authority. Of course, the transaction information can also represent other types of transactions, such as invoice requests or securities transactions; this embodiment does not limit such instances.

[0041] A DApp is an internet application that runs on a distributed network. It is completely open-source and autonomous, and no single entity controls more than 51% of the tokens (a type of digital proof of ownership). DApps can be upgraded based on user feedback and technical requirements, with upgrades occurring only after a majority of users reach a consensus. In this embodiment, the DApp has caching capabilities, meaning it has a certain amount of cache space. The DApp can synchronize block header information within a preset range from the blockchain network and search and filter out block header information related to itself from this range, storing this relevant information locally within the DApp. If it is necessary to verify whether a transaction exists on the blockchain later, the DApp can access the local node for verification, replacing the traditional method of requesting the blockchain network for each transaction, thus improving verification efficiency.

[0042] Please see Figure 2 , Figure 2 This application provides a schematic diagram of a block header saving process, wherein the block header saving method includes, but is not limited to, the following steps:

[0043] 210. The block header storage device sends a block header retrieval request to the blockchain network through a decentralized application (DApp). The block header retrieval request carries the block header height range to be retrieved. Accordingly, the blockchain network receives the block header retrieval request.

[0044] The block header storage device sends a block header retrieval request to any fully active node in the blockchain network. This request includes the requested block header height range. The block height value is stored in the block header and is used to identify the block's position in the blockchain, thus locating all associated basic attributes and transaction records. Upon receiving the request, a fully active node in the blockchain network can locate blocks within the height range and extract their block header information.

[0045] 220. The block header storage device receives block header information within the block header height range from the blockchain network.

[0046] After extracting the block header within the height range required by the DApp, the full node in the blockchain network sends it to the block header storage device.

[0047] 230. The block header storage device determines the block header information associated with the DAPP from the acquired block header information.

[0048] In one possible implementation, the block header information associated with the DApp refers to the transaction information initiated and / or received by the DApp included in the block body corresponding to the block header. The block header information associated with the DApp refers to the block header information related to the transactions initiated and / or received by the DApp.

[0049] In one possible implementation, the block header storage device specifically determines the target block header information related to the transaction initiated and / or received by the DAPP from the acquired block header information based on the transaction hash value in the acquired block header information.

[0050] Before the block header storage device determines the block header information associated with the DApp from the acquired block header information, it needs to obtain the Merkle tree hash authentication path corresponding to the target transaction and the hash value associated with the target transaction under that path from the blockchain network, based on the transactions initiated or received by the DApp (target transaction). When a full node in the blockchain network receives this request, it first locates the block in the blockchain where the target transaction is located (target block), constructs a Merkle tree based on each transaction in the target block, then determines the Merkle verification path corresponding to the target transaction, and returns the hash value associated with the Merkle path corresponding to the target transaction to the block header storage device. The block header storage device verifies whether the Merkle path corresponding to the target transaction is correct based on the hash value returned by the full node, that is, it calculates the Merkle root of the Merkle tree based on the transaction hash of the target transaction and the hash value returned by the full node, and determines whether the calculated Merkle root is consistent with the transaction hash value in the block header of the target block stored in the DApp. If they match, the verification is considered successful, proving that the target transaction has indeed been written into the blockchain. At the same time, the block header including the transaction hash value is identified as the block header information associated with the DApp, and the block header storage device confirms that the target transaction was successful.

[0051] The transaction hash value in the block header information can be a Merkle root. As described above, if there exists a block header whose Merkle root is the same as the Merkle root calculated from the hash authentication path and related hash value of the target transaction obtained from the full node, then it is determined that this block header is the block header associated with the DApp.

[0052] Please see Figure 3 , Figure 3 This is a schematic diagram of a Merkle tree provided for an embodiment of this application. Before introducing the Merkle tree, let's first introduce hash operations.

[0053] Hash operations, also known as hashing or hashing, transform an input of arbitrary length into a fixed-length output, called the hash value, using a hash algorithm. This transformation is a compression mapping; that is, the space of hash values ​​is usually much smaller than the space of inputs. Different inputs may hash to the same output, so it is impossible to determine a unique input value from the hash value. Hash operations can output any input data as a 256-bit binary number, and hash operations are irreversible. That is, it is easy to derive 256-bit binary data from input data, but very difficult to derive input data from 256-bit binary data. Hash algorithms include HA-1, SHA-224, SHA-256, SHA-384, and SHA-512, among others. For example, a string "123456abcdef" will generate a 256-bit binary digest after being processed by the SHA256 algorithm. The digest will be represented as "101001100101010001...", which is a total of 256 bits. Of course, the digest can also be represented in 64-bit hexadecimal.

[0054] like Figure 3 Transactions 1 through 8 are leaf nodes in the Merkle tree, and hashes 9 through 14 are intermediate nodes. Hash 1 is the result of hashing transaction 1, hash 2 is the result of hashing transaction 2, and so on. Hash 9 is the result of hashing a new hash value formed by hashes 1 and 2, and hash 10 is the result of hashing a new hash value formed by hashes 3 and 4, and so on. In the Merkle tree, hash 15 is the root node, i.e., the Merkle root. It is understandable that if the data in any leaf node (transactions 1 through 8) changes, the final hash 15 will change accordingly. Of course, in practical applications, the number of leaf nodes in a Merkle tree is very large, potentially reaching thousands; this embodiment does not limit this number.

[0055] For example, if transaction 5 is a transaction initiated or received by a DApp, the full node first locates the block containing the target transaction, constructs the Merkle tree of that block, determines the Merkle path for constructing the Merkle tree for transaction 5, and records the hash values ​​associated with that Merkle path. In this example, the hash values ​​associated with the Merkle path of transaction 5 are hash 6, hash 12, and hash 13. Hash 5 can be obtained from transaction 5, hash 11 can be obtained from hash 5 and hash 6, hash 14 can be obtained from hash 11 and hash 12, and finally, the Merkle root, hash 15, can be obtained from hash 13 and hash 14. The full node sends hash 6, hash 12, hash 13, and the Merkle path of transaction 5 to the block header storage device, which can then calculate hash 15 based on hash 6, hash 12, hash 13, and the Merkle path of transaction 5. If the block header storage device finds a Merkle root of a block header that is identical to hash 15 and has been synchronized from the blockchain network, then the device determines that this block header is associated with the DApp, saves it, and confirms that transaction 5 exists in the blockchain and is a successful transaction. Of course, in practical applications, a DApp may initiate or receive more than one transaction. The block header storage device can send a block header retrieval request to the blockchain network only after the DApp has initiated or received a certain number of transactions.

[0056] In one possible implementation, a full node in the blockchain network can locate the target block using a Bloom filter, or it can use other methods to locate the target block; this application does not limit the specific implementation.

[0057] 240. The block header storage device stores the block header information associated with the DAPP into the DAPP.

[0058] Once the block header storage device identifies a block header associated with a DApp, it saves that block header. Conversely, it deletes block headers that are not identified as associated with a DApp.

[0059] In one possible implementation, when a user verifies a transaction associated with a DApp, a block header storage device can be used to verify it using the block header information stored in the DApp. The block header storage device obtains the Merkle tree hash authentication path corresponding to the transaction and the hash value associated with the target transaction under that path from the blockchain network, calculates the Merkle root value, and compares it with the transaction hash value of the block header information stored locally in the DApp—that is, the Merkle root value of the local block header information. If the calculated Merkle root value matches the local block header information's Merkle root value, the block header storage device determines the transaction is successful and outputs a success result back to the user. Conversely, if no block header information's Merkle root value matches the calculated Merkle root value, the block header storage device determines the transaction has failed and outputs a failure result back to the user.

[0060] In one possible implementation, the block header storage device can receive transaction requests initiated by a DApp, which are used to initiate a first transaction to the blockchain network. Before initiating the first transaction, it is necessary to verify whether the second transaction was successful; the verification method is described in section 230 and will not be repeated here. If the second transaction is determined to be successful, the DApp can initiate the first transaction.

[0061] In this scenario, if the second transaction and the first transaction are related, the DApp can only initiate the first transaction after the second transaction has been successfully completed, ensuring the completion of a single transaction set. In this embodiment, the first transaction can be initiated by the DApp, and the second transaction can be received by the DApp. Of course, the first and second transactions can also be unrelated. Furthermore, it is not necessary to verify the success of the second transaction only when the first transaction is about to be initiated; verification can be performed immediately after the second transaction is initiated.

[0062] Through this embodiment, the block header storage device can store the block header information associated with the DApp in a timely and effective manner. When a user attempts to verify a transaction associated with the DApp, the block header storage device can obtain the block header information related to the transaction from the block header information stored in the DApp, thereby verifying the transaction and improving the efficiency of verifying a transaction.

[0063] Please see Figure 4 , Figure 4 This is a schematic diagram of a first case of initiating a block header acquisition request, provided in an embodiment of this application, wherein the executing entity is a block header storage device.

[0064] 410. Determine the first transaction count of the DApp since the last time a block header was included in the DApp.

[0065] The first transaction quantity is the number of transactions initiated by the DAPP, the number of transactions received by the DAPP, or the sum of the number of transactions initiated by the DAPP and the number of transactions received by the DAPP.

[0066] 420. Determine whether the first transaction quantity is greater than the preset value.

[0067] The preset value can be the system setting of the DApp, the setting of the blockchain network for the DApp, or the setting of other nodes. This application embodiment does not limit this.

[0068] 430. If the number of transactions in the first transaction exceeds the preset value, a request to obtain the block header is sent to the blockchain network via the DApp.

[0069] 440. Receive block header information within the block header height range from the blockchain network.

[0070] 450. Determine the block header information associated with the DAPP from the obtained block header information.

[0071] 460. Save the block header information associated with the DApp to the DApp.

[0072] In this embodiment, a block header retrieval request is only initiated after the number of transactions requiring verification in the DAPP reaches a preset value, which can save network resources and improve network utilization.

[0073] Please see Figure 5 , Figure 5 This is a schematic diagram of a second scenario for initiating a block header retrieval request, provided in an embodiment of this application, wherein the executing entity is a block header storage device.

[0074] 510. Initiate a third transaction to the blockchain network via a DAPP.

[0075] 520. Determine whether the time interval between the current time and the initiation time of the third transaction has reached the preset interval.

[0076] 530. If so, then send a block header retrieval request to the blockchain network via the DApp.

[0077] 540. Receive block header information within the block header height range from the blockchain network.

[0078] 550. Determine the block header information associated with the DAPP from the obtained block header information.

[0079] 560. Save the block header information associated with the DApp to the DApp.

[0080] In one possible implementation, the third transaction can also be a transaction received by the DApp. As the recipient of the third transaction, the DApp can still execute a request to send a block header to the blockchain network at a preset interval after receiving the third transaction.

[0081] For example, if a block header storage device initiates a third transaction through a DApp, but has not sent a block header retrieval request to the blockchain network from the time the third transaction was initiated until the current moment, the block header storage device can send a block header retrieval request to the blockchain network at a preset interval after the third transaction was initiated. This preset interval could be ten minutes. After obtaining the corresponding block header information, the device verifies the third transaction and saves the block header related to the DApp. Of course, other transactions may be initiated or received within this preset interval, so the block header storage device can simultaneously initiate block header retrieval requests for multiple transactions.

[0082] In one possible implementation, after the block header storage device verifies the successful completion of the third transaction, the importance level of the third transaction can be determined. If the importance level of the third transaction is lower than a preset level, the first block header information, which is the block header information associated with the third transaction in the block header information stored by the DAPP, is deleted. The importance level can be preset by the DAPP user; or determined based on the transaction type. For example, if the transaction type is a transfer, the importance level of that transaction is set to high, while if the transaction type is an invoice request, the importance level of that transaction is set to low; or different importance levels can be set based on other transaction types; the importance level can also be determined based on the content and amount of the transaction, or based on other reasonable methods. This application embodiment does not limit this. This method allows the deletion of block headers corresponding to unimportant transactions in the DAPP, ensuring that the DAPP has sufficient remaining storage space to store new block headers.

[0083] In one possible implementation, if the importance level of the third transaction is lower than a preset level, it can be determined whether a fourth transaction exists among the transactions initiated and / or received by the DApp. This fourth transaction is different from the third transaction and is related to the first block header information. If no fourth transaction exists, meaning there is no other transaction associated with the DApp in the block containing the third transaction (meaning only the third transaction is associated with the DApp in the block), and the importance level of the third transaction does not meet the preset level, the block header storage device considers that the importance level of the block header corresponding to the block storing the third transaction also does not meet the required importance level. Therefore, the block header storage device deletes the first block header information from the DApp. Of course, if a fourth transaction exists in the block corresponding to the third transaction, the importance level of the fourth transaction can also be verified. If the importance level of the fourth transaction is also lower than the preset level, the block header corresponding to that block can also be deleted. Alternatively, if the remaining storage space of the block header storage device is greater than a preset threshold, the first block header information may not be deleted. The preset threshold for the remaining storage space of the block header storage device can be user-defined or automatically set by the system. Furthermore, even if the remaining storage space of the block header storage device is less than a preset threshold, the first block header may not be deleted; or, even if the remaining storage space of the block header storage device is greater than the preset threshold, the first block header information may be deleted. This application embodiment does not impose limitations on this. Through this method, it is possible to verify whether there is another fourth transaction associated with the DApp in a block corresponding to a third transaction with an importance level lower than a preset level, thus preventing the accidental deletion of the block header corresponding to the third transaction due to its low importance level.

[0084] In this embodiment, when a DApp initiates a third transaction, it needs to send a block header retrieval request to the blockchain network within a preset interval to verify whether the third transaction has been recorded in the blockchain in a timely manner. This ensures the timeliness of transaction verification and enables the block header storage device to verify transactions initiated or received by the DApp in a timely manner.

[0085] Please see Figure 6 , Figure 6 This is a schematic diagram of a block header storage device module provided in an embodiment of this application. The logical structure of the device may include: a sending module 610, a receiving module 620, a processing module 630, and a storage module 640.

[0086] The sending module 610 is used to send a block header retrieval request to the blockchain network through a decentralized application (DApp). The block header retrieval request carries the block header height range to be retrieved.

[0087] The receiving module 620 is used to receive block header information within the block header height range from the blockchain network.

[0088] Processing module 630 is used to determine the block header information associated with the DAPP from the acquired block header information.

[0089] Storage module 640 is used to save the block header associated with the DAPP to the DAPP.

[0090] In one possible implementation, the processing module 630 is further configured to determine, based on the transaction hash value in the acquired block header information, the target block header information related to the transaction initiated and / or received by the DApp. The target block header information is then determined to be the block header information associated with the DApp.

[0091] In one possible implementation, after the storage module 640 saves the block header associated with the DApp to the DApp, the receiving module 620 is further configured to receive a transaction request initiated by the DApp, which requests to initiate a first transaction to the blockchain network; the processing module 630 is further configured to determine a second transaction associated with the first transaction. The sending module 610 is further configured to initiate the first transaction to the blockchain network when the second transaction is successfully verified.

[0092] In one possible implementation, the processing module 630 is further configured to determine the first number of transactions of the DAPP since the last time a block header was included in the DAPP, wherein the first number of transactions is the number of transactions initiated by the DAPP, the number of transactions received by the DAPP, or the sum of the number of transactions initiated by the DAPP and the number of transactions received by the DAPP; determine whether the first number of transactions is greater than a preset value; if the first number of transactions is greater than the preset value, then execute the request to send a block header retrieval request to the blockchain network through the decentralized application DAPP.

[0093] In one possible implementation, the processing module 630 is further configured to initiate a third transaction to the blockchain network via the DApp; determine whether the time interval between the current time and the initiation time of the third transaction reaches a preset interval; if so, execute a request to send a block header retrieval request to the blockchain network via the decentralized application (DApp).

[0094] In one possible implementation, after the storage module 640 saves the block header associated with the DAPP to the DAPP, the processing module 630 is further used to verify whether the third transaction is successful based on the block header information saved by the DAPP; if the third transaction is successful, the importance level of the third transaction is determined; if the importance level of the third transaction is lower than a preset level, the first block header information is deleted from the block header information saved by the DAPP, which is the block header information associated with the third transaction in the block header information saved by the DAPP.

[0095] In one possible implementation, after the processing module 630 determines that the importance level of the third transaction is lower than a preset level, the processing module 630 is further configured to determine whether there is a fourth transaction among the transactions initiated and / or received by the DAPP, which is different from the third transaction and is related to the first block header information; if there is no fourth transaction, the first block header information is deleted from the DAPP.

[0096] Please see Figure 7 , Figure 7 This is a simplified schematic diagram of the physical structure of a block header storage device provided in an embodiment of this application. The device includes a processor 710, a memory 720, and a communication interface 730, which are connected through one or more communication buses.

[0097] Processor 710 is configured to support block header storage device execution. Figure 2 , Figure 4 and Figure 5 The corresponding functions in the method. The processor 710 can be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof.

[0098] The memory 720 is used to store program code, etc. The memory 720 may include volatile memory, such as random access memory (RAM); the memory 720 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 720 may also include a combination of the above types of memory.

[0099] The communication interface 730 is used to send and receive data, information, or messages, and can also be described as a transceiver, transceiver circuit, etc. For example, the communication interface 730 is used to send a block header retrieval request to the blockchain network, or the communication interface 730 is used to receive block header information within a height range, etc.

[0100] In this embodiment of the invention, the processor 710 can call the program code stored in the memory 720 to perform the following operations:

[0101] In one possible implementation, the control communication interface 730 sends a block header retrieval request to the blockchain network via a decentralized application (DApp), the request carrying the requested block header height range; and receives block header information within the block header height range from the blockchain network. The processor 710 calls program code stored in memory 720 to determine the block header information associated with the DApp from the retrieved block header information. Memory 720 saves the block header associated with the DApp to the DApp.

[0102] In one possible implementation, processor 710 calls program code stored in memory 720 to determine, based on the transaction hash value in the acquired block header information, the target block header information related to the transaction initiated and / or received by the DAPP. The target block header information is then determined to be the block header information associated with the DAPP.

[0103] In one possible implementation, after the memory 720 saves the block header associated with the DApp to the DApp, the control communication interface 730 receives a transaction request initiated by the DApp, which requests to initiate a first transaction to the blockchain network. The processor 710 calls the program code stored in the memory 720 to determine a second transaction associated with the first transaction. When the control communication interface 730 verifies the second transaction successfully, it initiates the first transaction to the blockchain network.

[0104] In one possible implementation, the processor 710 calls the program code stored in the memory 720 to determine the first number of transactions of the DAPP since the last block header was included in the DAPP. The first number of transactions is the number of transactions initiated by the DAPP, the number of transactions received by the DAPP, or the sum of the number of transactions initiated by the DAPP and the number of transactions received by the DAPP. The processor 710 determines whether the first number of transactions is greater than a preset value. If the first number of transactions is greater than the preset value, the processor 710 executes the request to send a block header retrieval request to the blockchain network through the decentralized application DAPP.

[0105] In one possible implementation, the processor 710 calls the program code stored in the memory 720 to initiate a third transaction to the blockchain network through the DAPP; determines whether the time interval between the current time and the initiation time of the third transaction reaches a preset interval; if so, it executes the request to send a block header retrieval request to the blockchain network through the decentralized application DAPP.

[0106] In one possible implementation, after the memory 720 saves the block header associated with the DAPP to the DAPP, the processor 710 calls the program code stored in the memory 720 to verify whether the third transaction is successful based on the block header information saved by the DAPP; if the verification of the third transaction is successful, the importance level of the third transaction is determined; if the importance level of the third transaction is lower than a preset level, the first block header information is deleted from the block header information saved by the DAPP, and the first block header information is the block header information associated with the third transaction in the block header information saved by the DAPP.

[0107] In one possible implementation, after the processor 710 calls the program code stored in the memory 720 to determine that the importance level of the third transaction is lower than a preset level, the processor 710 calls the program code stored in the memory 720 to determine whether there is a fourth transaction among the transactions initiated and / or received by the DAPP. This fourth transaction is different from the third transaction and is related to the first block header information. If there is no fourth transaction, the first block header information is deleted from the DAPP.

[0108] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0109] The steps in the method of this invention can be adjusted, combined, or deleted according to actual needs.

[0110] The modules in the processing device of this invention can be merged, divided, or deleted according to actual needs.

[0111] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, storage disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0112] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for storing block headers, characterized in that, include: Determine the first number of transactions of the DAPP since the last time the block header was saved in the decentralized application (DAPP). The first number of transactions is the number of transactions initiated by the DAPP, the number of transactions received by the DAPP, or the sum of the number of transactions initiated by the DAPP and the number of transactions received by the DAPP. If it is determined that the number of the first transactions is greater than a preset value, a block header retrieval request is sent to the blockchain network through a decentralized application (DAPP), and the block header retrieval request carries the block header height range to be retrieved. Receive block header information from the blockchain network within the block header height range; Based on the transaction hash value in the obtained block header information, determine the target block header information related to the transaction initiated and / or received by the DAPP from the obtained block header information; The target block header information is determined to be the block header information associated with the DAPP; The block header information associated with the DAPP is saved to the DAPP.

2. The method according to claim 1, characterized in that, After saving the block header associated with the DAPP to the DAPP, the method further includes: Receive a transaction request initiated by the DApp, the transaction request being used to request the initiation of a first transaction to the blockchain network; Identify the second transaction associated with the first transaction; The success of the second transaction is verified based on the block header information stored in the DAPP. When the verification of the second transaction is successful, the first transaction is initiated to the blockchain network.

3. The method according to claim 1, characterized in that, The method further includes: Initiating a third transaction to the blockchain network through the DAPP; Determine whether the time interval between the current time and the initiation time of the third transaction reaches a preset interval; If so, then execute the step of sending a block header retrieval request to the blockchain network via a decentralized application (DAPP).

4. The method according to claim 3, characterized in that, After saving the block header associated with the DAPP to the DAPP, the method further includes: The success of the third transaction is verified based on the block header information stored in the DAPP. If the verification of the third transaction is successful, the importance level of the third transaction is determined; If the importance level of the third transaction is lower than the preset level, the first block header information is deleted from the block header information saved in the DAPP. The first block header information is the block header information associated with the third transaction in the block header information saved in the DAPP.

5. The method according to claim 4, characterized in that, After determining that the importance level of the third transaction is lower than a preset level, the method further includes: Determine whether a fourth transaction exists among the transactions initiated and / or received by the DAPP, wherein the fourth transaction is different from the third transaction and is related to the first block header information; If the fourth transaction does not exist, the first block header information will be deleted from the DAPP.

6. A block header storage device, characterized in that, include: The sending module is used to send a block header retrieval request to the blockchain network through a decentralized application (DAPP), wherein the block header retrieval request carries the block header height range to be retrieved; A receiving module is configured to receive block header information from the blockchain network within the block header height range; The processing module is used to determine, based on the transaction hash value in the acquired block header information, the target block header information related to the transaction initiated and / or received by the DAPP. The target block header information is determined to be the block header information associated with the DAPP; A storage module is used to save the block header associated with the DAPP to the DAPP; The processing module is further configured to determine the first number of transactions of the DAPP since the last time the block header was stored in the decentralized application (DAPP), wherein the first number of transactions is the number of transactions initiated by the DAPP, the number of transactions received by the DAPP, or the sum of the number of transactions initiated by the DAPP and the number of transactions received by the DAPP; determine whether the first number of transactions is greater than a preset value; if the first number of transactions is greater than the preset value, trigger the sending module to send a block header acquisition request to the blockchain network through the decentralized application (DAPP).

7. A block header storage device, characterized in that, include: A processor and a memory interconnected thereto, wherein the memory is used to store a computer program, the computer program including program instructions, and the processor is configured to invoke the program instructions to perform the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 5.

Images