A block processing method and related device

Abstract

This application provides a block processing method and related equipment. The method includes: acquiring block data constructed by a block construction object, and acquiring the block signature information and resource transfer amount corresponding to the block data; if the acquired block data meets the block selection conditions, verifying the block signature information of the acquired block data; if the signature information of the acquired block data passes verification, updating the block record data using the resource transfer amount and the acquired block data, wherein the updated block record data is used to record the maximum resource transfer amount among the acquired resource transfer amounts, and the block data corresponding to the maximum resource transfer amount; and performing on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data. This application embodiment can reduce the verification cost during the on-chain process of block data.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a block processing method and related equipment. Background Technology

[0002] A blockchain is a data structure composed of several blocks of data linked together by hash values. Each block consists of transaction data generated within a certain period, packaged by computer nodes in the blockchain network that have the right to record transactions, and uploaded to the blockchain based on a consensus mechanism. The blockchain consensus mechanism is an agreement among computer nodes in the blockchain network to reach consensus on the transactions and states in the block data, preventing malicious acts such as transaction tampering, double-spending, and Byzantine attacks, thus ensuring the security and reliability of the blockchain.

[0003] However, in some cases, there may be multiple requests to upload block data to the blockchain. In this case, each block data needs to be verified in order to find the appropriate block data to upload to the blockchain, which makes the verification cost of the block data upload process quite high. Summary of the Invention

[0004] This application provides a block processing method and related equipment, which can reduce the verification cost during the process of uploading block data to the blockchain.

[0005] On one hand, embodiments of this application provide a block processing method, the method comprising:

[0006] Obtain the block data constructed by the block construction object, and obtain the block signature information of the block data and the resource transfer amount corresponding to the block data;

[0007] If the obtained block data meets the block selection criteria, then verify the block signature information of the obtained block data.

[0008] If the signature information of the acquired block data is verified, the block record data is updated using the resource transfer amount and the acquired block data. The updated block record data is used to record the maximum resource transfer amount among the acquired resource transfer amounts, and the block data corresponding to the maximum resource transfer amount.

[0009] The block data corresponding to the maximum resource transfer amount recorded in the updated block record data is processed on the blockchain.

[0010] On one hand, embodiments of this application provide a block processing method, the method comprising:

[0011] The system receives a block challenge request sent by a relay node after the verification of the block data to be verified fails. The block challenge request includes the block data to be verified and the corresponding block signature information. The block data to be verified is the block data corresponding to the maximum resource transfer amount obtained by the relay node from the block record data stored by the relay node. The block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node.

[0012] The block signature information corresponding to the block data to be verified and the block data to be verified are verified to obtain the challenge result of the block data to be verified.

[0013] Return the challenge result to the relay node. The challenge result indicates whether the challenge initiated by the relay node for the verification result of the block data to be verified was successful or not.

[0014] On one hand, embodiments of this application provide a block processing method, the method comprising:

[0015] Obtain multiple transaction data.

[0016] Sort multiple transaction data and package the sorted transaction data to generate block data;

[0017] Based on multiple transaction data, determine the amount of resources transferred corresponding to the block data;

[0018] The block data is signed to obtain the block signature information.

[0019] On one hand, embodiments of this application provide a block processing method, the method comprising:

[0020] Receive block header data sent by relay nodes; the block data corresponding to the maximum resource transfer amount recorded in the updated block record data includes the block header data; the updated block record data is obtained by the relay node after the acquired block data meets the block selection conditions and the block signature information of the acquired block data is verified, by updating the block record data with the resource transfer amount corresponding to the acquired block data and the acquired block data.

[0021] Sign the block header data to obtain the block header signature information;

[0022] The block header signature information is returned to the relay node so that the relay node can process the block data corresponding to the maximum resource transfer amount recorded in the updated block record data on the blockchain based on the block header signature information.

[0023] Accordingly, embodiments of this application also provide a block data processing apparatus, which includes one or more units for executing the aforementioned block processing method.

[0024] Accordingly, embodiments of this application provide a computer device, which includes:

[0025] A processor is used to execute computer programs;

[0026] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the block processing method described above.

[0027] Accordingly, embodiments of this application provide a computer-readable storage medium storing a computer program that is loaded by a processor and executed as described above in the block processing method.

[0028] Accordingly, this application provides a computer program product, which includes a computer program or computer instructions, and the computer program or computer instructions implement the above-described block processing method when executed by a processor.

[0029] In this embodiment, block data constructed by a block construction object is obtained, along with the block signature information and resource transfer amount corresponding to the block data. If the obtained block data meets the block selection criteria, the block signature information of the obtained block data is verified. If the signature information of the obtained block data passes verification, the block record data is updated using the resource transfer amount and the obtained block data. The updated block record data is used to record the maximum resource transfer amount among the obtained resource transfer amounts, and the block data corresponding to the maximum resource transfer amount. The block data corresponding to the maximum resource transfer amount recorded in the updated block record data is then processed on-chain. It is evident that this embodiment can obtain block data constructed by a block construction object and verify the block signature information of the block data when the block data meets the block selection criteria. This eliminates the need to verify every piece of obtained block data, and only the block signature information is verified during verification, significantly reducing verification or computation costs. Furthermore, by updating the block record data using the resource transfer amount corresponding to the acquired block data and the acquired block data after the signature information of the acquired block data has been verified, the appropriate block data to be uploaded to the chain (i.e. the block data corresponding to the maximum resource transfer amount) can be recorded through the block record data. This enables the determination of appropriate block data to be uploaded to the chain from multiple block data, while only verifying the appropriate block data to be uploaded to the chain, thereby reducing the verification cost in the process of uploading block data to the chain. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1A An architecture diagram of a blockchain network provided for an embodiment of this application;

[0032] Figure 1B A schematic diagram of a blockchain structure is provided as an embodiment of this application;

[0033] Figure 1C A block generation schematic diagram provided for an embodiment of this application;

[0034] Figure 1D An architecture diagram of a block processing system provided in this application embodiment;

[0035] Figure 2 A flowchart illustrating a block processing method provided in an embodiment of this application;

[0036] Figure 3 A flowchart illustrating a block processing method provided in an embodiment of this application;

[0037] Figure 4 A flowchart illustrating a block processing method provided in an embodiment of this application;

[0038] Figure 5 A flowchart illustrating a block processing method provided in an embodiment of this application;

[0039] Figure 6 A flowchart illustrating a block processing method provided in an embodiment of this application;

[0040] Figure 7 This is a schematic diagram of the structure of a block processing device provided in an embodiment of this application;

[0041] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0042] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0043] This application provides a block processing scheme that introduces a relay node to match block building objects and block proposal objects. The relay node can obtain the block data built by at least one block building object and the corresponding resource transfer amount (i.e., bidding price). The resource transfer amount corresponding to the block data refers to the amount of resources that the corresponding block building object needs to transfer to the block proposal object after the block data is proposed and put on the chain. The following description uses a block construction object as an example. After obtaining the block data constructed by the block construction object and the resource transfer amount (such as the bid price) of the block data, the relay node does not immediately verify the obtained block data. Instead, it determines whether the block data meets the block selection conditions, such as whether the resource transfer amount corresponding to the block data is the maximum resource transfer amount, or whether the block construction object has stored a certain amount of proof resources (such as deposits). If the block data meets the block selection conditions, the relay node verifies the block signature information of the block data. After the block signature information of the block data is verified, the relay node updates the block record data using the resource transfer amount and the block data. The updated block record data is used to record the maximum resource transfer amount among the obtained resource transfer amounts and the block data corresponding to the maximum resource transfer amount. In this way, when entering the block proposal, the block data corresponding to the maximum resource transfer amount can be obtained from the updated block record data for asynchronous verification. As can be seen, the solution provided in this application is an optimistic block relay scheme. It records the block data corresponding to the maximum resource transfer amount (i.e., the block data that won the bid), thus enabling verification of only the winning block data before it is added to the chain. This significantly reduces the verification delay during the block data addition process. Relay nodes do not need to immediately verify every block, reducing the verification cost and computational cost of the relay nodes. Furthermore, since it is not necessary to verify a large amount of block data before the auction ends, but only the block data corresponding to the maximum resource transfer amount is verified, the operating cost of the relay nodes is reduced. Additionally, since verification only needs to be performed on the block signature information of blocks that meet the block selection criteria, relay nodes can process a large amount of block data from various block building objects before entering the block proposal stage, thereby increasing the amount of block data processed by the relay nodes.

[0044] To prevent malicious behavior by block-building objects, the solution provided in this application introduces a deposit and challenge mechanism. That is, the block-building object needs to deposit a certain amount of proof resources in advance to prove that it does not have malicious behavior. After the relay node fails to verify the block data, it can initiate a challenge against the block data to challenge the verification result of the block data to the block arbitration node. After the challenge is successful (i.e. the verification result of the block data is confirmed to be correct), the proof resources deposited by the block-building object are deducted. By introducing the deposit and challenge mechanism, the interests of the block proposal object and the block-building object's lack of malicious intent can be ensured.

[0045] Regarding blockchain, it can be maintained by a blockchain network; please refer to [link / reference]. Figure 1A Blockchain network 100 refers to a system for data sharing between node devices. This blockchain network may include multiple node devices 101, which can refer to various clients within the blockchain network. Each node device 101, during normal operation, can receive input information and maintain shared data within the blockchain network based on this received input information. To ensure information interoperability within the blockchain network, information connections can exist between each node device, allowing for information transmission. For example, when any node device in the blockchain network receives input information, other node devices in the blockchain network obtain this input information according to a consensus algorithm and store it as part of the shared data, ensuring data consistency across all node devices in the blockchain network.

[0046] Each node in a blockchain network has a corresponding node device identifier. Furthermore, each node can store the node device identifiers of other nodes in the network. This allows for the subsequent broadcasting of generated blocks (i.e., block data) to other nodes in the blockchain network based on their identifiers. Each node can maintain a list of node device identifiers as shown in the table below, storing the node device name and its corresponding identifier in this list. The node device identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node device. Table 1 uses IP addresses as an example.

[0047] Node device name Node device identifier Node device 1 117.114.151.174 Node device 2 117.116.189.145 … … Node device N 119.123.XXX.XXX

[0048] Each node in a blockchain network stores the same blockchain record. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 1BA blockchain consists of multiple blocks. The genesis block includes a block header (i.e., block header data) and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0049] When generating the individual blocks in the blockchain, see Figure 1C When a node device hosting the blockchain receives input information (such as transaction data), it verifies the input information. After verification, it stores the input information in a memory pool and updates the hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and attempts to calculate the feature value multiple times using different random numbers, ensuring that the calculated feature value satisfies the following formula:

