Data processing methods, devices, equipment, media, and products based on blockchain.

Abstract

This application provides a blockchain-based data processing method, apparatus, device, medium, and product. The method includes: receiving block proposal information sent by a block-producing node, comprising a target block and a target digital signature, wherein the target digital signature is obtained by digitally signing the block header information included in the target block, and the block header information includes a standard Merkle root determined based on transaction data in the block body information; calculating a digest of the block header information to obtain a first digest, and designing the target digital signature to obtain a second digest; if the first digest information matches the second digest information, determining the target Merkle root based on the transaction data obtained from the block proposal information; and performing an operation on the target block based on the comparison result of the standard Merkle root and the target Merkle root. This application can realize data verification of block proposal information, ensuring the accuracy of the processing results after processing based on the block proposal information.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to blockchain-based data processing methods, blockchain-based data processing devices, data processing equipment, computer-readable storage media, and computer program products. Background Technology

[0002] With the continuous development and application of computer technology, blockchain technology has also developed rapidly. Because information stored on the blockchain cannot be forged or tampered with, using blockchain technology for business data processing has become a current trend. During block synchronization, block-producing nodes create blocks and generate block proposal information based on these blocks, which is then broadcast to consensus nodes. Consensus nodes can then perform processing such as block consensus based on the received block proposal information. However, block proposal information may experience data loss or other anomalies during transmission. Since consensus nodes cannot verify the block proposal information, the received block proposal information may be incorrect. If the consensus nodes then process the information based on this incorrect information, the processing results will be abnormal. Therefore, how to implement data verification of block proposal information to ensure the accuracy of processing results based on this information is a pressing problem that needs to be solved. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, medium, and product based on blockchain, which can realize data verification of block proposal information and ensure the accuracy of the processing results after processing based on block proposal information.

[0004] This application provides a blockchain-based data processing method, which includes:

[0005] Receive block proposal information sent by the block-producing node; wherein, the block proposal information includes a target block and a target digital signature, the target block includes block header information and block body information, the target digital signature is obtained by digitally signing the block header information, and the block header information includes a standard Merkle root determined based on the transaction data in the block body information.

[0006] The block header information and the target digital signature are obtained from the block proposal information. The block header information is digested to obtain the first digest information of the block header information. The target digital signature is designed to obtain the second digest information of the block header information.

[0007] If the first summary information matches the second summary information, then the standard Merkel root and the transaction data are obtained from the block proposal information, and the target Merkel root is determined based on the transaction data.

[0008] Based on the comparison results between the standard Merkel root and the target Merkel root, the operation is performed on the target block.

[0009] This application provides another blockchain-based data processing method, which includes:

[0010] Create a target block, which includes block header information and block body information. The block body information includes transaction data, and the block header information includes a standard Merkle root determined based on the transaction data.

[0011] The above block header information is digitally signed to obtain the target digital signature, and block proposal information is generated based on the target block and the target digital signature.

[0012] The aforementioned block proposal information is sent to the consensus nodes in the blockchain network so that the consensus nodes in the blockchain network can verify the data included in the aforementioned block proposal information and perform operations on the aforementioned target block based on the verification results.

[0013] This application provides a blockchain-based data processing device, which, in one embodiment, includes:

[0014] The data acquisition module 501 is used to receive block proposal information sent by the block producing node; wherein, the block proposal information includes a target block and a target digital signature, the target block includes block header information and block body information, the target digital signature is obtained by digitally signing the block header information, and the block header information includes a standard Merkle root determined based on the transaction data in the block body information.

[0015] The processing module 502 is used to obtain the block header information and the target digital signature from the block proposal information, perform digest calculation on the block header information to obtain the first digest information of the block header information, and perform designing processing on the target digital signature to obtain the second digest information of the block header information.

[0016] The aforementioned processing module 502 is further configured to, if the aforementioned first digest information matches the aforementioned second digest information, obtain the aforementioned standard Merkel root and the aforementioned transaction data from the aforementioned block proposal information, and determine the target Merkel root based on the aforementioned transaction data;

[0017] The aforementioned processing module 502 is further configured to perform operations on the aforementioned target block based on the comparison results between the aforementioned standard Merkel root and the aforementioned target Merkel root.

[0018] This application provides another blockchain-based data processing apparatus, which, when applied in one embodiment, includes:

[0019] The data acquisition module 501 is used to create a target block, which includes block header information and block body information. The block body information includes transaction data, and the block header information includes a standard Merkle root determined based on the transaction data.

[0020] The processing module 502 is used to perform digital signature processing on the above block header information to obtain a target digital signature, and generate block proposal information based on the above target block and the above target digital signature.

[0021] The aforementioned processing module 502 is further configured to send the aforementioned block proposal information to the consensus nodes in the blockchain network, so that the consensus nodes in the blockchain network can verify the data included in the aforementioned block proposal information and perform operations on the aforementioned target block based on the verification results.

[0022] This application provides a data processing device, including a processor, a memory, and a network interface, which are interconnected. The memory stores a computer program, which includes program instructions. The processor is configured to invoke the program instructions to implement the steps of the blockchain-based data processing method.

[0023] This application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which are executed by a processor to implement the steps of the blockchain-based data processing method described above.

[0024] This application provides a computer program product, which includes a computer program or computer instructions, which are executed by a processor to implement the steps of the blockchain-based data processing method described above.

[0025] This application leverages the characteristics of blockchain data structure. During the blockchain proposal process, the block-producing node directly constructs the target digital signature using the block header information. Compared to signing the entire target block (i.e., the block header and block body information), this significantly reduces the amount of data involved in constructing the digital signature, thus reducing the time consumed in the construction process. Simultaneously, a standard Merkle value determined based on transaction data is stored in the target block for consensus nodes to verify the received transaction data. This verifies both the block header information and the transaction data, ensuring the accuracy of the processing results based on the block proposal information. The block-producing node then generates block proposal information based on the target digital signature and the target block, improving the efficiency of proposal generation. Finally, the block-producing node sends the block proposal information to the consensus node, which performs corresponding operations on the target block based on the verification results returned by the consensus node.

[0026] During the consensus node's proposal processing, it first receives block proposal information from the block-producing node. Then, it calculates a digest of the block header information in the block proposal to obtain a first digest, and designs the target digital signature in the block proposal to obtain a second digest. Since both the first and second digests are generated from the corresponding block header information, they can be used to verify the block header information, ensuring its correctness. If the first and second digests match, a target Merkle root is calculated based on the received transaction data, and compared with the standard Merkle root in the block proposal information to verify the block body information (transaction data), ensuring its correctness. This method improves the efficiency of proposal processing compared to performing digest processing on a large amount of transaction data for data verification. During proposal transmission, since the target digital signature is generated based on the block header information, its data volume is relatively small, improving the efficiency of proposal transmission compared to signing the entire target block (i.e., block header and block body information). Finally, the consensus nodes perform the corresponding operations on the target block based on the comparison results. By using the above method, while ensuring the credibility of block proposal information, the efficiency of block-producing nodes in generating proposals and the efficiency of consensus nodes in processing proposals can be improved. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0028] Figure 1A This is a schematic diagram of a blockchain-based proposal process provided in an embodiment of this application;

[0029] Figure 1B This is a schematic diagram of the architecture of a blockchain-based data processing system provided in an embodiment of this application;

[0030] Figure 1C This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0031] Figure 1D This is a schematic diagram illustrating a process for generating a new block, provided in an embodiment of this application.

[0032] Figure 2 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application;

[0033] Figure 3AThis is a schematic diagram of the structure of a block in a blockchain provided in an embodiment of this application;

[0034] Figure 3B This is a schematic diagram of a process for calculating the root of a Merkel tree, provided in an embodiment of this application;

[0035] Figure 3C This is a schematic diagram of a blockchain-based proposal process provided in an embodiment of this application;

[0036] Figure 4 This is a flowchart illustrating another blockchain-based data processing method provided in an embodiment of this application;

[0037] Figure 5 This is a schematic block diagram of a blockchain-based data processing device provided in this embodiment;

[0038] Figure 6 This is a schematic block diagram of a data processing device provided in an embodiment of this application. Detailed Implementation

[0039] 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.

[0040] It should be noted that the terms "first," "second," etc., used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature specified with "first" or "second" may explicitly or implicitly include at least one of those features.

[0041] The following will explain some key terms that appear in the embodiments of this application.

[0042] In a blockchain, a block consists of two main parts: the block header and the block body. The block header stores information such as the hash of the previous block (PreHash), the hash of the current block body (Hash), and a timestamp (TimeStamp). The block body stores the detailed data of the block, which includes several lines of records; this data can be transaction information or other types of information. The node that produces the block packages the block information along with its own signature into a network message and broadcasts it to other nodes. This message is called a proposal, and proposals are a common message type in blockchains.

[0043] A digital signature, also known as a public-key digital signature, is a string of numbers that only the sender of the information can generate and that cannot be forged by other objects. This string of numbers also serves as valid proof of the authenticity of the information sent by the sender. A digital signature is similar to a physical signature written on paper, but it uses public-key cryptography techniques to achieve its purpose. It is a method for verifying digital information. A digital signature typically defines two complementary operations: one for signing and the other for verification. Digital signatures are an application of asymmetric key encryption technology and digital digest technology.