[0050] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0051] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0052] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node device where the blockchain resides sends the newly generated block to other node devices in its blockchain network based on the node device identifiers of other node devices in the blockchain network. The other node devices verify the newly generated block and, after completing the verification, add the newly generated block to their stored blockchain.

[0053] Please see Figure 1D This is an architecture diagram of a block processing system provided in an embodiment of this application. The block processing system may include at least one block building object (such as...). Figure 1DBlock building object 201, block building object 202), relay node 203, and at least one block proposal object (such as...) Figure 1D The block proposal objects 204 and 205, and the block arbitration node 206 are included. It should be understood that the number of block proposal objects and the number of block building objects are not limited in this embodiment. Wherein:

[0054] ① Block building objects 201 and 202 refer to node devices in the blockchain network that have not obtained the right to record transactions or the qualification to propose blocks. Block building objects can construct block data; that is, they can obtain transaction data from the mempool, package it to generate block data, and provide the corresponding resource transfer amount for the block data.

[0055] ② Relay node 203 is used to match block building objects and block proposal objects. That is, relay node 203 can receive the block data built by each block building object, and verify the block signature information of the block data when the received block data meets the block selection conditions. In addition, relay node 203 can be used to record the maximum resource transfer amount among the obtained resource transfer amounts, and the block data corresponding to the maximum resource transfer amount. When entering the block data proposal stage, relay node 203 can send the block data corresponding to the maximum resource transfer amount to the block proposal object so that the block proposal object can propose the block data to be put on the chain.

[0056] The relay node 203 involved in this application embodiment can be a node device in a blockchain network, or it can be a computer device set up outside the blockchain network that can communicate with the block proposal object and the block building object. In one implementation, the relay node 203 can be a trusted third-party node that can provide services to the block proposal object and the block building object. These services may include, but are not limited to, verifying the block data constructed by the block building object, providing the block proposal object with the block data corresponding to the current maximum resource transfer amount, etc. In another implementation, the relay node can be an off-chain relay.

[0057] ③ Block proposal object 204 and block proposal object 205 can be node devices that have obtained the right to record transactions or the qualification to propose blocks in the blockchain network. When entering the block data proposal stage, block proposal object 204 and block proposal object 205 can obtain the block data corresponding to the recorded maximum resource transfer amount from relay node 203 and propose it so that the block data corresponding to the recorded maximum resource transfer amount can be put on the chain.

[0058] ④ In this embodiment, a block arbitration node 206 is provided. This block arbitration node 206 can be used to store a preset number of proof resources stored by the block building object, such as a deposit. Furthermore, the block arbitration node 206 allows relay objects to make challenges. That is, when the relay node 203 fails to verify the block data, it can send a block challenge request to the relay node 203 as the block data to be verified. This block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node. The verification result indicates that the verification of the block data to be verified has failed. In other words, the block challenge request can challenge the correctness of the verification result of the block data to be verified to the block arbitration node.

[0059] The block arbitration node 206 can be used to receive block challenge requests sent by the relay node 203. The block arbitration node verifies the block data in the block challenge request to determine whether the challenge initiated by the relay node 203 against the verification result of the block data is successful. In addition, if it is determined that the relay node 203's challenge against the verification result of the block data is successful or the challenge fails, the node will reward or punish the block building object and the block proposal object according to the corresponding penalty strategy to prevent the block building object from having malicious behavior and to ensure the rights of the block proposal object and the block building object have no malicious intent.

[0060] It should be understood that the block arbitration node 206 can be deployed on computer devices (such as servers, terminal devices, etc.) independent of the blockchain network, i.e., as shown below. Figure 1D As shown; of course, the block arbitration node 206 can also be deployed in other node devices besides the block proposal object and the block building object; or the block arbitration node 206 can also be deployed in the block proposal object or the block building object; in some implementations, the block arbitration node 206 is equipped with an arbitration smart contract, which can respond to the block challenge request sent by the relay node, verify the block data to determine whether the relay node 203 has successfully challenged, and reward or punish the block building object, the block proposal object, etc. according to the penalty strategy (such as deducting a certain amount of proof resources from the block building object and transferring the deducted proof resources to the block proposal object and the relay node, etc.).

[0061] As can be seen, the block processing system provided in this application involves computer devices such as block building objects, relay nodes, at least one block proposal object, and block arbitration nodes. Through the interaction between these computer devices, the block data corresponding to the maximum resource transfer volume can be uploaded to the blockchain. This reduces the computational costs of block building objects, relay nodes, and block proposal objects, and better realizes the verification cost in the process of uploading block data to the blockchain. Furthermore, the introduction of block arbitration nodes enables the challenge of block data, which can better maintain the security and stability of the entire block processing system.

[0062] The block processing method mentioned in the embodiments of this application will be described below.

[0063] Based on the architecture diagram of the above block processing system, please refer to... Figure 2 This is a flowchart illustrating a block processing method provided in an embodiment of this application. The block processing method is applied to a block processing system, and is implemented through data interaction between a block proposal object, a relay node, a block building object, and a block arbitration node within the block processing system. The block proposal object, relay node, and block building object are all computer devices, while the block arbitration node can be deployed on a separate node device. For ease of understanding, the following description uses the example of a block arbitration node deployed on a separate node device. It should be understood that the block processing system can be all or part of the aforementioned blockchain network, or the block proposal object and block building object can be node devices within the aforementioned blockchain network, while the relay node is a computer device outside of a blockchain network, such as an off-chain relay. The block processing method provided in this embodiment of the application can include at least the following steps S201-S221:

[0064] S201. The block building object stores a preset number of proof resources into the block arbitration node.

[0065] When a block-building object wants to build block data, it needs to deposit a preset amount of proof resources (such as a deposit) with the block arbitration node. The preset amount (such as d) can be set according to needs. The proof resources are used to prove the credibility of the block-building object, or to prevent the block-building object from generating problematic (such as illegal) block data. By depositing a certain amount of proof resources, it is possible to prevent the block-building object from acting maliciously in subsequent processes. The block-building objects involved in this application embodiment can be one or more. Each block-building object can deposit a preset amount of proof resources with the block arbitration node before building block data. Of course, each block-building object can deposit a different amount of proof resources with the block arbitration node. For example, if block-building object 1 has a lot of historically linked block data, it can deposit a small amount of proof resources with the block arbitration node. If block-building object 2 has a little historically linked block data, it can deposit a larger amount of proof resources with the block arbitration node.

[0066] S202, Block construction object constructs block data.

[0067] Specifically, a block-building object can construct block data with the goal of maximizing its own benefit. For example, a block-building object can construct block data according to the maximum amount of resources it can acquire. In one implementation, the block-building object can select multiple transaction data from the mempool to include in the block in order to maximize its own benefit. In another implementation, the block-building object can select multiple transaction data from the mempool, sort these transaction data, and then package the sorted transaction data into a block.

[0068] S203. The block construction object determines the amount of resource transfer corresponding to the block data being constructed.

[0069] In this process, block data needs to be proposed by a block proposal object. At this point, multiple block building objects may have constructed block data. Each block building object needs to provide a corresponding resource transfer amount so that the block proposal object can select the block data to propose based on the resource transfer amounts provided by each block building object. In other words, the resource transfer amount refers to the amount of resources that a block building object needs to transfer to the block proposal object after the corresponding block data is proposed and successfully added to the blockchain. This resource transfer amount can also be called the bidding price.

[0070] In one implementation, a bidding strategy is set. The block building object can determine the resource transfer amount corresponding to the constructed block data based on multiple transaction data and the bidding strategy. For example, if multiple transaction data can yield a target resource amount after execution, the bidding strategy could include setting the resource transfer amount to 50% of the target resource amount. In this case, the block building object determines that the resource transfer amount corresponding to the constructed block data is 50% of the target resource amount. In another implementation, if the bidding strategy aims to maximize on-chain inclusion, the block building object can set the resource transfer amount corresponding to the constructed block data to be as large as possible, while ensuring its own interests, so that subsequent block proposal objects can propose their own block data.

[0071] S204. The block construction object signs the block data to obtain the block signature information of the block data.

[0072] Specifically, the block building object uses its private key to sign the block data, obtaining the block signature information. Optionally, the block building object can use its private key to sign the block data and the corresponding resource transfer amount, obtaining the block signature information, i.e., using the private key to sign...<block,bid> Perform signature processing to obtain the block signature information `sign`. Here, `block` represents the block data, and `bid` represents the amount of resources transferred.

[0073] S205. The relay node obtains block data, block signature information, and the resource transfer amount corresponding to the block data from the block construction object. Specifically, the block construction object will...<block,bid> The block data is sent to the relay node for bidding. In turn, the relay node receives the block data sent by the block building object and obtains the block signature information and the resource transfer amount corresponding to the block data.

[0074] S206. The relay node verifies whether the obtained block data meets the block selection conditions.

[0075] The relay node's verification of whether the acquired block data meets the block selection criteria can include the following implementation methods:

[0076] Method 1: The relay node maintains block record data, which records the current maximum resource transfer amount. The relay node can determine whether the resource transfer amount (bid) corresponding to the acquired block data is greater than the current maximum resource transfer amount (max_bid) recorded in the block record data. If it is determined that the resource transfer amount corresponding to the acquired block data is greater than the current maximum resource transfer amount recorded in the block record data (i.e., bid > max_bid), then the acquired block data meets the block selection condition, and step S207 is executed. If it is determined that the resource transfer amount corresponding to the acquired block data is less than or equal to the current maximum resource transfer amount recorded in the block record data, then the acquired block data does not meet the block selection condition.

[0077] Method 2: A confidence score is recorded for the block construction object. This confidence score indicates the level of confidence in the block construction object; the higher the confidence level, the lower the probability of malicious behavior. The relay node can determine whether the confidence score of the block construction object is greater than a preset confidence score. If the confidence score is greater than the preset confidence score, the obtained block data is determined to meet the block selection criteria, and step S207 is executed. If the confidence score is less than or equal to the preset confidence score, the obtained block data is determined not to meet the block selection criteria.