[0044] A consortium blockchain is a system architecture that falls between public and private blockchains, often controlled by multiple central entities. Several organizations collaborate to maintain a blockchain, which requires restricted access with protected information; examples include supply chain organizations or banking consortia. A consortium blockchain can be viewed as a distributed escrow ledger system controlled by multiple "authoritative" nodes designated by the organization. These nodes manage and operate the entire system based on a consensus mechanism. Consortium blockchains can be considered "partially decentralized," allowing public access and transactions, but requiring consortium permission to verify transactions or publish smart contracts. A key characteristic of consortium blockchains is that each node typically has a corresponding entity, and joining or leaving the system requires consortium approval. Various stakeholders collaborate closely on the blockchain, jointly maintaining its healthy and stable development. In a consortium blockchain, nodes have certain access control mechanisms, and inter-node communication requires carrying identity information (e.g., digital signatures). Only after verifying that the message originates from a valid node in the consortium (i.e., the signature verification process) can the message be accepted and processed by other nodes. This application will use a consortium blockchain as an example to describe the methods in subsequent embodiments.

[0045] This application first proposes a blockchain proposal method; please refer to [link to relevant documentation]. Figure 1A The blockchain proposal process includes two parts: block-producing node proposal and consensus node proposal processing.

[0046] During the block-producing node proposal process, the block-producing node M first constructs block A; then serializes block A into a binary array B; then performs digest calculation on the binary array B to obtain a digital digest C; then signs the digital digest C to obtain a digital signature D; finally, the block-producing node packages block A and digital signature D into a proposal (A+D) and broadcasts it to the consensus nodes.

[0047] During the proposal processing process, consensus node N first receives the proposal (A+D) broadcast by the block-producing node; then it extracts block A from the proposal (A+D) and serializes block A into a binary array B1; next, it performs a digest calculation on the binary array B1 to obtain a digital digest C1; the consensus node uses the public key of the block-producing node to decrypt the digital signature D to obtain a digital digest C2; finally, it compares digital digest C1 and digital digest C2. If C1 equals C2, then block A is processed; if C1 does not equal C2, then block A is rejected.

[0048] The above method enables blockchain proposals. Block-producing nodes construct digital signatures based on the block header and block body information, package the target block and digital signature into a proposal, and send it to the consensus node. The consensus node receives the target block and digital signature, generates a digital digest using the block header and block body information, decrypts the received digital signature to generate another digital digest, and verifies the authenticity and completeness of the received proposal by comparing the two digests. However, when a block is large (i.e., the blockchain load is high), the data volume of a single block is large, making the entire proposal process time-consuming. This is because constructing a digital signature requires serializing a large list of transactions (i.e., block body information), a time-consuming process that reduces the overall chain performance. This application utilizes the characteristics of the blockchain data structure to directly construct digital signatures using the block header information, significantly reducing the amount of data involved in constructing digital signatures. It also constructs a target Merkle root using the received transaction data and verifies the transaction data against a standard Merkle root generated from the block header based on its own transaction data, ensuring the credibility of the information and improving the efficiency of the proposal.

[0049] This application will be illustrated through the following examples:

[0050] Please see Figure 1B This is a schematic diagram of the architecture of a blockchain-based data processing system provided in an embodiment of this application. The blockchain-based data processing system includes a blockchain network 10 and a client 102, wherein:

[0051] Blockchain network 10 refers to a network used for data sharing between nodes. The blockchain network may include multiple nodes 101, among which consensus nodes may be included. Each node 101, in its normal operation, receives input information and maintains shared data (i.e., the blockchain) within the blockchain network based on the received input information. Each node in the blockchain network stores the same blockchain, which consists of a series of blocks sequentially generated in chronological order, such as... Figure 1BAs shown in the diagram, blocks 1, M-1, etc., are blocks that, once added to the blockchain, will not be removed. Blocks record the data submitted by nodes in the blockchain network. To ensure information exchange within the blockchain network, each node can be connected to another node, enabling peer-to-peer (P2P) communication between any two nodes. This P2P communication can be conducted via wired or wireless communication links. For example, when any node in the blockchain network receives input information, other nodes retrieve this input information according to the consensus algorithm and store it as part of the shared data, ensuring consistency of data stored on all nodes in the blockchain network.

[0052] Client 102 can access the blockchain network and communicate with nodes in the blockchain network, such as sending transaction data to nodes. The terminal where client 102 is located can be a smartphone, tablet, laptop, desktop computer, in-vehicle smart terminal, etc., and this embodiment of the application does not limit the specific device.

[0053] It should be noted that, Figure 1B The number of nodes shown is merely illustrative. Any number of nodes can be deployed as needed. A node can refer to any form of computing device connected to the network, such as a server or user terminal.

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

[0055] Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0056] In this blockchain network, each node stores an identical copy of the blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 1CA blockchain consists of multiple blocks. The genesis block includes a block header 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.

[0057] When generating the various blocks in the blockchain, see [link / reference]. Figure 1D When a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

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

[0059] 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.

[0060] 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 containing the blockchain sends the newly generated block to other nodes in its blockchain network based on the node identifiers of other nodes in the blockchain network. The other nodes verify the newly generated block and, after verification, add the newly generated block to their stored blockchain.

[0061] In a blockchain network, smart contracts can run on nodes, enabling various transactions. A smart contract is an immutable, automatically executing computer program that runs on the blockchain. It's code that executes when certain conditions are met. Developers can define contract logic using programming languages, publish it to the blockchain (smart contract registration), and execute it based on the contract terms, triggered by keys or other events. The blockchain also provides functions for upgrading and deregistering smart contracts.

[0062] In some feasible implementations, any node 101 of the blockchain network can obtain transaction data from a client. This transaction data may carry the client's identity identifier, which can be determined based on the client's identity certificate. Node 101 can query the client's identity certificate from the smart contract based on the identity identifier. If the client's identity certificate is found in the smart contract, and the identity certificate determines that the client has the authority to execute the transaction operation corresponding to the transaction data on the blockchain, then node 101 can execute the transaction operation corresponding to the transaction data on the blockchain. By utilizing the mapping relationship between the identity identifier carried in the transaction data and the identity certificate recorded in the smart contract, the corresponding identity certificate of the client can be determined, and the transaction operation can be performed according to the permissions indicated in the identity certificate, thereby improving the security of data processing on the blockchain. Carrying only the identity identifier in the transaction data, while ensuring that the corresponding identity certificate can be obtained, can reduce the amount of transaction data compared to carrying the complete identity certificate in the transaction data, which is conducive to the rapid transmission of transaction data.

[0063] Typically, it is also necessary to generate transaction blocks for the transaction data and put the blocks on the blockchain (store the blocks on the blockchain). Since only the identity identifier is carried, the amount of transaction data can be reduced compared to carrying the complete identity certificate in the transaction data, while ensuring that the corresponding identity certificate can be obtained. This can achieve a certain degree of data compression, thereby reducing the consumption of blockchain storage resources.

[0064] It is understood that in the specific implementation of this application, data related to blockchain status data, transaction data, user information, etc. are involved. When the above data is used in specific products or technologies in the embodiments of this application, user permission or consent is required. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0065] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0066] Please see Figure 2 , Figure 2This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The data processing method in this embodiment is described from the perspective of the consensus node side, such as... Figure 2 As shown, this blockchain-based data processing method may include:

[0067] S201. Receive block proposal information sent by the block-producing node; wherein, the block proposal information includes the target block and the target digital signature, the target block includes block header information and block body information, the target digital signature is obtained by digitally signing the block header information, and the block header information includes the standard Merkle root determined based on the transaction data in the block body information.

[0068] First, let's introduce the structure of the block (i.e., the target block). Please refer to [link / reference]. Figure 3A , Figure 3A This is a schematic diagram of the structure of a block in a blockchain provided in an embodiment of this application. The block includes a block header and a block body. The block header includes the parent block hash (Prev Block Hash), timestamp, version number, Merkel root hash, nonce, and difficulty target. The block body includes multiple transactions (e.g., ...). Figure 3A (Transaction 1, Transaction 2, Transaction 3, Transaction 4...Transaction N).

[0069] In the block header, the parent block hash is used to link blocks to their parent blocks, recording the hash address of the parent block. Its effects are twofold: firstly, it allows tracing all blockchain transactions preceding a single block, providing excellent traceability; secondly, any change to a block will alter the hash values ​​of all subsequent blocks unless all subsequent blocks are modified, demonstrating the ledger's immutability or prohibitive cost of modification. The timestamp indicates the transaction's existence time. An ordered chain of timestamps can be seen across the entire blockchain, and these timestamps are immutable. The version number describes the version number of the software or protocol update. The Merkle root hash is the digital fingerprint of a transaction, uniquely identifying some or all of the transaction data in the block body. Any modification to any transaction data within the Merkle root will change this digital fingerprint, affecting the block's hash value and consequently altering the hash values ​​of all subsequent blocks. The target value is a random number input by the user, initially set to 0. This target value is crucial to the Proof-of-Work algorithm. Assuming the hash value of the current block is equal to the hash value of the entire block header, the consensus node first uses the Merkle root (a hash value generated by hashing transaction records) to generate the target value before calculating the hash value itself. Then, it continuously attempts to input the target value until the input target value is less than the threshold of the hash value obtained for the current block. The difficulty value describes the target difficulty of the Proof-of-Work algorithm for this block.

[0070] The block body contains the transactions stored in that block, including the transaction count and transaction data. Specifically, the block body is divided into three parts: numTransactionsBytes, numTransactions, and transactions. numTransactionsBytes is 1 byte in size and records the number of bytes occupied by the transaction count; numTransactions is 0-8 bytes in size and records the total number of transactions within the block; transactions is of uncertain size and records multiple transaction data within the block's memory. Among these, numTransactions (recording the number of transactions within the block) is a crucial field for storing transaction information. Using compressed storage for numTransactions significantly saves storage space. The numTransactionsBytes field indicates the location of numTransactions within the block body, preparing for the retrieval of the transaction count.

[0071] In this embodiment, the block proposal information includes a target block and a target digital signature. The target digital signature is obtained by digitally signing the block header information. The block header information includes a standard Merkle root determined based on the transaction data in the block body information. The specific methods for performing the digital signature and calculating the standard Merkle root will be described in detail in subsequent embodiments and will not be repeated in this embodiment.

[0072] It should be noted that in this application, the block header information refers to the block header portion, the block body information refers to the block body portion, and the Merkle root refers to the Merkle root hash value. Other relevant data can be referred to the relevant description of the data structure in the blockchain. This application will not repeat them in subsequent embodiments.

[0073] In one embodiment, since a consensus node may receive block proposal information sent by another node (such as the block-producing node mentioned above), but the node sending the block proposal information is not necessarily the master node responsible for block production at the current stage, it may also be block proposal information sent by an abnormal node. To ensure the security of the proposal, it is necessary to verify the node identifier of the received block proposal information. Based on this, the block proposal information may include the node identifier of the block-producing node. The steps for verifying the node identifier of the received block proposal information are as follows.

[0074] (1) Obtain the node identifier of the master node responsible for producing blocks at the current stage, and obtain the node identifier of the producing node from the block proposal information.

[0075] In this embodiment, the current stage refers to the block height, that is, the nth block in the blockchain currently being processed. The master node responsible for producing blocks in the current stage is selected. For example, if node 1 is selected to produce blocks 1000-1050 in the current stage, then node 1 is the node identifier of the master node responsible for producing blocks in the current stage. Based on this, the consensus node can obtain the node identifier of the master node according to the above method, and then obtain the node identifier of the block producing node corresponding to the block proposal information from the block proposal information.

[0076] (2) If the node identifier of the block-producing node matches the node identifier of the master node, then the steps of obtaining the block header information and target digital signature from the block proposal information, performing digest calculation on the block header information, and obtaining the first digest information of the block header information are executed.

[0077] In this embodiment, by comparing the node identifier of the block-producing node with the node identifier of the master node, the consensus node can determine whether the received block proposal information was sent by the master node responsible for block production at the current stage, thereby ensuring data security. If the node identifier of the block-producing node matches the node identifier of the master node, the steps of obtaining the block header information and the target digital signature from the block proposal information, performing digest calculation on the block header information, and obtaining the first digest information of the block header information can continue to be executed, that is, steps S202 to S204 can continue to be executed.

[0078] In one embodiment, if the node identifier of the block-producing node does not match the node identifier of the master node, it indicates that the received block proposal information was not sent by the master node responsible for block production at the current stage. The consensus node can then refuse to process the block proposal information and continue to wait to obtain the next block proposal information. It then uses the node identifier judgment method provided above to verify the master node until it detects the block proposal information sent by the master node responsible for block production at the current stage. The consensus node then performs blockchain operations (e.g., block consensus) on the target block in the verified block proposal information.

[0079] S202. Obtain the block header information and target digital signature of the target block from the block proposal information, perform digest calculation on the block header information to obtain the first digest information of the block header information, and perform designing processing on the target digital signature to obtain the second digest information of the block header information.

[0080] In this embodiment, the block header information stores the block's header information, such as the parent block hash (PrevBlock Hash), timestamp, version number, Merkel root hash, nonce, and difficulty target. By performing a digest calculation on the block header information, a first digest can be generated. That is, different block header information generates different digests. Furthermore, any modification to any data in the same block header information will change the generated digest.

[0081] The target digital signature is extracted by the consensus node from the received block proposal information. Since the target digital signature is determined by the block-producing node based on the block header information, the consensus node can obtain the second digest information of the corresponding block header information by designing the target digital signature. Because the target digital signature is generated based on the block header information and its data volume is relatively small, the block proposal information transmission efficiency is improved compared to signing the entire target block (i.e., the block header information and block body information) before transmitting the block proposal information.

[0082] By comparing the first digest and second digest information corresponding to the block header information, the consensus node can determine whether the block header information of the target block in the received block proposal information has been tampered with (if the first digest and second digest information match, the block header information is determined to have been tampered with; if the first digest and second digest information do not match, the block header information is determined not to have been tampered with), thus ensuring the accuracy of the block header information. Since this embodiment only verifies the correctness of the block header information, but the block body information may also be tampered with, it is also necessary to verify the block body information (e.g., transaction data). This application proposes a method for verifying block body information based on Merkle tree roots. The specific operation steps will be described in detail in subsequent embodiments and will not be repeated here.

[0083] In one embodiment, the target digital signature carries a public key for decrypting the target digital signature (or, the consensus node stores a public key distributed by the block-producing node that can decrypt the target digital signature). The process by which the consensus node designs the target digital signature to obtain the second digest information of the block header can be that the consensus node uses the public key to design the target digital signature to obtain the second digest information of the block header.

[0084] In one embodiment, the above-mentioned digest calculation of the block header information to obtain the first digest information of the block header information is implemented in the following specific steps.

[0085] (1) Serialize the block header information to obtain serialized data.

[0086] In this embodiment, serialization refers to the process of converting program data (e.g., block data in this embodiment) into a format that can be stored and transmitted, so as to realize the storage, writing to files, and data transmission of the serialized data. The reverse process of serialization is deserialization, which can reconstruct program data from the stream. In this application, by combining serialization and deserialization, data storage and transmission can be easily achieved. By generating and storing serialized data using serialization technology, when the program is run again or data processing is performed, it is only necessary to read the stored serialized data to perform relevant operations, thereby improving data processing speed. Applying this method to the digest generation process in this application improves digest generation efficiency.

[0087] In one embodiment, object serialization and deserialization can be performed using Java's native ObjectOutputStream.write() and ObjectInputStream.read() methods; JSON-based methods can also be used; and XML-based methods can also be used.

[0088] (2) Perform digest calculation on the serialized data to obtain the first digest information of the block header information.

[0089] In this embodiment, digest calculation refers to digital digest (also called digital fingerprint or digital fingerprint) processing, which transforms a message of arbitrary length into a fixed-length short message. Digital digest processing can be viewed as a function (i.e., a hash function) that processes messages of arbitrary length. A one-way hash function is used to process the plaintext to be encrypted into a fixed-length (128-bit) ciphertext. This ciphertext is also called a digital fingerprint. Since different plaintexts will always result in different ciphertexts, while the same plaintext will always have the same digest, by performing digest calculation on the serialized data, consensus nodes only need to compare whether the first digest and second digest information corresponding to the block header information are consistent to confirm whether the block header information has been tampered with, thus ensuring the authenticity and integrity of the block header information.

[0090] In one embodiment, the digital digest processing can employ MD5 (Message-Digest Algorithm, a cryptographic hash function). The MD5 method generates a 128-bit (16-byte) hash value to ensure the integrity and consistency of transmitted information. Besides this, digital digest processing can also use any of the following methods: MD2, MD4, SHA1, SHA256, SHA384, and SHA512, which will not be elaborated upon in this embodiment.

[0091] S203. If the first digest information matches the second digest information, then obtain the standard Merkel root and transaction data from the block proposal information, and determine the target Merkel root based on the transaction data.

[0092] In this embodiment, the first digest information matches the second digest information, allowing the consensus node to determine that the block header information of the target block corresponding to the block proposal information has not been tampered with, thus ensuring the data accuracy of the block header information. Since block body information may also be tampered with, it is also necessary to verify the block body information (e.g., transaction data).

[0093] Since the block header information includes a standard Merkle root determined based on the transaction data in the block body information, transaction data is obtained from the received block proposal information, and a target Merkle root is generated based on the transaction data. By comparing the standard Merkle root with the target Merkle root as a reference, it is possible to verify whether the transaction data in the block body information has been tampered with, thereby ensuring the authenticity and integrity of the block body information (transaction data).

[0094] It should be noted that the steps of obtaining the standard Merkle root from the block proposal information and obtaining transaction data can be performed simultaneously (e.g., simultaneously obtaining the standard Merkle root and obtaining transaction data) or in steps (e.g., first obtaining the standard Merkle root and then obtaining transaction data, or the order can be reversed).

[0095] In one embodiment, the determination of the target Merkel root based on transaction data in the block proposal information can be achieved based on the following steps.

[0096] (1) Obtain multiple transaction data from the block proposal information, as well as the sequence of multiple transaction data.

[0097] In this embodiment, the multiple transaction data in the target block have a temporal relationship, that is, they form a sequence. This sequence indicates the time when the transactions corresponding to the multiple transaction data occurred. When calculating the target Merkle root of the transaction data, incorporating the sequence of the transaction data enriches the descriptive dimensions of the data and reflects the unique correspondence between the target Merkle root and the transaction data.

[0098] (2) Obtain the hash values ​​of multiple transaction data.

[0099] This step involves obtaining the hash value of each transaction from multiple transaction data sets using a hash algorithm.

[0100] (3) Calculate multiple first hash values ​​corresponding to multiple first data groups using a hash algorithm. Each of the multiple first data groups includes two adjacent transaction data groups sorted according to the sequence of multiple transaction data.

[0101] (4) Calculate multiple second hash values ​​corresponding to multiple second data groups using a hash algorithm. Each second data group in the multiple second data groups includes two adjacent first hash values.

[0102] (5) Determine the target Merkle root based on the multiple second hash values.