[0078] Method 3: If the block arbitration node stores a preset number of proof resources for the block building object, a resource query request is sent to the block arbitration node to check whether the block building object corresponding to the acquired block data has stored the preset number of proof resources. The query result returned by the block arbitration node based on the resource query request is received. If the query result indicates that the block building object corresponding to the acquired block data has stored the preset number of proof resources, the acquired block data is determined to meet the block selection conditions, and step S207 is executed. If the query result indicates that the block building object corresponding to the acquired block data has not stored the preset number of proof resources, the acquired block data is determined not to meet the block selection conditions.

[0079] Method 4: Determine whether the acquired block data meets the block selection criteria by combining two of the following: the resource transfer amount corresponding to the acquired block data, whether the block construction object corresponding to the acquired block data contains a preset amount of proof resources, and the confidence score of the block construction object. In one implementation, if the resource transfer amount corresponding to the acquired block data is greater than the maximum resource transfer amount currently recorded in the block record data, and the confidence score of the block construction object is greater than the preset confidence score, then the acquired block data is determined to meet the block selection criteria. Specifically, if the resource transfer amount corresponding to the acquired block data is greater than the maximum resource transfer amount currently recorded in the block record data, then it is determined whether the confidence score of the block construction object is greater than the preset confidence score. If the confidence score of the block construction object is greater than the preset confidence score, then the acquired block data is determined to meet the block selection criteria, and step S207 is executed. If the resource transfer amount corresponding to the obtained block data is less than or equal to the maximum resource transfer amount currently recorded in the block record data, then the obtained block data does not meet the block selection conditions. Alternatively, if the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, but the confidence score of the block construction object is less than or equal to the preset confidence score, then the obtained block data does not meet the block selection conditions.

[0080] In another implementation, if the query result indicates that the block building object corresponding to the obtained block data has stored a preset number of proof resources, and the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, then the obtained block data is determined to meet the block selection conditions, and step S207 is executed. Specifically, if the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, a resource query request is sent to the block arbitration node. The resource query request is used to query whether the block building object corresponding to the obtained block data has stored a preset number of proof resources; the query result returned by the block arbitration node based on the resource query request is received; if the query result indicates that the block building object corresponding to the obtained block data has stored a preset number of proof resources, then the obtained block data is determined to meet the block selection conditions. If the resource transfer amount corresponding to the obtained block data is less than or equal to the maximum resource transfer amount currently recorded in the block record data, then the obtained block data is determined not to meet the block selection conditions. Alternatively, if the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, but the query result indicates that the block construction object corresponding to the obtained block data has not stored the preset number of proof resources, then it is determined that the obtained block data does not meet the block selection conditions.

[0081] It should be understood that the determination of whether the acquired block data meets the block selection criteria can also be made by combining three factors: the resource transfer amount corresponding to the acquired block data, whether the block building object corresponding to the acquired block data contains a preset number of proof resources, and the confidence score of the block building object. That is, if the query result indicates that the block building object corresponding to the acquired block data contains a preset number of proof resources, and the resource transfer amount corresponding to the acquired block data is greater than the maximum resource transfer amount currently recorded in the block record data, and the confidence score of the block building object is greater than the preset confidence score, then the acquired block data is determined to meet the block selection criteria, and step S207 is executed; otherwise, the acquired block data is determined not to meet the block selection criteria. If it is determined that the acquired block data does not meet the block selection criteria, the relay node does not need to perform any operation on the acquired block data.

[0082] As can be seen, the embodiments of this application can more accurately determine whether the block data obtained by the relay node meets the block selection conditions by using the resource transfer amount corresponding to the block data obtained by the relay node, whether the block construction object corresponding to the obtained block data has a preset number of proof resources, and the confidence score of the block construction object. This allows the relay node to verify only the block data that meets the block selection conditions, greatly reducing the computational cost of the relay node and increasing the amount of block data that the relay node can process.

[0083] S207. If the obtained block data meets the block selection conditions, the relay node verifies the block signature information of the obtained block data.

[0084] The verification of the block signature information of the acquired block data can be achieved by using the public key of the corresponding block building object to verify the block signature information (sign) of the acquired block data. If the block signature information verification passes, step S208 is executed; if the block signature information verification fails, the acquired block data is discarded. It should be understood that, when the acquired block data meets the block selection conditions, step S207 only verifies the block signature information of the acquired block data, without verifying the execution of the block data. This reduces the computational cost for relay nodes in processing block data constructed by block building objects, and also enables relay nodes to process more bids for block building objects more quickly. In other words, relay nodes can process block data constructed by more block building objects.

[0085] S208. If the signature information of the acquired block data is verified, the relay node updates the block record data using the resource transfer amount and the acquired block data.

[0086] The block record data is used to record the maximum resource transfer amount among all resource transfer amounts acquired by the relay node. If the acquired block data meets the block selection condition (i.e., the resource transfer amount corresponding to the acquired block data is greater than the maximum resource transfer amount recorded in the block record data), then updating the block record data using the resource transfer amount and the acquired block data can include: updating the maximum resource transfer amount recorded in the block record data to the resource transfer amount corresponding to the acquired block data (i.e., updating the `max_bid` recorded in the block record data to the resource transfer amount `bid`), and recording the acquired block data and the corresponding block signature information in the block record data. The updated block record data will then contain <<block,bid> It should be understood that when the maximum resource transfer amount recorded in the block record data is updated to the resource transfer amount corresponding to the acquired block data, then the maximum resource transfer amount recorded in the updated block record data is the same as the resource transfer amount corresponding to the acquired block data.

[0087] As can be seen, the relay node verifies the block signature information of the constructed block data and records the maximum resource transfer amount through the block record data. In this way, when the block proposal object makes a block proposal later, the relay node can directly verify the block data corresponding to the maximum resource transfer amount (i.e. the block data that wins the bid). This greatly reduces the simulation delay in the block data auction process, which allows the relay node to process more block data within a fixed block interval.

[0088] S209. The block proposal object queries the relay node for the current maximum resource transfer amount and the block header data included in the block data corresponding to the current maximum resource transfer amount.

[0089] The block proposal object has the authority to propose blocks. When the block proposal object enters the block proposal phase, it queries the relay node for the current maximum resource transfer amount and the block header data included in the block data corresponding to the current maximum resource transfer amount. The relay node can obtain the block header data included in the block data corresponding to the current maximum resource transfer amount from the updated block record data and return the block header data. It is important to note that the block header does not reveal information about the block body (i.e., the transaction data and sorting order within the block data).

[0090] S210, The relay node returns the block header data to the block proposal object. Correspondingly, the block proposal object can receive the block header data returned by the relay node.

[0091] S211. The block proposal object signs the block header data to obtain the block header signature information. Specifically, the relay node can use its own private key to sign the block header data to obtain the block header signature information.

[0092] S212. The block proposal object returns the block header signature information to the relay node to obtain the corresponding block data. Correspondingly, the relay node can receive the block header signature information returned by the block proposal object.

[0093] S213. The relay node verifies the block header signature information and, after successful verification, adds the block header signature information to the block data corresponding to the maximum resource transfer amount recorded in the updated block record data.

[0094] When the block header signature information is added to the block data corresponding to the maximum resource transfer amount recorded in the updated block record data, the block data with the added block header signature information becomes valid. Valid means that the corresponding block data is proposed to be added to the chain.

[0095] S214. Verify the block data with added block header signature information and obtain the verification result.

[0096] Verification of block data with added block header signature information may include at least one of the following: a) verifying whether the block data to be verified is an invalid block; b) verifying whether the block proposal object has obtained the corresponding resource transfer amount from the block data. These will be elaborated on below:

[0097] a. Verify whether the block data is invalid. Specifically, step S214 may include: performing a validity check on the block data with added block header signature information. If the validity check of the block data with added block header signature information passes, the block data is determined to be a valid block data, and there is no problem with the block data. A verification result indicating successful verification of the block data with added block header signature information is obtained. If the validity check of the block data with added block header signature information fails, the block data is determined to be an invalid block data, and there is a problem with the block data. A verification result indicating failed verification of the block data with added block header signature information is obtained.

[0098] The validity verification of block data containing multiple transaction data entries, especially for blocks with added block header signatures, can include: verifying whether each transaction is signed; and verifying whether the format of the block data conforms to specifications. If each transaction is signed and the block data format conforms to specifications, the validity verification of the block data with added block header signatures is considered successful; otherwise, the validity verification is considered unsuccessful.

[0099] b. Verify whether the block proposal object has obtained the corresponding resource transfer amount from the block data. The block data corresponding to the maximum resource transfer amount in the updated block record data includes multiple transaction data, and includes the resource transfer amount used to indicate that it needs to be transferred from the corresponding block construction object to the block proposal object. The indicated resource transfer amount is the maximum resource transfer amount. Step S214 may include: obtaining the account change information of the block proposal object after the execution of multiple transaction data in the block data with added block header signature information; if the account change information indicates that the block proposal object has received the maximum resource transfer amount, it means that the block proposal object can obtain the resource transfer amount from the block data, and a verification result of successful verification of the block data with added block header signature information is obtained; if the account change information indicates that the block proposal object has not received the maximum resource transfer amount, it means that the block proposal object cannot obtain the corresponding resource transfer amount from the block data, and it is determined that there is a problem with the block data, and a verification result of failed verification of the block data with added block header signature information is obtained.

[0100] It should be understood that verifying block data with added block header signature information can also result in the following: Performing a validity check on the block data with added block header signature information; if the validity check passes, obtaining the account change information of the block proposal object after the execution of multiple transactions within the block data with added block header signature information; if the account change information indicates that the block proposal object received the maximum resource transfer amount, then a verification result indicating successful verification of the block data with added block header signature information is obtained. Conversely, if the validity check fails and / or if the account change information indicates that the block proposal object did not receive the maximum resource transfer amount, then a verification result indicating failed verification of the block data with added block header signature information is obtained.

[0101] S215. If the verification result indicates that the block data with added block header signature information has been successfully verified, the relay node will broadcast the block data with added block header signature information, or return the block data with added block header signature information to the block proposal object, so that the block proposal object will broadcast the block data with added block header signature information onto the chain.

[0102] In this process, relay nodes broadcast block data with added block header signatures. Block proposal targets can then access this block data. Broadcasting prevents block proposal targets from extracting transaction data from the block data they receive from block builder targets and constructing their own blocks, thus protecting the rights of block builder targets to some extent. When relay nodes return block data with added block header signatures to block proposal targets, the block proposal targets are required to broadcast this additional block data to the blockchain. This prevents situations where relay nodes fail to broadcast block data. Alternatively, relay nodes can both broadcast and return block data with added block header signatures to block proposal targets, enabling the block proposal targets to broadcast this additional block data to the blockchain.