[0103] Steps (3) to (5) are based on a binary tree calculation method, calculating the hash value layer by layer to finally obtain the target Merkle tree root. Please refer to [link to relevant documentation]. Figure 3B , Figure 3B This is a schematic diagram of a flowchart for calculating the root of a Merkel tree provided in an embodiment of this application. The following will illustrate this process. Figure 3B The steps (1) to (4) above will be explained in detail. For example, the block proposal information includes multiple transaction data (e.g., transaction 1, transaction 2, transaction 3, and transaction 4); obtain the hash values ​​of multiple transaction data (that is, perform a hash operation on transaction 1 to obtain the hash value of transaction 1, and according to this method, the hash values ​​of transaction 2, transaction 3, and transaction 4 can be obtained); then use the hash algorithm to calculate multiple first hash values ​​corresponding to multiple first data groups, the first data group includes two adjacent transaction data ordered according to the sequence of multiple transaction data (e.g., according to the sequence of transaction data 1 to 4, divide the 4 transaction data to obtain two first data groups, namely [hash value of transaction 1]). The process involves calculating the hash values ​​of transaction 1, 2, 3, and 4, and then calculating multiple first hash values ​​(e.g., the hash values ​​corresponding to transaction 1 and 2, and the hash values ​​corresponding to transaction 3 and 4). A hash algorithm is then used to calculate multiple second hash values ​​corresponding to multiple second data groups, each including two adjacent first hash values ​​(e.g., the hash values ​​corresponding to transaction 1, 2, 3, and 4 obtained by merging the hash values ​​corresponding to transaction 1 and 2 with the hash values ​​corresponding to transaction 3 and 4). Through these steps, all transaction data can be calculated sequentially using a binary tree approach, ultimately yielding a single hash value for each transaction, which is then used as the target Merkle tree root.

[0104] It should be noted that after performing the step of calculating multiple second hash values ​​corresponding to multiple second data groups using a hash algorithm (i.e., step 3 above), there may be more than two second hash values. When there are more than two second hash values, you can refer to the above steps (1) to (3) and repeat the execution until only two hash values ​​are generated. Then, perform a hash operation based on the two hash values ​​to obtain the final hash value. This final hash value is the target Merkle root.

[0105] The Merkle root in the above method is a digital fingerprint of the transaction data, uniquely identifying some or all of the transaction data in the block body. If any transaction data that constitutes the Merkle root is modified, this digital fingerprint will definitely change. By calculating the Merkle root, subsequent verification of whether the transaction data in the received block proposal information has been tampered with is based on the Merkle root, ensuring the reliability and integrity of the data.

[0106] In one embodiment, when the number of multiple transaction data in the block proposal information is odd, it is also necessary to construct balancing data, that is, to calculate the Merkle root based on the method provided above. The specific operation steps are as follows.

[0107] (1) Construct balanced data. Balanced data is obtained by copying the last transaction data from multiple transaction data.

[0108] (2) Add the balancing data to the end of multiple transaction data.

[0109] In this embodiment, when the number of multiple transaction data is odd, the Merkle root cannot be calculated using the method provided above because the method is based on a binary tree classification method and cannot be applied to cases where the number of transaction data is odd. Therefore, by copying the last transaction data from the multiple transaction data and placing it at the end of the transaction data as balancing data, the Merkle root can be calculated based on the method provided above, ensuring the accuracy of the Merkle root.

[0110] In one embodiment, the balancing data can be the last transaction among multiple transaction data sets, or any one of the transaction data sets (e.g., the first transaction data set). The balancing data can be appended to the end of the multiple transaction data sets or at any position within them. This embodiment also proposes a method for constructing and processing balancing data with better processing results. First, the balancing data is constructed by copying the first transaction data set from the multiple transaction data sets; then, the balancing data is appended to the beginning of the multiple transaction data sets. It should be noted that the balancing data construction and processing method can be appropriately configured according to different business data to achieve better processing results.

[0111] S204. Based on the comparison results between the standard Merkle root and the target Merkle root, perform the operation on the target block.

[0112] In this embodiment, the authenticity and completeness of block information (transaction data) can be determined based on the comparison result between the standard Merkle root and the target Merkle root. In one embodiment, performing operations on the target block based on the comparison result between the standard Merkle root and the target Merkle root may include the following steps.

[0113] (1) If the comparison results of the standard Merkle root and the target Merkle root are a match, then consensus processing is performed on the target block.

[0114] If the comparison between the standard Merkle root and the target Merkle root matches, it means that the block header and block body information in the block proposal information received by the consensus node have passed data verification and have not been tampered with. Therefore, consensus processing can be performed on the target block in the received block proposal information.

[0115] In one embodiment, when a consensus node is conducting block consensus, it can compare and verify the data in the target block in the received block proposal information with the data stored in its own memory. If the data matches, it confirms the consensus on the target block (that is, it votes in favor during block consensus) and feeds back the consensus result to the block node to complete the block consensus.

[0116] (2) If the comparison results between the standard Merkle root and the target Merkle root are not a match, the target block will not be processed and a feedback message will be sent to the block producing node. The feedback message is used to indicate that the transaction data in the target block has been tampered with.

[0117] In one embodiment, when the first digest information differs from the second digest information, a first anomaly report can be generated. The first anomaly report is used to indicate that the block header information of the received block proposal message has been tampered with. When the comparison results of the standard Merkle root and the target Merkle root are different, a second anomaly report can be generated. The second anomaly report is used to indicate that the block body information (i.e., transaction data) of the received block proposal message has been tampered with.

[0118] In this embodiment, the feedback information identifies the specific type of reception anomaly, i.e., the transaction data in the received block proposal information has been tampered with. In addition, feedback information corresponding to different situations can be sent to the block-producing node when the comparison results of the standard Merkle root and the target Merkle root match, when the first digest information matches the second digest information, and when the first digest information does not match the second digest information. The feedback information is used to indicate the abnormal state of the data under different circumstances, increasing the diversity of anomaly message prompts when data is abnormal, and facilitating corresponding processing by consensus nodes and block-producing nodes based on diverse anomaly message prompts.

[0119] In one embodiment, the following operations may also be performed when the comparison results between the standard Merkel root and the target Merkel root are not a match.

[0120] (1) Receive encrypted block proposal information sent by the block-producing node; the encrypted block proposal information is obtained by the block-producing node verifying the transaction data in the target block included in the block proposal information when the number of consensus nodes returning feedback information meets the message resending condition, and encrypting the block proposal information using the node public key of the consensus node in the blockchain network when the verification result is passed.

[0121] In this embodiment, the feedback information returned by the consensus node is used to indicate that the transaction data in the target block has been tampered with. The message retransmission condition can be a quantity threshold (e.g., 2 / 3), that is, when the number of consensus nodes returning feedback information reaches the quantity threshold, the block-producing node will verify the transaction data in the target block included in the block proposal information. A verification result of "pass" means that the block-producing node verifies the transaction data in the target block, finds the data to be correct, and then determines the verification result as "pass".

[0122] It is understandable that the block proposal information received by the consensus node includes transaction data. If there is an error in the transaction data, at least the following two situations will occur.

[0123] The first scenario involves an anomaly in the transaction data packaged by the block-producing node itself, leading to anomalies in the transaction data received by the consensus node. The second scenario involves accurate transaction data packaged by the block-producing node, but anomalies occur during the receipt of the transaction data by the consensus node. In both scenarios, the consensus node sends feedback to the block-producing node. After receiving a certain number of feedback messages from the consensus nodes, the block-producing node determines whether the anomaly is due to its own data or an anomaly occurring during the receipt of the block proposal information by the consensus node, resulting in errors in the data ultimately received by the consensus node (i.e., verification of the transaction data in the target block included in the block proposal information). If the block-producing node verifies that its own data is not anomaly (i.e., the verification result is successful), it uses the public key of the consensus nodes in the blockchain network to encrypt the block proposal information, obtaining encrypted block proposal information. The consensus node can then receive this encrypted block proposal information to re-obtain the block proposal information.

[0124] (2) Use the private key of the node corresponding to the node's public key to decrypt the encrypted block proposal information to obtain the decrypted block proposal information.

[0125] In one embodiment, each of the aforementioned node public and private keys can be generated only once. For example, there is one block-producing node (master node) and multiple consensus nodes. The block-producing node uses its unique public key to encrypt the block proposal information, obtaining encrypted block proposal information, and then sends this encrypted block proposal information to the multiple consensus nodes. The multiple consensus nodes use their unique private keys to decrypt the encrypted block proposal information, obtaining the decrypted block proposal information. This method is well-suited for environments with reliable transmission (e.g., consortium blockchains) because it uses only a unique public key to generate a single encrypted block proposal, eliminating the need to generate multiple encrypted block proposals based on different consensus nodes, thus improving proposal efficiency. Furthermore, by receiving the encrypted block proposal information sent by the block-producing node and then decrypting it to obtain the block proposal information, the consensus nodes can further reduce the risk of data anomalies when receiving block proposal information, ensuring the accuracy and integrity of the received block proposal information.

[0126] (3) Verify the data included in the decrypted block proposal information and perform operations on the target block based on the verification results.

[0127] In this embodiment, when the comparison results between the standard Merkle root and the target Merkle root are mismatched, the encrypted block proposal information sent by the block-producing node is received. The encrypted block proposal information is then decrypted to obtain the decrypted block proposal information. The data included in the decrypted block proposal information is then verified, and operations are performed on the target block based on the verification results. The method for verifying the data included in the decrypted block proposal information can be found in the specific descriptions of steps S202 to S204 and their respective embodiments, and will not be repeated in this embodiment.

[0128] Please see Figure 3C , Figure 3C This application presents another blockchain proposal method based on the aforementioned method. The blockchain proposal process includes two parts: block-producing node proposal and consensus node proposal processing.