[0103] S216. If the verification result indicates that the verification of block data with added block header signature information fails, then the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is identified as the block data to be verified. A block challenge request is sent to the block arbitration node. This block challenge request includes the block data to be verified and the corresponding block signature information. This block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node. That is, after the block data verification fails, the relay node can use the block data as the block data to be verified and initiate a block challenge request to the block arbitration node to challenge the block arbitration node that its verification result for the block data to be verified is correct.

[0104] S217. The block arbitration node responds to the block challenge request by verifying the block signature information corresponding to the block data to be verified and the block data to be verified, and obtains the challenge result of the block data to be verified.

[0105] A block challenge request is used to challenge the verification result of the block data to be verified. This verification result indicates that the verification of the block data to be verified has failed. Therefore, a block challenge request challenges the failure of the verification of the block data to be verified, i.e., it challenges the existence of a problem with the block to be verified (such as invalid block data or resource transfer amounts that the block proposal object cannot obtain from the block data). Specifically, the block arbitration node can use the public key of the block construction object of the block data to be verified to verify the block signature information corresponding to the block data to be verified, to confirm whether the block data to be verified was signed by the corresponding block construction object. If the block signature information of the block data to be verified is successfully verified, the block arbitration node then verifies the block data to be verified.

[0106] The block arbitration node verifies the block data to be verified, including: whether the block data is invalid and whether the block proposal object can obtain the corresponding resource transfer amount from the block data. If the block data to be verified is valid and the block proposal object can obtain the corresponding resource transfer amount from the block data, the block arbitration node successfully verifies the block data, indicating that the block data is not problematic. It then generates a challenge result indicating that the relay node's verification of the block data failed, meaning that the relay node encountered a problem in verifying the block data. If the block data to be verified is invalid and the block proposal object cannot obtain the corresponding resource transfer amount from the block data, the block arbitration node fails to verify the block data.

[0107] If the block arbitration node fails to verify the data of the block to be verified and / or fails to verify the block signature information corresponding to the data of the block to be verified, it indicates that there is a problem with the data of the block to be verified. In this case, a challenge result initiated by the relay node against the verification result of the data of the block to be verified is generated, meaning that the relay node's verification result of the data of the block to be verified is correct. The process by which the block arbitration node verifies the data of the block to be verified is similar to the process described above for the relay node to verify the data of the block with the added block header signature information, and will not be repeated here.

[0108] S218. If the challenge result indicates that the verification data challenge initiated by the relay node against the block data to be verified is successful, the block arbitration node deducts the first number of proof resources and the second number of proof resources from the preset number of proof resources stored in the block construction object.

[0109] If the challenge result indicates that the verification data challenge initiated by the relay node against the block data to be verified is successful, the block arbitration node can deduct a preset number of proof resources stored in the block building object, and divide the preset number of proof resources into a first number of proof resources and a second number of proof resources according to the strategy. For example, the strategy specifies that the relay node receives 1 / 5 of the proof resources and the block proposal object receives 4 / 5 of the proof resources; if the preset number of proof resources is d, then the preset number of proof resources is allocated according to this strategy, that is, the first number of proof resources is 1 / 5d; the second number of proof resources is 4 / 5d. Of course, it is also possible to deduct part of the proof resources stored in the corresponding block building object.

[0110] S219, The block arbitration node transfers the first number of proof resources to the relay node.

[0111] The block arbitration node transfers the first number of proof resources to the relay node. This can cover the cost of the relay node initiating verification on the one hand, and encourage the relay node to initiate verification on the other hand, thereby better controlling the block building object from acting maliciously.

[0112] S220, The block arbitration node transfers a second number of proof resources to the block proposal object of the block data to be verified.

[0113] The block arbitration node transfers a second number of proof resources to the block proposal object whose block data is to be verified. This can compensate the block proposal object for the loss of resource transfer during the bidding process, and also compensate for the loss of block reward due to the inability to publish block data.

[0114] S221. The block arbitration node returns a message to the relay node indicating that the verification data challenge for the block data to be verified has been successful.

[0115] In this embodiment, on the one hand, the relay node determines whether the acquired block data meets the block selection conditions, and if the acquired block data meets the block selection conditions, it verifies the block signature information of the acquired block data. In this way, when multiple block data compete to be uploaded to the chain, the relay node does not need to verify each acquired block data, but only verifies the block signature information, which reduces the verification cost of uploading block data to the chain to a certain extent and reduces the computational cost of the relay node. On the other hand, after the block signature information of the acquired block data is verified, the relay node can update the block record data with the resource transfer amount corresponding to the acquired block data. This will ensure that the updated block record data contains the maximum resource transfer amount and the corresponding block data. When the block proposal object makes a block proposal, it can directly obtain the block data corresponding to the maximum resource transfer amount from the updated block record data and propose the block data corresponding to the maximum resource transfer amount. In this way, the relay node only needs to verify the block data corresponding to the maximum resource transfer amount (i.e., the block data corresponding to the maximum resource transfer amount is the block data that wins the bid), which can also reduce the computational cost of the relay node. Furthermore, the block building object stores a certain amount of proof resources, which can prevent malicious behavior of the block building object and ensure the security of the entire block processing system. In addition, the embodiments of this application provide a challenge mechanism. After the block data verification fails, the relay node can initiate a block challenge request to the block arbitration node to challenge the verification result of the block data. In the event that the block arbitration node successfully challenges the verification result of the block data (i.e. the block data has a problem), the proof resources of the block building object are deducted and transferred to the relay node and the block proposal object respectively. This ensures the interests of the relay node and the block building object have no malicious intent, and also ensures the security of the entire block processing system.

[0116] Please see Figure 3 This is a flowchart illustrating a block processing method provided in an embodiment of this application. The block processing method is applied to a block processing system, which includes a block proposal object, a relay node, a block construction object, and a block arbitration node; the method is applied to the relay node in the block processing system. In one possible implementation, the relay node is an off-chain relay. The block processing method can be executed by the relay node. The block processing method may include the following steps S301-S304:

[0117] S301. Obtain the block data constructed by the block construction object, and obtain the block signature information of the block data and the resource transfer amount corresponding to the block data.

[0118] The block processing system can include multiple block building objects. Each block building object can construct block data with the goal of maximizing its own benefit and determine the resource transfer amount corresponding to the block data. Relay nodes can receive block data, block signature information, and corresponding resource transfer amounts sent by each block building object sequentially or simultaneously. Then, they determine whether each acquired block data meets the block selection criteria. Taking any acquired block data as an example, if the acquired block data meets the block selection criteria, step S302 is executed; if the acquired block data does not meet the block selection criteria, no operation is required on the acquired block data. For details on how to determine whether block data meets the block selection criteria, please refer to [link to documentation]. Figure 2 The relevant descriptions will not be repeated here.

[0119] S302. If the obtained block data meets the block selection conditions, then verify the block signature information of the obtained block data.

[0120] S303. If the signature information of the obtained block data is verified, the block record data is updated using the resource transfer amount and the obtained block data. The updated block record data is used to record the maximum resource transfer amount among the obtained resource transfer amounts and the block data corresponding to the maximum resource transfer amount.

[0121] If the acquired block data meets the block selection criteria (meaning the resource transfer amount corresponding to the acquired block data is the maximum resource transfer amount currently recorded in the block record data), then when the signature information of the acquired block data passes verification, the block record data can be updated using the resource transfer amount and the acquired block data. In one implementation, updating the block record data can be done by directly replacing the maximum resource transfer amount currently recorded in the block record data with the resource transfer amount corresponding to the acquired block data, and replacing the block data corresponding to the maximum resource transfer amount recorded in the block record data with the acquired block data. In this case, the maximum resource transfer amount recorded in the updated block record data is the same as the resource transfer amount corresponding to the acquired block data. For example, if the acquired block data is block data A, and the corresponding resource transfer amount is A, then directly replacing the maximum resource transfer amount currently recorded in the block record data with the resource transfer amount A corresponding to block data A, and replacing the block data corresponding to the maximum resource transfer amount currently recorded in the block record data with block data A. In this case, the maximum resource transfer amount in the updated block record data is resource transfer amount A. Optionally, the block record data may also include block signature information of the block data corresponding to the maximum resource transfer amount, etc.

[0122] In another implementation, updating the block record data can be done by directly adding the resource transfer amount and the acquired block data to the block record data, and using the maximum resource transfer amount previously recorded in the block record data as a candidate resource transfer amount. This candidate resource transfer amount and its corresponding block data are also retained in the block record data. In other words, the updated block record data not only retains the maximum resource transfer amount and its corresponding block data, but also retains candidate resource transfer amounts smaller than the maximum resource transfer amount. For example, if the maximum resource transfer amount recorded in the block record data is resource transfer amount B, and the resource transfer amount A corresponding to the acquired block data A is greater than resource transfer amount B, then block data A and resource transfer amount A can be recorded in the block record data, while resource transfer amount B and its corresponding block data are retained, resulting in the updated block record data. This facilitates subsequent relay nodes proposing block data corresponding to candidate resource transfer amounts when proposing block data corresponding to the maximum resource transfer amount fails, thus protecting the rights of the block proposal object.

[0123] S304. Process the block data corresponding to the maximum resource transfer amount recorded in the updated block record data to be added to the blockchain.

[0124] The process of uploading the block data corresponding to the maximum resource transfer amount recorded in the updated block record data to the blockchain includes: when a block proposal event is detected, determining the block data corresponding to the maximum resource transfer amount recorded in the updated block record data; the determined block data includes block header data; sending the block header data to the block proposal object so that the block proposal object can sign the block header data to obtain the block header signature information; receiving the block header signature information returned by the block proposal object, and based on the block header signature information, uploading the block data corresponding to the maximum resource transfer amount recorded in the updated block record data to the blockchain. Here, a block proposal event can refer to receiving a block query request sent by the block proposal object, or it can refer to the current system time reaching the block proposal time.

[0125] Based on the block header signature information, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is processed for on-chain processing, including: verifying the block header signature information, and adding the block header signature information to the block data corresponding to the maximum resource transfer amount recorded in the updated block record data after successful verification; verifying the block data with added block header signature information to obtain a verification result; if the verification result indicates that the block data with added block header signature information has been successfully verified, then broadcasting the block data with added block header signature information onto the chain or returning the block data with added block header signature information to the block proposal object, so that the block proposal object can broadcast the block data with added block header signature information onto the chain.