[0129] During the block-producing node proposal process, the block-producing node M first constructs block A; then serializes the block header of block A (i.e., the block header information in this application) into a binary array B; then performs digest calculation on the binary array B to obtain a digital digest C; the block-producing node then signs the digital digest C to obtain a digital signature D; finally, the block-producing node packages block A and digital signature D into a proposal (A+D) and broadcasts it to the consensus nodes.

[0130] During the consensus node's proposal processing, consensus node N first receives the proposal (A+D) broadcast by the block-producing node; then it extracts block A from the proposal (A+D) and serializes the block header of block A (i.e., the block header information in this application) into a binary array B1; the consensus node then performs a digest calculation on the binary array B1 to obtain a digital digest C1; the consensus node uses the public key of the block-producing node to decrypt the digital signature D to obtain a digital digest C2; then it compares digital digest C1 and digital digest C2. If C1 is not equal to C2, it rejects processing block A; if C1 is equal to C2, the consensus node calculates the Merkle hash value corresponding to the transaction data in block A (i.e., the target Merkle root in this application), and then compares the standard Merkle root in the block header with the target Merkle root. If the standard Merkle root and the target Merkle root are the same, the consensus node processes block A; if the standard Merkle root and the target Merkle root are different, the consensus node rejects processing block A.

[0131] Using the above method, blockchain proposals can be implemented. Block-producing nodes construct digital signatures based on the block header information and package the target block and digital signature into a proposal, which is then sent to the consensus nodes. The consensus nodes receive the target block and digital signature, generate a digital digest using the block header information of the target block, and then decrypt the received digital signature to generate another digital digest. By comparing the two digests, the consensus nodes can verify the authenticity and completeness of the block header information in the received proposal. Finally, a target Merkle root value is generated based on the block body information in the proposal and compared with the standard Merkle root value of the block header information in the target block. This comparison allows the consensus nodes to verify the authenticity and completeness of the block body information in the received proposal.

[0132] Because constructing a digital signature during the proposal process is time-consuming, while calculating the target Merkle root value using transaction data is relatively quick, the method proposed in this application only requires processing the relatively small block header information during digital signature construction, eliminating the need to serialize a large list of transactions (i.e., block body information). This significantly reduces the amount of data involved in constructing the digital signature. The target Merkle root is then calculated based on the transaction data in the received block body information and compared with the standard Merkle root, thus ensuring the authenticity and completeness of the block body information in the proposal. Overall, this process greatly improves the efficiency of the proposal process while also ensuring the credibility of the proposal message.

[0133] In one embodiment, because the block-producing node broadcasts in real time, the consensus node may not receive the block proposal information or the complete block proposal information within a limited time. Therefore, the reception status of the block proposal information can be obtained first, and then subsequent operations can be performed based on the reception status. The specific steps are as follows.

[0134] (1) Determine whether the block proposal information sent by the block-producing node was successfully received within the target time.

[0135] (2) If the block proposal information sent by the block-producing node is successfully received within the target time, the step of performing digest calculation on the block header information in the block proposal information to obtain the first digest information is executed.

[0136] (3) If the block proposal information sent by the block-producing node is not successfully received within the target time, the target message is broadcast to the consensus node in the blockchain network. The target message is used to indicate that the block proposal information has failed to be received.

[0137] In this embodiment, determining whether block proposal information sent by the block-producing node was successfully received within the target time can be performed from multiple dimensions. For example, the completeness of the block proposal information can be checked. If the received data packet only contains block header information or only block body information, the received block proposal information is considered incomplete. This can be interpreted as the situation described above where the block proposal information sent by the block-producing node was not successfully received within the target time. In this case, a target message is broadcast to the consensus nodes in the blockchain network. The target message indicates that the reception of the block proposal information failed, and can also indicate that the block proposal information is incomplete and the data type is missing. By indicating relevant messages about block proposal information failure from different dimensions through the target message, the richness of the anomaly notification message dimensions is further improved, facilitating the consensus nodes to perform corresponding operation and maintenance operations based on the anomaly report.

[0138] In summary, this application leverages the characteristics of the blockchain data structure. During the consensus node's proposal processing, it first receives block proposal information sent by the block-producing node; then, it performs a digest calculation on the block header information in the block proposal information to obtain the first digest information, and designs the target digital signature in the block proposal information to obtain the second digest information. Since both the first and second digest information are generated corresponding to the block header information, comparing the first and second digest information allows for data verification of the block header information, thus ensuring its correctness. If the first and second digest information match, a target Merkle root is calculated based on the received transaction data, and this target Merkle root is compared with the standard Merkle root in the block proposal information. Because the Merkle root can uniquely identify part or all of the transaction data in the block body, data verification can be performed on the block body information (transaction data), thus ensuring the correctness of the block body information. This method improves the efficiency of proposal processing compared to data verification through digesting large amounts of transaction data. During proposal transmission, since the target digital signature is generated based on the block header information, its data volume is relatively small, thus improving transmission efficiency compared to signing the entire target block (i.e., block header and block body information). Finally, the consensus nodes perform corresponding operations on the target block based on the comparison results.

[0139] This application also proposes a method for constructing balanced data, improving the applicability of the method for verifying transaction data through Merkle tree roots; the consensus node finally performs corresponding operations on the target block based on the comparison results. Through the above methods, the production efficiency of block proposals is improved while ensuring the credibility of block proposal information. This application also verifies node identifiers by obtaining the node identifier of the master node responsible for block production at the current stage and the node identifier of the received block proposal information, avoiding receiving block proposal information sent by abnormal nodes and ensuring the security of proposals. This application improves the efficiency of digest generation by serializing the block header information and then performing digest calculation to obtain the digest information corresponding to the block header information.

[0140] This application proposes that when a consensus node detects a mismatch between the standard Merkle root and the target Merkle root, it should refuse to process the target block and send feedback to the block-producing node indicating that the transaction data in the target block has been tampered with. Furthermore, it proposes generating various anomaly messages to indicate abnormal situations based on different stages of the judgment results (such as mismatch in digest information comparison results or Merkle root comparison results), thus increasing the richness of anomaly alerts and facilitating appropriate processing by both consensus and block-producing nodes based on diverse anomaly alerts. This application also proposes that the consensus node receive and decrypt the encrypted block proposal information sent by the block-producing node to obtain new block proposal information, further reducing the risk of data anomalies when the consensus node receives block proposal information and ensuring the correctness of the received block proposal information. Finally, this application proposes that after receiving block proposal information, the consensus node should verify the completeness of the received block proposal information and generate a target message indicating the completeness verification status, further increasing the richness of anomaly alerts. By using the above methods, while ensuring the credibility of block proposal information, the efficiency of block-producing nodes in generating proposals and the efficiency of consensus nodes in processing proposals can be improved.

[0141] Please see Figure 4 , Figure 4 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The data processing method in this embodiment is described from the perspective of the block-producing node. This blockchain-based data processing method may include:

[0142] S401. Create the target block. The target block includes block header information and block body information. The block body information includes transaction data, and the block header information includes the standard Merkle root determined based on the transaction data.

[0143] In this embodiment, before performing block production operations (e.g., block consensus), the block-producing node needs to create a target block. The target block is the original data used by the block-producing node for block production operations. The block includes a block header and a block body. The block header includes the parent block hash (Prev Block Hash), timestamp, version number, Merkel root hash, nonce, and difficulty target. The block body includes multiple transactions (e.g., ...). Figure 3A (Transactions 1, 2, 3, 4... N). For the specific structure of the target block, please refer to [link to relevant documentation]. Figure 3A For a detailed description of the target block, please refer to the relevant descriptions in the foregoing embodiments; this embodiment will not repeat them here.

[0144] It is worth noting that the block header information includes a standard Merkle root, which is determined based on transaction data. For the method of determining the standard Merkle root based on transaction data, please refer to [link to relevant documentation]. Figure 3B The method for determining the target Merkel root based on transaction data in the block proposal information in the aforementioned embodiments will not be repeated in this embodiment.

[0145] S402. Perform digital signature processing on the block header information to obtain the target digital signature, and generate block proposal information based on the target block and the target digital signature.

[0146] In one embodiment, the above-mentioned digital signature processing of the block header information to obtain the target digital signature is implemented in the following specific steps.

[0147] (1) Serialize the block header information to obtain serialized data.

[0148] In this embodiment, serialization refers to the process of converting program data (e.g., block data in this embodiment) into a format that can be stored and transmitted, so as to realize the storage, writing to files, and data transmission of the serialized data. The reverse process of serialization is deserialization, which can reconstruct program data from the stream. In this application, by combining serialization and deserialization, data storage and transmission can be easily achieved. By generating and storing serialized data using serialization technology, when the program is run again or data processing is performed, it is only necessary to read the stored serialized data to perform relevant operations, thereby improving data processing speed. Applying this method to the digest generation process in this application improves digest generation efficiency.

[0149] In one embodiment, object serialization and deserialization can be performed using Java's native ObjectOutputStream.write() and ObjectInputStream.read() methods; JSON-based methods can also be used; and XML-based methods can also be used.

[0150] The method by which the block-producing node serializes the block header information to obtain serialized data can be found in the description of the method by which the consensus node serializes the block header information to obtain serialized data in the previous embodiment, and will not be repeated in this embodiment.

[0151] (2) Perform digest calculation on the serialized data to obtain the second digest information of the block header information.

[0152] In this embodiment, digest calculation refers to performing digital digest (also called digital fingerprint or digital fingerprint) processing to transform a message of arbitrary length into a fixed-length short message. Digital digest processing can be viewed as a function (i.e., a hash function) that processes messages of arbitrary length. By employing a one-way hash function, the plaintext to be encrypted is processed into a fixed-length (128-bit) ciphertext. This ciphertext is also called a digital fingerprint. Since different plaintexts will always result in different ciphertexts, while the same plaintext will always have the same digest, by performing digest calculation on the serialized data, consensus nodes only need to compare whether the first digest information and the second digest information corresponding to the block header information are consistent to confirm whether the block header information has been tampered with, thus ensuring the authenticity and integrity of the block header information.

[0153] In one embodiment, the digital digest processing can employ MD5 (Message-Digest Algorithm, a cryptographic hash function). The MD5 method generates a 128-bit (16-byte) hash value to ensure the integrity and consistency of transmitted information. Besides this, digital digest processing can also use any of the following methods: MD2, MD4, SHA1, SHA256, SHA384, and SHA512, which will not be elaborated upon in this embodiment.

[0154] The method by which the block-producing node performs digest calculation on the serialized data to obtain the second digest information of the block header information can be found in the description of the method by which the consensus node performs digest calculation on the serialized data to obtain the first digest information of the block header information in the aforementioned embodiment. This embodiment will not repeat the description.

[0155] (3) Use the signature private key to encrypt the second digest information to obtain the target digital signature.

[0156] In this embodiment, the digital signature method serves two purposes: verification and encryption. Verification refers to verifying the identity of the message sender (i.e., the block-producing node) to prevent forgery; while encryption refers to encrypting the plaintext (i.e., the second digest information) to prevent leakage to non-message recipients. Digital signatures can be implemented using either "symmetric encryption" (encryption and decryption use the same key and require a third-party arbitrator) or "asymmetric encryption" (information encrypted with a public key can only be decrypted with the private key, and vice versa; two key pairs are used, each containing a public key and a private key, and digital signatures can be completed without third-party arbitration).

[0157] S403. Send the block proposal information to the consensus nodes in the blockchain network so that the consensus nodes in the blockchain network can verify the data included in the block proposal information and perform operations on the target block according to the verification results.

[0158] In this embodiment, the block proposal information is generated by packaging the target block and the target digital signature. The block proposal information is sent to the consensus node in the blockchain network, and the consensus node waits for the received block proposal information to be verified. When the block producing node receives the verification result returned by the consensus node, it can determine whether the consensus node has reached a consensus on the target block in the block proposal information based on the verification result, so as to execute subsequent blockchain operations (such as adding the block to the chain).

[0159] In one embodiment, the target digital signature in the block proposal information also carries a public key for decrypting the target digital signature (or, the consensus node stores a public key distributed by the block-producing node that can decrypt the target digital signature). The process of designing the target digital signature to obtain the second digest information of the block header information can be performed by the block-producing node using the public key to design the target digital signature and obtain the second digest information of the block header information.

[0160] In one embodiment, if the consensus node detects a mismatch between the standard Merkle root and the target Merkle root, it refuses to process the target block and sends feedback information to the block-producing node. This feedback information indicates that the transaction data in the target block has been tampered with. The block-producing node can receive the feedback information returned by the consensus node and perform corresponding operations based on it, as detailed below.

[0161] (1) Receive feedback information returned by consensus nodes in the blockchain network. The feedback information is used to indicate that the transaction data in the target block has been tampered with. If the number of consensus nodes that return feedback information meets the message retransmission condition, the transaction data in the target block included in the block proposal information is verified.

[0162] In this embodiment, the feedback information returned by the consensus node is used to indicate that the transaction data in the target block has been tampered with. The message retransmission condition can be a quantity threshold (e.g., 2 / 3), that is, when the number of consensus nodes returning feedback information reaches the quantity threshold, the block-producing node will verify the transaction data in the target block included in the block proposal information. A verification result of "pass" means that the block-producing node verifies the transaction data in the target block, finds the data to be correct, and then determines the verification result as "pass".

[0163] It is understandable that the block proposal information received by the consensus node includes transaction data. If the transaction data is incorrect, there are at least two possibilities: first, the transaction data packaged by the block-producing node itself is abnormal, leading to abnormal transaction data received by the consensus node; second, the transaction data packaged by the block-producing node itself is accurate, but the consensus node encounters an error during the receipt of the transaction data. The consensus node will return feedback information to the block-producing node. After the block-producing node receives a certain number of feedback messages from the consensus nodes, it will then determine whether the error is due to its own data or an error that occurred when the consensus node received the block proposal information, resulting in the error in the data ultimately received by the consensus node (i.e., verifying the transaction data in the target block included in the block proposal information). When the block-producing node verifies that its own data is not abnormal (i.e., the verification result is passed), it uses the public key of the consensus nodes in the blockchain network to encrypt the block proposal information to obtain encrypted block proposal information. The above method can be understood as follows: when a block-producing node receives feedback from a consensus node that its transaction data has been tampered with, it verifies its own transaction data. If the data is found to be correct (i.e., the consensus node encountered an anomaly when receiving the data), it encrypts and sends the block proposal information. The consensus node can then receive this encrypted block proposal information to retrieve the original block proposal information.

[0164] In one embodiment, the block-producing node receives feedback information returned by the consensus node in the blockchain network. This feedback information can be multi-dimensional. For example, the feedback information could be the consensus node's verification of the completeness of the block proposal information. If the received data packet only contains block header information or only contains block body information, the received block proposal information is considered incomplete (this can be seen as the situation described above where the block proposal information sent by the block-producing node was not successfully received within the target time). The returned feedback information indicates that the reception of the block proposal information failed. Simultaneously, the feedback information can also indicate that the block proposal information is incomplete and that any data types are missing. By receiving multi-dimensional feedback information from the consensus node in the blockchain network, the block-producing node increases the richness of the anomaly message dimensions, facilitating the block-producing node to perform corresponding operations based on the received multi-dimensional feedback information.

[0165] (2) If the verification result is successful, the block proposal information is encrypted using the public key of the consensus node in the blockchain network to obtain the encrypted block proposal information.

[0166] (3) Send the encrypted block proposal information to the consensus nodes in the blockchain network.

[0167] In this embodiment, the block-producing node sends encrypted block proposal information to the consensus node, which then uses its private key to decrypt the block proposal information. This improves the success rate of block proposal information delivery, reduces the risk of data anomalies when the consensus node receives block proposal information, and enhances the accuracy and integrity of the received block proposal information.

[0168] In one embodiment, the feedback information is sent by the consensus node when it detects that the standard Merkle root and the target Merkle root included in the block proposal message do not match; the target Merkle root is determined by the consensus node based on the transaction data in the block proposal information when it detects that the first digest information and the second digest information of the block header information do not match; the first digest information is obtained by the consensus node performing a digest calculation on the block header information in the block proposal information, and the first digest information is obtained by the consensus node performing designing processing on the target digital signature in the block proposal information.

[0169] The descriptions of feedback information, target Merkel root, first summary information, and second summary information can be found in the relevant descriptions of the first embodiment of this application, and will not be repeated in this embodiment.

[0170] In one embodiment, the process by which the block-producing node determines the standard Merkle root of the target block can be implemented according to the following steps.

[0171] (1) Obtain multiple transaction data from the block body information, as well as the sequence of multiple transaction data.

[0172] (2) Determine multiple first hash values ​​corresponding to multiple first data groups according to the hash algorithm, wherein each of the multiple first data groups includes two adjacent transaction data ordered according to the sequence of the transaction data.

[0173] (3) Determine multiple second hash values ​​corresponding to multiple second data groups according to the hash algorithm. Each of the multiple second data groups includes two adjacent first hash values.

[0174] (4) Determine the standard Merkle root based on multiple second hash values.

[0175] For the specific implementation process described above, please refer to the relevant description of the consensus node determining the target Merkel root in the first embodiment of this application. This embodiment will not repeat it.

[0176] In one embodiment, when the number of multiple transaction data in the block proposal information is odd, the block producing node also needs to construct balancing data, which can be done by calculating the Merkle root based on the method provided above. The specific operation steps are as follows.

[0177] (1) Construct balanced data. Balanced data is obtained by copying the last transaction data from multiple transaction data.

[0178] (2) Add the balancing data to the end of multiple transaction data.

[0179] In this embodiment, when the number of multiple transaction data is odd, the Merkle root cannot be calculated using the method provided above because the method is based on a binary tree classification method and cannot be applied to cases where the number of transaction data is odd. Therefore, the block-producing node can calculate the Merkle root based on the method provided above by copying the last transaction data from the multiple transaction data and placing it at the end of the transaction data as balancing data, thus ensuring the accuracy of the Merkle root.

[0180] In one embodiment, the balancing data can be the last transaction among multiple transaction data sets, or any one of the multiple transaction data sets (e.g., the first transaction data set). Furthermore, the balancing data can be added to the end of the multiple transaction data sets, or at any position within the multiple transaction data sets. It should be noted that the construction and processing methods of the balancing data can be appropriately configured according to different business data to achieve better processing results.

[0181] In one embodiment, the block-producing node can perform operations on the target block based on the verification result. The verification result can be the voting result of the consensus nodes regarding the block proposal information. Therefore, the block-producing node's operation on the target block based on the verification result may include the following steps.

[0182] (1) Receive the voting results of consensus nodes in the blockchain network regarding block proposal information.

[0183] (2) Determine the consensus result based on the voting results.

[0184] In one embodiment, the method for determining the consensus result based on the voting results may include the following steps.

[0185] 1) Determine the number of votes that were in favor of the decision, and the total number of votes that were determined.

[0186] 2) Calculate the ratio between the number of votes in favor and the total number of votes, and check whether the ratio is greater than the proportion threshold.