[0126] Optionally, as mentioned above, the updated block record data may also be used to record the candidate resource transfer amount and the block data corresponding to the candidate resource transfer amount, where the candidate resource transfer amount is less than the maximum resource transfer amount recorded in the updated block record data. In this case, if no block header signature information is received from the block proposal object, or if the verification result indicates that the verification of the block data with added block header signature information fails, the block data corresponding to the candidate resource transfer amount is retrieved from the updated block record data, and the block data corresponding to the candidate resource transfer amount is processed on the blockchain. This can protect the rights and interests of the block proposal object. If the verification of the block data corresponding to the candidate resource transfer amount fails, or if no corresponding block header signature information is received from the block proposal object, the next block data corresponding to the candidate resource transfer amount can be retrieved from the updated block record data, and the next block data corresponding to the candidate resource transfer amount can be processed on the blockchain until the corresponding block header signature information is received from the block proposal object, or the verification of the block data corresponding to the candidate resource transfer amount is successful, or the block proposal times out (i.e., the validity period of the proposal qualification has expired). If a block proposal times out and no block data is uploaded to the blockchain, it's possible that the block proposer doesn't want the block data from a certain block builder or the block proposer itself, and therefore doesn't respond with the block header signature data. In this case, the reason for the failure to upload block data to the blockchain can be generated as transaction data and uploaded to the blockchain to announce that the failure was due to the block proposer, preventing the block proposer from reneging.

[0127] Furthermore, this application embodiment introduces a challenge mechanism. The so-called challenge mechanism means that if the verification result indicates that the verification of block data with added block header signature information fails, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data (that is, the block data with added block header signature information) can be identified as the block data to be verified, and a block challenge request for the verification result of the block data to be verified can be sent to the block arbitration node to challenge the verification result of the block data to be verified. The relay node receives the challenge result returned by the block arbitration node after verifying the block data to be verified and the corresponding block signature information. The challenge result is used to indicate whether the verification result of the block data to be verified initiated by the relay node was successfully challenged. Specifically, the challenge result includes a prompt message indicating that the challenge was successful or a prompt message indicating that the challenge failed. If the challenge result indicates that the relay node's challenge to verify the block data to be verified is successful, it means that the block data to be verified is invalid or the block proposal object cannot obtain resource transfer amount from the block data to be verified. In other words, the block data to be verified has a problem, the relay node's verification result for the block data to be verified is correct, and the relay node's challenge is successful. If the challenge result indicates that the relay node's challenge to verify the block data to be verified fails, it means that the block data to be verified is valid or the block proposal object can obtain resource transfer amount from the block data to be verified. In other words, the block data to be verified does not have a problem, the relay node's verification result for the block data to be verified is incorrect, and the relay node's challenge is failed.

[0128] In the case of a successful challenge, the block arbitration node stores a preset number of proof resources corresponding to the block construction object of the block data to be verified. The block arbitration node can deduct a first number of proof resources from the preset number. The relay node can receive the first number of proof resources sent by the block arbitration node, as well as a success message. The preset number of proof resources includes the first number of proof resources. In the case of a failed challenge, the relay node will have its verification frequency limited to prevent resource consumption caused by the relay node continuously initiating verifications.

[0129] In this embodiment, block data constructed by a block construction object is obtained, along with the block signature information and resource transfer amount corresponding to the block data. If the obtained block data meets the block selection criteria, the block signature information of the obtained block data is verified. If the signature information of the obtained block data passes verification, the block record data is updated using the resource transfer amount and the obtained block data. The updated block record data is used to record the maximum resource transfer amount among the obtained resource transfer amounts, and the block data corresponding to the maximum resource transfer amount. The block data corresponding to the maximum resource transfer amount recorded in the updated block record data is then processed on-chain. Therefore, in this embodiment, block data constructed by a block construction object can be obtained, and the block signature information of the block data can be verified if the block data meets the block selection criteria. This eliminates the need to verify every piece of obtained block data, and only the block signature information is verified during verification, significantly reducing verification or computation costs. On the other hand, by updating the block record data using the resource transfer amount corresponding to the acquired block data and the acquired block data after the signature information of the acquired block data has been verified, the appropriate block data to be uploaded to the chain (i.e. the block data corresponding to the maximum resource transfer amount) can be recorded through the block record data. This reduces the verification cost in the process of uploading block data to the chain while determining the appropriate block data from multiple block data.

[0130] Please see Figure 4 This is a flowchart illustrating a block processing method provided in an embodiment of this application. The block processing method is applied to a block processing system, which includes a block proposal object, a relay node, a block construction object, and a block arbitration node. The method is applied to the block arbitration node within the block processing system. In some feasible implementations, the block arbitration node can be a separate computer device, or it can be directly deployed within a relay node or a block proposal object. An arbitration smart contract is deployed within the block arbitration node, and the block processing method provided in this embodiment is executed by calling the arbitration smart contract. The block processing method may include the following steps S401-S403:

[0131] S401. Receive a block challenge request sent by the relay node after the verification of the block data to be verified fails. The block challenge request includes the block data to be verified and the corresponding block signature information. The block data to be verified is the block data corresponding to the maximum resource transfer amount obtained by the relay node from the block record data stored by the relay node. The block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node.

[0132] S402. Verify the block signature information corresponding to the block data to be verified and the block data to be verified to obtain the challenge result of the block data to be verified.

[0133] Block arbitration nodes can verify the block signature information corresponding to the block data to be verified, to verify whether the block signature information is signed by the block construction object corresponding to the block data to be verified; and after the block signature information is verified, the block data to be verified is verified. If the verification of the block data to be verified fails, it means that there is a problem with the block data to be verified, that is, the block data to be verified is an illegal block and / or the block proposal object cannot obtain the corresponding resource transfer amount from the block data to be verified. At this time, it is determined that the verification result of the block data to be verified is correct, the relay node challenge is successful, and a challenge result initiated by the relay node against the verification result challenge of the block data to be verified is generated. If the verification of the block data to be verified is successful, it means that there is no problem with the block data to be verified, that is, the block data to be verified is a legal block and the block proposal object can obtain the corresponding resource transfer amount from the block data to be verified. At this time, it is determined that the verification result of the block data to be verified is incorrect, the relay node challenge is failed, and a challenge result initiated by the relay node against the verification result challenge of the block data to be verified is generated.

[0134] S403. Return the challenge result to the relay node. The challenge result is used to indicate whether the challenge initiated by the relay node for the verification result of the block data to be verified was successful or not.

[0135] In this embodiment, not only a challenge mechanism but also a reward and penalty mechanism is introduced. That is, based on the challenge result, relay nodes, block proposal objects, and block building objects can be rewarded or penalized. If the challenge result indicates that the relay node's challenge to verify the block data to be verified is successful, the reward and penalty mechanism may include at least one of the following:

[0136] ① The block construction object corresponding to the block data to be verified (i.e., the block construction object that constructs the block data to be verified) has pre-stored a preset number of proof resources with the block arbitration node. The block arbitration node can associate the preset number of proof resources with the block construction object. If the verification result challenge initiated by the relay node against the block data to be verified is successful, it means that the block construction object corresponding to the block data to be verified has engaged in malicious behavior. In this case, the block arbitration node can deduct a first number of proof resources and a second number of proof resources from the preset number of proof resources stored in the block construction object corresponding to the block data to be verified, transfer the first number of proof resources to the relay node, and transfer the second number of proof resources to the block proposal object of the block data to be verified. The embodiments of this application can automatically and flexibly deduct the preset number of proof resources stored in the block construction object and transfer the deducted proof resources to the block proposal object and the relay node. This can achieve the punishment of malicious block construction objects while protecting the rights and interests of the block proposal object and the relay node.

[0137] Optionally, in this embodiment of the application, the challenge result, the deduction of proof resources for the block building object, and the transfer record are used to generate transaction data, and the generated transaction data is processed on the blockchain. By uploading the challenge result and the proof resource deduction record of the block building object to the blockchain, it can be ensured that the verification process, the challenge result, and the proof resource deduction record of the block building object are traceable, making it easy to clearly see the reason for the deduction of proof resources for the block building object.

[0138] ② Remove the block building object corresponding to the block data to be verified from the blockchain network or block processing system. This prevents the block building object from continuing to act maliciously, ensuring the security of the blockchain network and block processing system. When the block building object wants to reconnect to the blockchain network to build block data, it can provide more proof resources or other proof information to ensure that the block building object has no possibility of malicious behavior.

[0139] ③ Reduce the confidence score of the block building object corresponding to the block data to be verified. For example, directly reduce the confidence score of the block building object corresponding to the block data to be verified by 10%, 15%, etc.

[0140] ④ Within a preset time period (such as 1 day, 1 week, etc.), the block building object corresponding to the block data to be verified is prohibited from building block data. This can reduce the problem of the block building object frequently building block data, and the relay node needs to continuously provide computing costs to verify the block data built by the block building object. In addition, it can also enable the block data built by other block building objects to be proposed by the block proposal object.

[0141] ⑤ Increase the number of proof resources provided by the block construction object corresponding to the block data to be verified.

[0142] If the challenge result indicates that the verification challenge initiated by the relay node against the block data to be verified has failed, the reward and penalty mechanism may include at least one of the following:

[0143] ① Count the number of times the relay node fails to challenge, and determine whether the number of times the relay node fails to challenge exceeds the threshold. If the number of times the relay node fails to challenge exceeds the threshold, limit the challenge frequency of the relay node. This can prevent the relay node from frequently initiating block challenge requests.

[0144] ② Increase the confidence score of the block building object corresponding to the block data to be verified. For example, directly increase the confidence score of the block building object corresponding to the block data to be verified by 10%, 15%, etc.

[0145] In summary, by introducing challenge and penalty mechanisms, the embodiments of this application can maximize the protection of the rights and interests of relay nodes, block proposal objects, etc., and can prevent malicious behavior of block building objects to a certain extent, thus ensuring the security of the block on-chain process and the stability of the blockchain network.

[0146] In this embodiment, the block building object can pre-store a preset number of proof resources, and the block arbitration node allows the relay node to send a block challenge request after the verification of the block data to be verified fails. After receiving the block challenge request, the block arbitration node can verify the block data to be verified and the corresponding block signature information to determine whether the verification result of the block data to be verified is correct, thereby determining whether the relay node has successfully challenged. Based on whether the relay node's challenge is successful or not, a corresponding reward and punishment mechanism is triggered, which can prevent malicious behavior of the block building object, ensure the rights and interests of the block proposal object, and maintain the stability of the entire block processing system.