[0187] 3) If the ratio is greater than the ratio threshold, the consensus result is determined to be a consensus reached; if the ratio is less than or equal to the ratio threshold, the consensus result is determined to be a consensus not reached.

[0188] (3) If the consensus result is that a consensus has been reached, the target block will be added to the blockchain.

[0189] In this embodiment, the voting result can be the result data (e.g., for or against) obtained by consensus nodes after verifying the legality of transaction data in the target block and the execution order of each transaction corresponding to the transaction data. The block-producing node receives the voting results from each consensus node and determines whether to add the target block to the blockchain based on the voting results. For example, if more than 2 / 3 of the consensus nodes agree to add the target block to the blockchain (i.e., more than 2 / 3 of the consensus nodes vote in favor, reaching a consensus), then the target blockchain is added to the blockchain.

[0190] In summary, this application leverages the characteristics of the blockchain data structure. During the blockchain proposal process, the block-producing node directly constructs the target digital signature using the block header information. Compared to signing the entire target block (i.e., the block header and block body), this significantly reduces the amount of data involved in constructing the digital signature, thus reducing the time consumed in the construction process. Simultaneously, a standard Merkle value determined based on the transaction data is stored in the target block for the consensus node to verify the received transaction data. This verifies both the block header information and the transaction data, ensuring the accuracy of the processing results based on the block proposal information system. The block-producing node then generates block proposal information based on the target digital signature and the target block, improving the efficiency of proposal generation. Finally, the block-producing node sends the block proposal information to the consensus node, which performs corresponding operations on the target block based on the verification results returned by the consensus node.

[0191] This application proposes a feedback message sent by the block-producing node when it receives a mismatch between the standard Merkle root and the target Merkle root from the consensus node. This feedback message indicates that the transaction data in the target block has been tampered with. It also proposes various anomaly messages generated by the consensus node based on different stages of the judgment (e.g., mismatch in digest information comparison, mismatch in Merkle root comparison). This improves the richness of the anomaly message dimensions, facilitating the block-producing node to handle different anomaly messages accordingly. Furthermore, this application proposes that when the number of consensus nodes that have failed to receive block proposal information reaches a threshold, the block-producing node sends encrypted block proposal information to the consensus node. This reduces the risk of data anomalies when the consensus node receives block proposal information, ensuring the accuracy and integrity of the received block proposal information. This application also proposes that the block-producing node can determine whether the requirements for adding the block to the blockchain are met based on the verification results, and decide whether to execute the blockchain addition operation for the target block. Finally, this application proposes a method for the block-producing node to determine the target Merkle root and construct balanced data, improving the applicability of the method for verifying transaction data through the Merkle root. This application also proposes that the block generating node improves the digest generation efficiency by serializing the block header information and then performing digest calculation to obtain the digest information corresponding to the block header information.

[0192] Please see Figure 5 This is a schematic diagram of a blockchain-based data processing device provided in an embodiment of this application. The data processing device described in this embodiment can be applied to the first embodiment mentioned above, including:

[0193] The data acquisition module 501 is used to receive block proposal information sent by the block producing node; wherein, the block proposal information includes a target block and a target digital signature, the target block includes block header information and block body information, the target digital signature is obtained by digitally signing the block header information, and the block header information includes a standard Merkle root determined based on the transaction data in the block body information.

[0194] The processing module 502 is used to obtain the block header information and the target digital signature from the block proposal information, perform digest calculation on the block header information to obtain the first digest information of the block header information, and perform designing processing on the target digital signature to obtain the second digest information of the block header information.

[0195] The aforementioned processing module 502 is further configured to, if the aforementioned first digest information matches the aforementioned second digest information, obtain the aforementioned standard Merkel root and the aforementioned transaction data from the aforementioned block proposal information, and determine the target Merkel root based on the aforementioned transaction data;

[0196] The aforementioned processing module 502 is further configured to perform operations on the aforementioned target block based on the comparison results between the aforementioned standard Merkel root and the aforementioned target Merkel root.

[0197] Optionally, when the processing module 502 performs operations on the target block based on the comparison results of the standard Merkle root and the target Merkle root, it is specifically used for:

[0198] If the comparison results of the above standard Merkel root and the above target Merkel root are a match, then consensus processing is performed on the above target block.

[0199] If the comparison between the standard Merkle root and the target Merkle root is not a match, the target block will not be processed, and feedback information will be sent to the block-producing node. The feedback information indicates that the transaction data in the target block has been tampered with.

[0200] Optionally, the block proposal information mentioned above also includes the node identifier of the block-producing node, and the processing module 502 is further used for:

[0201] Obtain the node identifier of the master node responsible for producing blocks at the current stage, and obtain the node identifier of the block producing node from the block proposal information mentioned above;

[0202] If the node identifier of the block-producing node matches the node identifier of the master node, then the steps described above are executed: obtaining the block header information and the target digital signature from the block proposal information, performing digest calculation on the block header information, and obtaining the first digest information of the block header information.

[0203] Optionally, the above-mentioned processing module 502 is further used for:

[0204] When the comparison result between the standard Merkle root and the target Merkle root is not a match, the encrypted block proposal information sent by the block-producing node is received. The encrypted block proposal information is obtained by the block-producing node verifying the transaction data in the target block included in the block proposal information when the number of consensus nodes returning the feedback information meets the message retransmission condition, and encrypting the block proposal information using the node public key of the consensus node in the blockchain network when the verification result is successful.

[0205] The encrypted block proposal information is decrypted using the private key corresponding to the public key of the aforementioned node, resulting in the decrypted block proposal information.

[0206] The data included in the decrypted block proposal information is verified, and the operation is performed on the target block based on the verification result.

[0207] Optionally, when the processing module 502 performs digest calculation on the block header information to obtain the first digest information of the block header information, it is specifically used for:

[0208] The above block header information is serialized to obtain serialized data;

[0209] The serialized data is digested to obtain the first digest information of the block header information.

[0210] The data processing apparatus described in this embodiment can be applied to the second embodiment mentioned above, including:

[0211] The data acquisition module 501 is used to create a target block, which includes block header information and block body information. The block body information includes transaction data, and the block header information includes a standard Merkle root determined based on the transaction data.

[0212] The processing module 502 is used to perform digital signature processing on the above block header information to obtain a target digital signature, and generate block proposal information based on the above target block and the above target digital signature.

[0213] The aforementioned processing module 502 is further configured to send the aforementioned block proposal information to the consensus nodes in the blockchain network, so that the consensus nodes in the blockchain network can verify the data included in the aforementioned block proposal information and perform operations on the aforementioned target block based on the verification results.

[0214] Optionally, the above-mentioned processing module 502 is further used for:

[0215] The system receives feedback information returned by consensus nodes in the aforementioned blockchain network. This feedback information indicates that the transaction data in the aforementioned target block has been tampered with. If the number of consensus nodes returning the aforementioned feedback information meets the message retransmission condition, the system verifies the transaction data in the aforementioned target block included in the aforementioned block proposal information.

[0216] If the verification result is successful, the public key of the consensus node in the above blockchain network is used to encrypt the above block proposal information to obtain encrypted block proposal information.

[0217] The aforementioned encrypted block proposal information is sent to the consensus nodes in the aforementioned blockchain network.

[0218] Optionally, the aforementioned feedback information is sent by the consensus node when it detects a mismatch between the standard Merkle root and the target Merkle root included in the block proposal message; the target Merkle root is determined by the consensus node based on the transaction data in the block proposal information when it detects a mismatch between the first digest information and the second digest information of the block header information; the first digest information is obtained by the consensus node performing a digest calculation on the block header information in the block proposal information, and the first digest information is obtained by the consensus node performing designing processing on the target digital signature in the block proposal information.

[0219] Optionally, when the processing module 502 performs digital signature processing on the block header information to obtain the target digital signature, it is specifically used for:

[0220] The above block header information is serialized to obtain serialized data;

[0221] The above serialized data is digested to obtain the second digest information of the block header information;

[0222] The second digest information is encrypted using the signature private key to obtain the target digital signature.

[0223] It should be noted that the functions of each functional module of the data processing device in this application embodiment can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0224] Please see Figure 6 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device described in this embodiment includes: a processor 601, a memory 602, and a network interface 603. The processor 601, the memory 602, and the network interface 603 can exchange data.

[0225] The processor 601 described above can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0226] The aforementioned memory 602 may include read-only memory and random access memory, and provides program instructions and data to the processor 601. A portion of the memory 602 may also include non-volatile random access memory. In a feasible embodiment, this data processing device can be applied to the first embodiment described above, wherein the processor 601 executes the aforementioned program instructions when it calls them:

[0227] Receive block proposal information sent by the block-producing node; wherein, the block proposal information includes a target block and a target digital signature, the target block includes block header information and block body information, the target digital signature is obtained by digitally signing the block header information, and the block header information includes a standard Merkle root determined based on the transaction data in the block body information.

[0228] The block header information and the target digital signature are obtained from the block proposal information. The block header information is digested to obtain the first digest information of the block header information. The target digital signature is designed to obtain the second digest information of the block header information.

[0229] If the first summary information matches the second summary information, then the standard Merkel root and the transaction data are obtained from the block proposal information, and the target Merkel root is determined based on the transaction data.

[0230] Based on the comparison results between the standard Merkel root and the target Merkel root, the operation is performed on the target block.

[0231] Optionally, when the processor 601 performs operations on the target block based on the comparison result of the standard Merkle root and the target Merkle root, it specifically performs the following operations:

[0232] If the comparison results of the above standard Merkel root and the above target Merkel root are a match, then consensus processing is performed on the above target block.