[0147] Please see Figure 5 This is a flowchart illustrating a block processing method provided in an embodiment of this application. The block processing method is applied to a block processing system, which includes a block proposal object, relay nodes, block building objects, and block arbitration nodes. The method is executed by the block building object in the block processing system. The block processing method may include the following steps S501-S504:

[0148] S501. Obtain multiple transaction data. The block building object can obtain multiple transaction data from the memory pool, such as randomly obtaining multiple transaction data from the memory pool or obtaining multiple transaction data from the memory pool to maximize its own interests.

[0149] S502. Sort multiple transaction data and package the sorted transaction data to generate block data.

[0150] S503. Based on multiple transaction data, determine the resource transfer amount corresponding to the block data. The resource transfer amount corresponding to this block data refers to the amount of resources that the block construction object needs to transfer to the block proposal object after the block data is proposed and added to the blockchain.

[0151] S504. Sign the block data to obtain the block signature information. The block building object can use its private key to sign the block data to obtain the block signature information. Optionally, it can use its private key to sign the block data and the resource transfer amount to obtain the block signature information.

[0152] After generating the block signature information, the block building object can send the block data, block signature information, and the resource transfer amount corresponding to the block data to the relay node to participate in the bidding, thereby realizing the block proposal on the chain.

[0153] In this embodiment, multiple transaction data are acquired, sorted, and packaged to generate block data. Based on the multiple transaction data, the resource transfer amount corresponding to the block data is determined. The block data is then signed to obtain its block signature information. By separating block construction from block proposal, the block construction object can construct block data with the goal of maximizing its own utilization and provide the corresponding resource transfer amount. This allows the block construction object to share the block construction task with the block proposal object, not only improving the block data construction process but also reducing the computational resource requirements of the block proposal object during the block on-chain process.

[0154] Please see Figure 6 This is a flowchart illustrating a block processing method provided in an embodiment of this application. The block processing method is applied to a block processing system, which includes a block proposal object, relay nodes, block construction objects, and block arbitration nodes. The method is executed by the block proposal object in the block processing system. The block processing method may include the following steps S601-S603:

[0155] S601, Receive block header data sent by relay node; The block data corresponding to the maximum resource transfer amount recorded in the updated block record data includes block header data; The updated block record data is obtained by the relay node updating the block record data using the resource transfer amount corresponding to the acquired block data and the acquired block data after the acquired block data meets the block selection conditions and the block signature information of the acquired block data is verified.

[0156] Specifically, when a block proposal object enters the block proposal phase, it can send a block query request to the relay node. This block query request is used to query the current maximum resource transfer amount and the block header data in the block data corresponding to the maximum resource transfer amount; and receive the block header data sent by the relay node based on the block query request.

[0157] S602. Sign the block header data to obtain the block header signature information.

[0158] The block proposer can use their private key to sign the block header data and obtain the block header signature information.

[0159] S603. Return the block header signature information to the relay node so that the relay node can perform on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data based on the block header signature information.

[0160] Specifically, the block proposal object can return the block header signature information to the relay node to obtain the block data corresponding to the block header data. After the block proposal object has verified the block header signature information and the block data corresponding to the block header data, it can return the block data with the added block header data to the block proposal object through broadcast, or directly return the block data with the added block header data to the block proposal object.

[0161] In this embodiment, the relay node receives block header data; the updated block record data includes the block header data corresponding to the maximum resource transfer amount recorded in the block record data; the updated block record data is obtained by the relay node updating the block record data using the resource transfer amount corresponding to the acquired block data and the acquired block data after the acquired block data meets the block selection conditions and the block signature information of the acquired block data is verified; the block header data is signed to obtain the block header signature information of the block header data; the block header signature information is returned to the relay node so that the relay node can perform on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data based on the block header signature information. As can be seen, the block proposal object completes the block proposal in this round based on the constructed block. For the block proposal object, there is no need to consume resources to complete the block construction, which reduces the computing performance of the block proposal object. In addition, the block proposal object can obtain some of the resource benefits generated by the transaction fees generated by the block data being put on the chain to a certain extent by proposing the block data corresponding to the maximum resource transfer amount, thus meeting the needs of automated and intelligent resource allocation.

[0162] The block processing apparatus provided in the embodiments of this application will now be described.

[0163] In a first embodiment of the block data processing apparatus, the block processing apparatus is disposed in a computer device. The block processing apparatus may be a computer program (including program code) within the computer device; for example, the block processing apparatus may be application software within the computer device. The computer device may be the relay node mentioned above. The block processing apparatus can be used to execute... Figure 2 as well as Figure 3 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 7 , Figure 7 This is a schematic diagram of the structure of a block processing device provided in an embodiment of this application. Please refer to [link / reference]. Figure 7 The block processing device includes the following units:

[0164] The acquisition unit 701 is used to acquire the block data constructed by the block construction object, and to acquire the block signature information of the block data and the resource transfer amount corresponding to the block data;

[0165] The processing unit 702 is used to verify the block signature information of the acquired block data if the acquired block data meets the block selection conditions.

[0166] The processing unit 702 is also used to update the block record data using the resource transfer amount and the acquired block data if the signature information of the acquired block data is verified. The updated block record data is used to record the maximum resource transfer amount among the acquired resource transfer amounts and the block data corresponding to the maximum resource transfer amount.

[0167] The processing unit 702 is also used to perform on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data.

[0168] The processing unit 702 is further configured to:

[0169] If the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, then the obtained block data is determined to meet the block selection criteria; or,

[0170] Obtain the confidence score recorded for the block building object. The confidence score is determined based on the on-chain status of the block built by the block building object. If the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, and the confidence score of the block building object is greater than the preset confidence score, then it is determined that the obtained block data meets the block selection conditions.

[0171] The processing unit 702 is further configured to:

[0172] Send a resource query request to the block arbitration node. The resource query request is used to query whether the block building object corresponding to the obtained block data has a preset number of proof resources.

[0173] Receive the query results returned by the block arbitration node based on the resource query request;

[0174] If the query results indicate that the block construction object corresponding to the obtained block data has stored a preset number of proof resources, and the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, then it is determined that the obtained block data meets the block selection conditions.

[0175] When processing unit 702 performs on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data, it can be specifically used for:

[0176] When a block proposal event is detected, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is determined; the determined block data includes the block header data.

[0177] Send block header data to the block proposal object so that the block proposal object can sign the block header data to obtain the block header signature information;

[0178] Receive the block header signature information returned by the block proposal object;

[0179] Based on the block header signature information, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is processed on the blockchain.

[0180] The block proposal event refers to receiving a block query request sent by the block proposal object.

[0181] Specifically, when processing unit 702 performs on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data based on the block header signature information, it can be used for:

[0182] The block header signature information is verified, and after successful verification, the block header signature information is added to the block data corresponding to the maximum resource transfer amount recorded in the updated block record data.

[0183] The block data with added block header signature information is verified to obtain the verification result;

[0184] If the verification result indicates that the block data with added block header signature information has been successfully verified, the block data with added block header signature information will be broadcast onto the chain or returned to the block proposal object so that the block proposal object can broadcast the block data with added block header signature information onto the chain.

[0185] The updated block record data is also used to record the candidate resource transfer amount and the block data corresponding to the candidate resource transfer amount, wherein the candidate resource transfer amount is less than the maximum resource transfer amount recorded in the updated block record data; the processing unit 702 is also used for:

[0186] If no block header signature information is received from the block proposal object, or if the verification result indicates that the verification of the determined block data has failed, the block data corresponding to the candidate resource transfer amount is obtained from the updated block record data, and the block data corresponding to the candidate resource transfer amount is processed on the blockchain.

[0187] Among them, the block data corresponding to the maximum resource transfer amount in the updated block record data includes multiple transaction data;

[0188] When processing unit 702 verifies block data with added block header signature information and obtains the verification result, it can be specifically used for:

[0189] Perform legality verification on block data with added block header signature information;

[0190] If the validity verification of the block data with added block header signature information passes, then obtain the account change information of the block proposal object after the execution of multiple transaction data in the block data with added block header signature information;

[0191] If the account change information indicates that the block proposal object has received the maximum resource transfer amount, then a verification result is obtained indicating that the block data with added block header signature information has been successfully verified.

[0192] The processing unit 702 is further configured to: if the verification result indicates that the verification of the block data with added block header signature information fails, determine the block data corresponding to the maximum resource transfer amount recorded in the updated block record data as the block data to be verified; send a block challenge request to the block arbitration node, the block challenge request including the block data to be verified and the block signature information corresponding to the block data to be verified, the block challenge request being used to challenge the verification result of the block data to be verified to the block arbitration node;

[0193] The acquisition unit 701 is also used to receive the challenge result returned by the block arbitration node after verifying the block data to be verified and the corresponding block signature information. The challenge result is used to indicate whether the challenge initiated by the relay node against the block data to be verified was successful or failed.

[0194] The block arbitration node stores a preset number of proof resources corresponding to the block construction object to be verified; the processing unit 702 is also used for:

[0195] If the challenge result indicates that the relay node's challenge to verify the block data to be verified is successful, then the relay node receives the first number of proof resources and the challenge success message sent by the block arbitration node. The preset number of proof resources includes the first number of proof resources.

[0196] In a second embodiment of the block processing apparatus, the block processing apparatus may be housed in a computer device corresponding to the aforementioned block arbitration node, and the block processing apparatus may be used to perform... Figure 2 as well as Figure 4 The steps shown in the method embodiments are partially or completely illustrated in the specific schematic diagram of the block processing device in this application embodiment. Figure 7 As shown, it includes an acquisition unit 701 and a processing unit 702;

[0197] The acquisition unit 701 is used to receive a block challenge request sent by the relay node after the verification of the block data to be verified fails. The block challenge request includes the block data to be verified and the block signature information corresponding to the block data to be verified. The block data to be verified is the block data corresponding to the maximum resource transfer amount obtained by the relay node from the block record data stored by the relay node. The block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node.

[0198] The processing unit 702 is used to verify the block signature information corresponding to the block data to be verified and the block data to be verified, and to obtain the challenge result of the block data to be verified.

[0199] The processing unit 702 is also used to return a challenge result to the relay node. The challenge result is used to indicate whether the challenge initiated by the relay node for the verification result of the block data to be verified was successful or not.

[0200] If the challenge result indicates that the relay node's challenge to verify the block data to be verified was successful, the processing unit 702 can be specifically used for:

[0201] The first number of proof resources and the second number of proof resources are deducted from the preset number of proof resources stored in the block construction object corresponding to the block data to be verified. The first number of proof resources are transferred to the relay node, and the second number of proof resources are transferred to the block proposal object of the block data to be verified.

[0202] Remove the block construction object corresponding to the block data to be verified from the blockchain network;

[0203] Reduce the confidence score of the block construction object corresponding to the block data to be verified;

[0204] Within a preset time period, the block construction object corresponding to the block data to be verified is prohibited from constructing block data;

[0205] Increase the number of proof resources provided by the block construction object corresponding to the block data to be verified.

[0206] The processing unit 702 can also be used for:

[0207] The challenge results and proof resources of the block building object are deducted to generate transaction data, and the generated transaction data is then processed on the blockchain.

[0208] The processing unit 702 can also be used for:

[0209] If the challenge result indicates that the relay node's challenge to verify the block data to be verified has failed, then the number of times the relay node's challenge has failed is counted.

[0210] If the number of failed challenges by a relay node exceeds a threshold, the challenge frequency of the relay node will be limited; and,

[0211] Increase the confidence score of the block construction object corresponding to the block data to be verified.

[0212] The processing unit 702 can also be used for:

[0213] Receive resource query requests for block building objects sent by relay nodes;

[0214] In response to a resource query request, the system queries the preset number of proof resources stored in the block construction object and obtains the query results.

[0215] The query results are returned to the relay nodes so that the relay nodes can determine whether the block data constructed by the block construction object meets the block selection criteria based on the query results.

[0216] In a third embodiment of the block processing apparatus, the block processing apparatus may be housed in a computer device corresponding to the aforementioned block building object, and the block processing apparatus may be used to execute... Figure 2 as well as Figure 5 The steps shown in the method embodiments are partially or completely illustrated in the specific schematic diagram of the block processing device in this application embodiment. Figure 7 As shown, it includes an acquisition unit 701 and a processing unit 702;

[0217] Acquisition unit 701 is used to acquire multiple transaction data.

[0218] Processing unit 702 is used to sort multiple transaction data and package the sorted transaction data to generate block data;

[0219] The processing unit 702 is also used to determine the amount of resources transferred corresponding to the block data based on multiple transaction data.

[0220] The processing unit 702 is also used to perform signature processing on the block data to obtain the block signature information of the block data.

[0221] In a fourth embodiment of the block processing apparatus, the block processing apparatus may be housed in a computer device corresponding to the aforementioned block proposal object, and the block processing apparatus may be used to execute... Figure 2 as well as Figure 6 The steps shown in the method embodiments are partially or completely illustrated in the specific schematic diagram of the block processing device in this application embodiment. Figure 7 As shown, it includes an acquisition unit 701 and a processing unit 702;

[0222] The acquisition unit 701 is used to receive block header data sent by the relay node; the block data corresponding to the maximum resource transfer amount recorded in the updated block record data includes the block header data; the updated block record data is obtained by the relay node updating the block record data using the resource transfer amount corresponding to the acquired block data and the acquired block data after the acquired block data meets the block selection conditions and the block signature information of the acquired block data is verified.

[0223] Processing unit 702 is used to sign the block header data to obtain the block header signature information of the block header data;

[0224] The processing unit 702 is also used to return block header signature information to the relay node so that the relay node can perform on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data based on the block header signature information.

[0225] The computer device provided in the embodiments of this application will be described in detail below.

[0226] Furthermore, this application also provides a schematic diagram of the structure of a computer device, which can be found in [reference needed]. Figure 8 The computer device may include a processor 801, an input device 802, an output device 803, and a memory 804. The processor 801, input device 802, output device 803, and memory 804 are connected via a bus. The memory 804 stores computer programs, which include program instructions, and the processor 801 executes the program instructions stored in the memory 804.

[0227] In one embodiment, processor 801 performs the following operations by running program instructions stored in memory 804:

[0228] Obtain the block data constructed by the block construction object, and obtain the block signature information of the block data and the resource transfer amount corresponding to the block data;

[0229] If the obtained block data meets the block selection criteria, then verify the block signature information of the obtained block data.

[0230] If the signature information of the acquired block data is verified, the block record data is updated using the resource transfer amount and the acquired block data. The updated block record data is used to record the maximum resource transfer amount among the acquired resource transfer amounts, and the block data corresponding to the maximum resource transfer amount.

[0231] The block data corresponding to the maximum resource transfer amount recorded in the updated block record data is processed on the blockchain.

[0232] The processor 801 is also used for:

[0233] If the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, then the obtained block data is determined to meet the block selection criteria; or,

[0234] Obtain the confidence score recorded for the block building object. The confidence score is determined based on the on-chain status of the block built by the block building object. If the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, and the confidence score of the block building object is greater than the preset confidence score, then it is determined that the obtained block data meets the block selection conditions.

[0235] The processor 801 is also used for:

[0236] Send a resource query request to the block arbitration node. The resource query request is used to query whether the block building object corresponding to the obtained block data has a preset number of proof resources.

[0237] Receive the query results returned by the block arbitration node based on the resource query request;

[0238] If the query results indicate that the block construction object corresponding to the obtained block data has stored a preset number of proof resources, and the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, then it is determined that the obtained block data meets the block selection conditions.

[0239] When processor 801 processes the block data corresponding to the maximum resource transfer amount recorded in the updated block record data for on-chain processing, it can specifically perform the following operations:

[0240] When a block proposal event is detected, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is determined; the determined block data includes the block header data.

[0241] Send block header data to the block proposal object so that the block proposal object can sign the block header data to obtain the block header signature information;

[0242] Receive the block header signature information returned by the block proposal object;

[0243] Based on the block header signature information, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is processed on the blockchain.

[0244] Among them, the block proposal event refers to receiving a block query request sent by the block proposal object.

[0245] Specifically, when processor 801 performs on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data based on the block header signature information, it can perform the following operations:

[0246] The block header signature information is verified, and after successful verification, the block header signature information is added to the block data corresponding to the maximum resource transfer amount recorded in the updated block record data.

[0247] The block data with added block header signature information is verified to obtain the verification result;

[0248] If the verification result indicates that the block data with added block header signature information has been successfully verified, the block data with added block header signature information will be broadcast onto the chain or returned to the block proposal object so that the block proposal object can broadcast the block data with added block header signature information onto the chain.

[0249] The updated block record data is also used to record the candidate resource transfer amount and the block data corresponding to the candidate resource transfer amount, wherein the candidate resource transfer amount is less than the maximum resource transfer amount recorded in the updated block record data; the processor 801 is also used for:

[0250] If no block header signature information is received from the block proposal object, or if the verification result indicates that the verification of the determined block data has failed, the block data corresponding to the candidate resource transfer amount is obtained from the updated block record data, and the block data corresponding to the candidate resource transfer amount is processed on the blockchain.

[0251] Among them, the block data corresponding to the maximum resource transfer amount in the updated block record data includes multiple transaction data;

[0252] When processor 801 verifies block data with added block header signature information and obtains the verification result, it can perform the following operations:

[0253] Perform legality verification on block data with added block header signature information;

[0254] If the validity verification of the block data with added block header signature information passes, then obtain the account change information of the block proposal object after the execution of multiple transaction data in the block data with added block header signature information;

[0255] If the account change information indicates that the block proposal object has received the maximum resource transfer amount, then a verification result is obtained indicating that the block data with added block header signature information has been successfully verified.

[0256] The processor 801 is also used for:

[0257] If the verification result indicates that the verification of the block data with added block header signature information fails, then the block data corresponding to the maximum resource transfer amount recorded in the updated block record data will be determined as the block data to be verified.

[0258] Send a block challenge request to the block arbitration node. The block challenge request includes the block data to be verified and the block signature information corresponding to the block data to be verified. The block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node.

[0259] The relay node receives the challenge result returned by the block arbitration node after verifying the block data to be verified and the corresponding block signature information. The challenge result is used to indicate whether the challenge initiated by the relay node against the block data to be verified was successful or failed.

[0260] The block arbitration node stores a preset number of proof resources corresponding to the block construction object to be verified; the processor 801 is also used for:

[0261] If the challenge result indicates that the relay node's challenge to verify the block data to be verified is successful, then the relay node receives the first number of proof resources and the challenge success message sent by the block arbitration node. The preset number of proof resources includes the first number of proof resources.

[0262] In another embodiment, processor 801 performs the following operations by running program instructions stored in memory 804:

[0263] The system receives a block challenge request sent by a relay node after the verification of the block data to be verified fails. The block challenge request includes the block data to be verified and the corresponding block signature information. The block data to be verified is the block data corresponding to the maximum resource transfer amount obtained by the relay node from the block record data stored by the relay node. The block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node.

[0264] The block signature information corresponding to the block data to be verified and the block data to be verified are verified to obtain the challenge result of the block data to be verified.

[0265] Return the challenge result to the relay node. The challenge result indicates whether the challenge initiated by the relay node for the verification result of the block data to be verified was successful or not.

[0266] If the challenge result indicates that the relay node's challenge to verify the block data to be verified was successful, processor 801 can also perform the following operations:

[0267] The first number of proof resources and the second number of proof resources are deducted from the preset number of proof resources stored in the block construction object corresponding to the block data to be verified. The first number of proof resources are transferred to the relay node, and the second number of proof resources are transferred to the block proposal object of the block data to be verified.

[0268] Remove the block construction object corresponding to the block data to be verified from the blockchain network;

[0269] Reduce the confidence score of the block construction object corresponding to the block data to be verified;

[0270] Within a preset time period, the block construction object corresponding to the block data to be verified is prohibited from constructing block data;

[0271] Increase the number of proof resources provided by the block construction object corresponding to the block data to be verified.

[0272] The processor 801 can also perform the following operations:

[0273] The challenge results and proof resources of the block building object are deducted to generate transaction data, and the generated transaction data is then processed on the blockchain.

[0274] The processor 801 can also perform the following operations:

[0275] If the challenge result indicates that the relay node's challenge to verify the block data to be verified has failed, then the number of times the relay node's challenge has failed is counted.

[0276] If the number of failed challenges by a relay node exceeds a threshold, the challenge frequency of the relay node will be limited; and,

[0277] Increase the confidence score of the block construction object corresponding to the block data to be verified.

[0278] The processor 801 can also perform the following operations:

[0279] Receive resource query requests for block building objects sent by relay nodes;

[0280] In response to a resource query request, the system queries the preset number of proof resources stored in the block construction object and obtains the query results.

[0281] The query results are returned to the relay nodes so that the relay nodes can determine whether the block data constructed by the block construction object meets the block selection criteria based on the query results.

[0282] In another embodiment, processor 801 performs the following operations by executing program instructions stored in execution memory 804:

[0283] Obtain multiple transaction data.

[0284] Sort multiple transaction data and package the sorted transaction data to generate block data;

[0285] Based on multiple transaction data, determine the amount of resources transferred corresponding to the block data;

[0286] The block data is signed to obtain the block signature information.

[0287] In another embodiment, processor 801 performs the following operations by executing program instructions stored in execution memory 804:

[0288] Receive block header data sent by relay nodes; the block data corresponding to the maximum resource transfer amount recorded in the updated block record data includes the block header data; the updated block record data is obtained by the relay node after the acquired block data meets the block selection conditions and the block signature information of the acquired block data is verified, by updating the block record data with the resource transfer amount corresponding to the acquired block data and the acquired block data.

[0289] Sign the block header data to obtain the block header signature information;

[0290] The block header signature information is returned to the relay node so that the relay node can process the block data corresponding to the maximum resource transfer amount recorded in the updated block record data on the blockchain based on the block header signature information.

[0291] Based on the same inventive concept, the principle and beneficial effects of the computer device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the method embodiments of this application in solving the problem. Please refer to the principle and beneficial effects of the method embodiments. For the sake of brevity, they will not be repeated here.

[0292] In this application, the term "unit" refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more units. Furthermore, each unit can be part of an overall unit that includes the functionality of that unit.

[0293] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program, which includes program instructions. When a processor executes these program instructions, it can execute the aforementioned... Figures 2-6 The methods described in the corresponding embodiments are therefore not repeated here. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application. As an example, program instructions may be deployed on a computer device, executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network.

[0294] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, enabling the computer device to perform the aforementioned... Figures 2-6 The methods described in the corresponding embodiments are therefore not repeated here.

[0295] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0296] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A block processing method, characterized in that, The method is applied to a relay node, and the method includes: Obtain the block data constructed by the block construction object, and obtain the block signature information of the block data and the resource transfer amount corresponding to the block data; If the obtained block data meets the block selection conditions, then verify the block signature information of the obtained block data; If the signature information of the acquired block data is verified, the block record data is updated using the resource transfer amount and the acquired block data. The updated block record data is used to record the maximum resource transfer amount among the acquired resource transfer amounts and the block data corresponding to the maximum resource transfer amount. The block data corresponding to the maximum resource transfer amount recorded in the updated block record data is processed on the blockchain.

2. The method as described in claim 1, characterized in that, The method further includes: If the resource transfer amount corresponding to the acquired block data is greater than the maximum resource transfer amount currently recorded in the block record data, then the acquired block data is determined to meet the block selection criteria; or, Obtain the confidence score recorded for the block construction object. The confidence score is determined based on the on-chain status of the block constructed by the block construction object. If the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, and the confidence score of the block construction object is greater than the preset confidence score, then it is determined that the obtained block data meets the block selection conditions.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: Send a resource query request to the block arbitration node. The resource query request is used to query whether the block construction object corresponding to the obtained block data has a preset number of proof resources. Receive the query results returned by the block arbitration node based on the resource query request; If the query result indicates that the block construction object corresponding to the obtained block data has stored a preset number of proof resources, and the resource transfer amount corresponding to the obtained block data is greater than the maximum resource transfer amount currently recorded in the block record data, then it is determined that the obtained block data meets the block selection conditions.

4. The method as described in claim 1, characterized in that, The process of uploading the block data corresponding to the maximum resource transfer amount recorded in the updated block record data to the blockchain includes: When a block proposal event is detected, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is determined; the determined block data includes the block header data. The block header data is sent to the block proposal object so that the block proposal object can sign the block header data to obtain the block header signature information of the block header data; Receive the block header signature information returned by the block proposal object; Based on the block header signature information, the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is processed on the blockchain. The block proposal event refers to receiving a block query request sent by the block proposal object.

5. The method as described in claim 4, characterized in that, The step of uploading the block data corresponding to the maximum resource transfer amount recorded in the updated block record data to the blockchain based on the block header signature information includes: The block header signature information is verified, and after successful verification, the block header signature information is added to the block data corresponding to the maximum resource transfer amount recorded in the updated block record data; The block data with the added block header signature information is verified to obtain the verification result. If the verification result indicates that the block data with the added block header signature information has been successfully verified, then the block data with the added block header signature information is broadcast onto the blockchain, or the block data with the added block header signature information is returned to the block proposal object so that the block proposal object can broadcast the block data with the added block header signature information onto the blockchain.

6. The method as described in claim 5, characterized in that, The updated block record data is also used to record the candidate resource transfer amount and the block data corresponding to the candidate resource transfer amount, wherein the candidate resource transfer amount is less than the maximum resource transfer amount recorded in the updated block record data. The method further includes: If the block header signature information is not received from the block proposal object, or if the verification result indicates that the verification of the determined block data has failed, then the block data corresponding to the candidate resource transfer amount is obtained from the updated block record data, and the block data corresponding to the candidate resource transfer amount is processed on the blockchain.

7. The method as described in claim 5 or 6, characterized in that, The block data corresponding to the maximum resource transfer amount in the updated block record data includes multiple transaction data; The verification of the block data with the added block header signature information to obtain the verification result includes: The legality of the block data with the added block header signature information is verified. If the validity verification of the block data with the added block header signature information passes, then the account change information of the block proposal object is obtained after the execution of multiple transaction data in the block data with the added block header signature information. If the account change information indicates that the block proposal object has received the maximum resource transfer amount, then a verification result is obtained that the block data with the added block header signature information has been successfully verified.

8. The method as described in claim 5, characterized in that, The method further includes: If the verification result indicates that the verification of the block data with the added block header signature information fails, then the block data corresponding to the maximum resource transfer amount recorded in the updated block record data is determined as the block data to be verified. A block challenge request is sent to the block arbitration node. The block challenge request includes the block data to be verified and the block signature information corresponding to the block data to be verified. The block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node. The relay node receives the challenge result returned by the block arbitration node after verifying the block data to be verified and the corresponding block signature information. The challenge result is used to indicate whether the challenge initiated by the relay node against the block data to be verified was successful or failed.

9. The method as described in claim 8, characterized in that, The block arbitration node stores a preset number of proof resources stored in the block construction object corresponding to the block data to be verified; The method further includes: If the challenge result indicates that the relay node's challenge to verify the block data to be verified is successful, then the relay node receives a first number of proof resources and a challenge success notification message sent by the block arbitration node. The preset number of proof resources includes the first number of proof resources.

10. A block processing method, characterized in that, The method is applied to a block arbitration node, and the method includes: The system receives a block challenge request sent by a relay node after the verification of the block data to be verified fails. The block challenge request includes the block data to be verified and the block signature information corresponding to the block data to be verified. The block data to be verified is the block data corresponding to the maximum resource transfer amount obtained by the relay node from the block record data stored by the relay node. The block challenge request is used to challenge the verification result of the block data to be verified to the block arbitration node. The block signature information corresponding to the block data to be verified and the block data to be verified are verified to obtain the challenge result of the block data to be verified. The relay node returns the challenge result, which indicates whether the challenge initiated by the relay node for verifying the block data to be verified was successful or not.

11. The method as described in claim 10, characterized in that, If the challenge result indicates that the verification result challenge initiated by the relay node against the block data to be verified is successful, the method further includes at least one of the following steps: The first number of proof resources and the second number of proof resources are deducted from the preset number of proof resources stored in the block construction object corresponding to the block data to be verified. The first number of proof resources are transferred to the relay node, and the second number of proof resources are transferred to the block proposal object of the block data to be verified. Remove the block construction object corresponding to the block data to be verified from the blockchain network; Reduce the confidence score of the block construction object corresponding to the block data to be verified; Within a preset time period, the block construction object corresponding to the block data to be verified is prohibited from constructing block data; Increase the number of proof resources provided by the block construction object corresponding to the block data to be verified.

12. The method as described in claim 11, characterized in that, The method further includes: The challenge results and the proof resource deduction records of the block construction object are used to generate transaction data, which is then processed on the blockchain.

13. The method as described in claim 10, characterized in that, The method further includes: If the challenge result indicates that the relay node's challenge to verify the block data to be verified has failed, then the number of times the relay node's challenge has failed is counted. If the number of failed challenges by the relay node exceeds a threshold, then the challenge frequency of the relay node is limited; and, Increase the confidence score of the block construction object corresponding to the block data to be verified.

14. The method as described in claim 10, characterized in that, The method further includes: Receive resource query requests for block building objects sent by relay nodes; In response to the resource query request, a preset number of proof resources stored in the block construction object are queried to obtain the query results; The query results are returned to the relay node so that the relay node can determine whether the block data constructed by the block construction object meets the block selection criteria based on the query results.

15. A block processing method, characterized in that, The method includes: Obtain multiple transaction data. The multiple transaction data are sorted, and the sorted transaction data is packaged to generate block data. Based on the multiple transaction data, determine the resource transfer amount corresponding to the block data; The block data is signed to obtain the block signature information of the block data.

16. A block processing method, characterized in that, The method includes: The relay node receives block header data sent by the relay node; the block data corresponding to the maximum resource transfer amount recorded in the updated block record data includes the block header data; the updated block record data is obtained by the relay node updating the block record data using the resource transfer amount corresponding to the acquired block data and the acquired block data after the acquired block data meets the block selection conditions and the block signature information of the acquired block data is verified. The block header data is signed to obtain the block header signature information of the block header data; The relay node returns the block header signature information so that the relay node can perform on-chain processing on the block data corresponding to the maximum resource transfer amount recorded in the updated block record data based on the block header signature information.

17. A block processing device, characterized in that, The apparatus includes one or more units for performing the method as described in any one of claims 1-9, or the apparatus includes one or more units for performing the method as described in any one of claims 10-14, or the apparatus includes one or more units for performing the method as described in claim 15, or the apparatus includes one or more units for performing the method as described in claim 16.

18. A computer device, characterized in that, The computer device includes a storage device and a processor; the storage device stores a computer program; the processor executes the computer program in the storage device to implement the steps of the method as described in any one of claims 1-16.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1-16.

20. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is processed and executed, it implements the steps of the method as described in any one of claims 1-16.

Images