[0233] If the comparison between the standard Merkle root and the target Merkle root is not a match, the target block will not be processed, and feedback information will be sent to the block-producing node. The feedback information indicates that the transaction data in the target block has been tampered with.

[0234] Optionally, the block proposal information mentioned above also includes the node identifier of the block-producing node, and the processor 601 is further used for:

[0235] Obtain the node identifier of the master node responsible for producing blocks at the current stage, and obtain the node identifier of the block producing node from the block proposal information mentioned above;

[0236] If the node identifier of the block-producing node matches the node identifier of the master node, then the steps described above are executed: obtaining the block header information and the target digital signature from the block proposal information, performing digest calculation on the block header information, and obtaining the first digest information of the block header information.

[0237] Optionally, the processor 601 described above is also used for:

[0238] When the comparison result between the standard Merkle root and the target Merkle root is not a match, the encrypted block proposal information sent by the block-producing node is received. The encrypted block proposal information is obtained by the block-producing node verifying the transaction data in the target block included in the block proposal information when the number of consensus nodes returning the feedback information meets the message retransmission condition, and encrypting the block proposal information using the node public key of the consensus node in the blockchain network when the verification result is successful.

[0239] The encrypted block proposal information is decrypted using the private key corresponding to the public key of the aforementioned node, resulting in the decrypted block proposal information.

[0240] The data included in the decrypted block proposal information is verified, and the operation is performed on the target block based on the verification result.

[0241] Optionally, when the processor 601 performs digest calculation on the block header information to obtain the first digest information of the block header information, it is specifically used for:

[0242] The above block header information is serialized to obtain serialized data;

[0243] The serialized data is digested to obtain the first digest information of the block header information.

[0244] In a feasible embodiment, the data processing device can be applied to the second embodiment described above, wherein the processor 601 executes the program instructions as follows:

[0245] Create a target block, which includes block header information and block body information. The block body information includes transaction data, and the block header information includes a standard Merkle root determined based on the transaction data.

[0246] The above block header information is digitally signed to obtain the target digital signature, and block proposal information is generated based on the target block and the target digital signature.

[0247] The aforementioned block proposal information is sent to the consensus nodes in the blockchain network so that the consensus nodes in the blockchain network can verify the data included in the aforementioned block proposal information and perform operations on the aforementioned target block based on the verification results.

[0248] Optionally, the processor 601 described above is also used for:

[0249] The system receives feedback information returned by consensus nodes in the aforementioned blockchain network. This feedback information indicates that the transaction data in the aforementioned target block has been tampered with. If the number of consensus nodes returning the aforementioned feedback information meets the message retransmission condition, the system verifies the transaction data in the aforementioned target block included in the aforementioned block proposal information.

[0250] If the verification result is successful, the public key of the consensus node in the above blockchain network is used to encrypt the above block proposal information to obtain encrypted block proposal information.

[0251] The aforementioned encrypted block proposal information is sent to the consensus nodes in the aforementioned blockchain network.

[0252] Optionally, the aforementioned feedback information is sent by the consensus node when it detects a mismatch between the standard Merkle root and the target Merkle root included in the block proposal message; the target Merkle root is determined by the consensus node based on the transaction data in the block proposal information when it detects a mismatch between the first digest information and the second digest information of the block header information; the first digest information is obtained by the consensus node performing a digest calculation on the block header information in the block proposal information, and the first digest information is obtained by the consensus node performing designing processing on the target digital signature in the block proposal information.

[0253] Optionally, when the processor 601 performs digital signature processing on the block header information to obtain the target digital signature, it is specifically used for:

[0254] The above block header information is serialized to obtain serialized data;

[0255] The above serialized data is digested to obtain the second digest information of the block header information;

[0256] The second digest information is encrypted using the signature private key to obtain the target digital signature.

[0257] In specific implementations, the processor 601, storage device 602, and network interface 603 described in the embodiments of this application can execute the embodiments of this application. Figure 2 or Figure 4 The implementation methods described in the relevant embodiments of the provided data processing method can also be used to execute the embodiments of this application. Figure 5 The implementation methods described in the relevant embodiments of the provided data processing device will not be repeated here.

[0258] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0259] This application also provides a computer-readable storage medium storing program instructions, which, when executed, may include, for example... Figure 2 or Figure 4 Some or all of the steps of the blockchain-based data processing method in the corresponding embodiments.

[0260] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0261] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0262] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. The server's processor reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the server to perform the steps described in the embodiments of the above methods.

[0263] The foregoing has provided a detailed description of a blockchain-based data processing method, apparatus, device, and medium. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data processing method based on blockchain, characterized in that, The method includes: Receive block proposal information sent by the block-producing node; wherein, the block proposal information includes a target block and a target digital signature, the target block includes block header information and block body information, the target digital signature is obtained by digitally signing the block header information, and the block header information includes a standard Merkle root determined based on the transaction data in the block body information; Obtain the block header information and the target digital signature from the block proposal information, perform digest calculation on the block header information to obtain the first digest information of the block header information, and perform designing processing on the target digital signature to obtain the second digest information of the block header information; If the first digest information matches the second digest information, then the standard Merkel root and the transaction data are obtained from the block proposal information, and the target Merkel root is determined based on the transaction data; Based on the comparison results between the standard Merkle root and the target Merkle root, the operation is performed on the target block; When the comparison result between the standard Merkle root and the target Merkle root is mismatched, the block-producing node sends encrypted block proposal information. The encrypted block proposal information is obtained by the block-producing node verifying the transaction data in the target block included in the block proposal information when the number of consensus nodes returning feedback information meets the message retransmission condition, and encrypting the block proposal information using the node public key of the consensus nodes in the blockchain network when the verification result is successful. The feedback information is used to indicate that the transaction data in the target block has been tampered with. The encrypted block proposal information is decrypted using the private key corresponding to the node's public key to obtain the decrypted block proposal information; the data included in the decrypted block proposal information is verified, and the operation is performed on the target block based on the verification result.

2. The method according to claim 1, characterized in that, The step of performing operations on the target block based on the comparison results of the standard Merkle root and the target Merkle root includes: If the comparison result between the standard Merkle root and the target Merkle root is a match, then consensus processing is performed on the target block; If the comparison result between the standard Merkle root and the target Merkle root is not a match, the target block is rejected for processing, and the feedback information is sent to the block-producing node.

3. The method according to claim 1, characterized in that, The block proposal information also includes the node identifier of the block-producing node, and the method further includes: Obtain the node identifier of the master node responsible for producing blocks at the current stage, and obtain the node identifier of the producing node from the block proposal information; If the node identifier of the block-producing node matches the node identifier of the master node, then the steps of obtaining the block header information and the target digital signature from the block proposal information, performing digest calculation on the block header information, and obtaining the first digest information of the block header information are executed.

4. The method according to any one of claims 1 to 3, characterized in that, The step of performing digest calculation on the block header information to obtain the first digest information of the block header information includes: The block header information is serialized to obtain serialized data; The serialized data is digested to obtain the first digest information of the block header information.

5. A data processing method based on blockchain, characterized in that, The method includes: Create a target block, the target block including block header information and block body information, the block body information including transaction data, and the block header information including a standard Merkle root determined based on the transaction data; The block header information is digitally signed to obtain a target digital signature, and block proposal information is generated based on the target block and the target digital signature. The block proposal information is sent to the consensus nodes in the blockchain network so that the consensus nodes in the blockchain network can verify the data included in the block proposal information and perform operations on the target block according to the verification results. The system receives feedback information returned by consensus nodes in the blockchain network, which indicates that the transaction data in the target block has been tampered with. If the number of consensus nodes returning the feedback information meets the message retransmission condition, the system verifies the transaction data in the target block included in the block proposal information. If the verification result is successful, the block proposal information is encrypted using the public key of the consensus node in the blockchain network to obtain encrypted block proposal information. The encrypted block proposal information is sent to the consensus nodes in the blockchain network, so that the consensus nodes in the blockchain network can decrypt the encrypted block proposal information using the private key corresponding to the node's public key, verify the data included in the decrypted block proposal information, and perform operations on the target block based on the verification results. The feedback information is sent by the consensus node when it detects a mismatch between the standard Merkle root and the target Merkle root included in the block proposal message; the target Merkle root is determined by the consensus node based on the transaction data in the block proposal information when it detects a mismatch between the first digest information and the second digest information of the block header information; the first digest information is obtained by the consensus node performing a digest calculation on the block header information in the block proposal information, and the first digest information is obtained by the consensus node performing designing processing on the target digital signature in the block proposal information.

6. The method according to claim 5, characterized in that, The step of digitally signing the block header information to obtain the target digital signature includes: The block header information is serialized to obtain serialized data; The serialized data is digested to obtain the second digest information of the block header information; The second digest information is encrypted using the signature private key to obtain the target digital signature.

7. A data processing device based on blockchain, characterized in that, It includes a module for implementing the blockchain-based data processing method as described in any one of claims 1 to 4, or it includes a module for implementing the blockchain-based data processing method as described in any one of claims 5 to 6.

8. A data processing device, characterized in that, The system includes a processor, a memory, and a network interface, which are interconnected. The memory stores a computer program, which includes program instructions. The processor is configured to invoke the program instructions to implement the blockchain-based data processing method as described in any one of claims 1 to 4, or to implement the blockchain-based data processing method as described in any one of claims 5 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions, which, when executed by a processor, cause a computer device having the processor to implement the blockchain-based data processing method as described in any one of claims 1 to 4, or to implement the blockchain-based data processing method as described in any one of claims 5 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the blockchain-based data processing method as described in any one of claims 1 to 4, or implement the blockchain-based data processing method as described in any one of claims 5 to 6.

Images