Blockchain-based intelligent engineering network transaction data management system

Abstract

The application discloses a blockchain-based intelligent engineering network transaction data management system and relates to the technical field of blockchain technology application.The system comprises the following modules: a data processing module, which acquires original transaction data and processes the original transaction data to generate standard transaction data packets; an index construction module, which processes the standard transaction data packets based on an improved Merkle Patricia tree algorithm and constructs a data index structure containing state mapping relationships; a block generation module, which verifies and encapsulates the data index structure by using a preset consensus mechanism and generates transaction data blocks; a network consensus module, which broadcasts the transaction data blocks to blockchain network nodes to trigger synchronous verification; and a ledger storage module, which, after consensus is reached, stores the transaction data blocks persistently in a distributed ledger and updates the global state.The system realizes efficient, safe and traceable management of intelligent engineering network transaction data and improves the state retrieval speed and system processing efficiency.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology application technology, specifically a blockchain-based intelligent engineering network transaction data management system. Background Technology

[0002] In the field of intelligent engineering, networked transactions involving multiple stakeholders, including design, construction, and material procurement, are becoming increasingly frequent. The resulting transaction data is characterized by complex structure, strong correlation, and high security requirements. Currently, such data is largely managed through centralized platforms. Centralized storage carries the risk of data tampering and loss, and data silos are prominent among participating parties, leading to cumbersome reconciliation and auditing processes with low transparency. While conventional blockchain technology can achieve data immutability and traceability, its native data index structure suffers from low efficiency in status queries and insufficient ability to express complex business relationships when facing application scenarios with frequent changes in engineering transaction status and diverse attributes. Furthermore, the consensus mechanism of general blockchains often becomes a bottleneck in terms of block confirmation speed and system throughput when dealing with the high-concurrency transaction processing needs of intelligent engineering networks, failing to meet the requirements of real-time data synchronization and business continuity for engineering collaboration. Therefore, how to construct a dedicated data management system that inherits the security and trustworthiness characteristics of blockchain while efficiently handling the complex status indexing and rapid consensus of intelligent engineering transactions is a current practical problem. Summary of the Invention

[0003] This invention aims to solve at least one of the technical problems existing in the prior art;

[0004] To this end, the present invention proposes a blockchain-based intelligent engineering network transaction data management system, comprising:

[0005] The data processing module is used to acquire raw transaction data in the intelligent engineering network, perform format parsing and information verification on the raw transaction data, and generate standard transaction data packets;

[0006] The index building module, based on the improved Merkel-Patricia tree algorithm, processes the standard transaction data packet to construct a data index structure containing state mapping relationships;

[0007] The block generation module is used to verify and encapsulate the data index structure using a preset consensus mechanism to generate transaction data blocks to be stored.

[0008] The network consensus module is used to broadcast the transaction data block to the blockchain network nodes, triggering the synchronous verification process of the network nodes;

[0009] The ledger storage module is used to persistently store the verified transaction data blocks in the distributed ledger after reaching network consensus, and to update the global network state.

[0010] Furthermore, the original transaction data is parsed and validated to generate a standard transaction data packet, including:

[0011] Extract the transaction entity identifier, transaction object description, transaction value, transaction timestamp, and digital signature information from the original transaction data;

[0012] The transaction entity identifier, transaction object description, transaction value, and transaction timestamp are compared one by one with the preset intelligent engineering network transaction data standard format template. Missing fields are marked, and fields with inconsistent formats are standardized and converted to form preliminary and organized transaction information.

[0013] The digital signature information and the pre-formulated transaction information are verified using a preset signature verification algorithm to confirm the reliability of the transaction source and the integrity of the information during transmission.

[0014] All the verified preliminary transaction information, along with their corresponding valid digital signature information, are packaged into a standard transaction data packet with a unified encapsulation format.

[0015] Furthermore, based on the improved Merkel-Patricia tree algorithm, the standard transaction data packet is processed to construct a data index structure containing state mapping relationships, including:

[0016] Extract key feature information from the standard transaction data packet, and generate a unique hash identifier for the transaction data based on the key feature information;

[0017] The underlying storage nodes of the improved Merkel-Patricia tree algorithm are initialized using the unique hash identifier as the leaf node key and the standard transaction data packet as the leaf node value.

[0018] The improved Merkel-Patricia tree algorithm is executed to construct the path by recursively calculating the hash of intermediate nodes from the bottom storage node upwards, forming a verification path connecting the leaf node and the root node.

[0019] During the construction process, the state information of all active transactions is synchronously mapped to the middle node of the tree to form a tree index for quickly locating and proving the existence and state of any transaction, namely the data index structure. Its root hash value serves as the unique cryptographic commitment to the state of this batch of transaction data.

[0020] Furthermore, the working principle of the improved Merkel-Patricia tree algorithm includes:

[0021] Based on the node structure of the standard Merkel-Patricia tree, each node is extended with a state version identifier field and a compressed proximity summary field.

[0022] When inserting or updating transaction data, the algorithm not only updates the corresponding leaf nodes according to the key-value path, but also updates the status version identifier field level by level along the path from the leaf node to the root node to identify the version change of the node data.

[0023] During the step-by-step update process, the algorithm synchronously calculates and updates the compressed proximity summary field, which is used to encode the local topological relationship of the currently processed node at a specific depth in the tree;

[0024] When performing state queries or existence proofs, the algorithm provides not only standard Merkel path nodes, but also state version identifier fields for relevant nodes on the path and compressed proximity summary fields, enabling the verifier to verify the consistency of the transaction state's position in the tree while verifying the transaction's existence.

[0025] Furthermore, the step of using a preset consensus mechanism to verify and encapsulate the data index structure to generate transaction data blocks to be stored includes:

[0026] A specific node in the blockchain network is selected as a proposer node, and the proposer node collects the data index structure and its corresponding original standard transaction data packets over a period of time;

[0027] The proposer node verifies and calculates the root hash of all the collected data index structures to ensure the consistency of its internal data.

[0028] The multiple verified data index structures and their associated original standard transaction data packets, along with the identity information of the proposer node and the current timestamp, are combined into a block body.

[0029] A hash operation is performed on the block body to generate a block body hash, and the block header hash of the previous transaction data block, the block body hash, and other block metadata are packaged together to generate the block header of the new block;

[0030] The block header and the block body are combined to form a complete block of transaction data to be stored.

[0031] Furthermore, the transaction data block is broadcast to the blockchain network nodes, triggering a synchronous verification process on the network nodes, including:

[0032] The proposer node will broadcast the generated block of transaction data to be stored to all known blockchain network nodes via a peer-to-peer network protocol;

[0033] Each blockchain network node that receives the transaction data block to be stored independently executes the block verification process, which includes: verifying the correctness of the block header hash, verifying the consistency between the block body hash and the record in the block header, verifying the accuracy of the root hash calculation of the data index structure, and verifying the digital signatures of all standard transaction data packets in the block.

[0034] After completing independent verification, each blockchain network node broadcasts its verification results again in the peer-to-peer network in the form of a voting message.

[0035] Other blockchain network nodes in the network collect and count voting messages from each blockchain network node, and determine whether to reach a consensus on the transaction data block to be stored based on the preset consensus rules.

[0036] Furthermore, the step of determining whether consensus has been reached on the transaction data block to be stored based on preset consensus rules includes:

[0037] Set a network verification threshold, which is related to the total number of currently online valid blockchain network nodes;

[0038] The number of blockchain network nodes that cast valid votes in favor of the transaction data block to be stored is counted.

[0039] The number of blockchain network nodes that cast valid affirmative votes is compared with the network verification pass threshold.

[0040] When the number of blockchain network nodes that cast valid votes in favor reaches or exceeds the network verification threshold, it is determined that the network has reached a consensus on the transaction data block to be stored, and the state of the transaction data block to be stored is changed to a verified transaction data block.

[0041] When the number of blockchain network nodes that cast valid votes in favor does not reach the network verification threshold, it is determined that network consensus has not been reached, and the transaction data block to be stored is marked as invalid.

[0042] Furthermore, after reaching network consensus, the step of persistently storing the verified transaction data blocks in the distributed ledger and updating the global network state includes:

[0043] After a network consensus is reached, each blockchain network node appends the verified transaction data block to its local blockchain data structure, which consists of transaction data blocks linked in chronological order.

[0044] While writing the verified transaction data block, the blockchain network nodes extract all standard transaction data packets from the block body of the verified transaction data block.

[0045] The extracted standard transaction data packet is stored in a local key-value pair state database, where the stored key is the unique identifier of the standard transaction data packet and the stored value is the complete content of the standard transaction data packet;

[0046] Based on the transaction execution results recorded in the verified transaction data blocks, the local global state tree is updated. The global state tree reflects the latest state of all smart engineering network transaction accounts and contracts on the current blockchain network.

[0047] Furthermore, the extracted standard transaction data packets are stored in a local key-value pair state database, including:

[0048] Generate a globally unique storage identifier for each of the standard transaction data packets within the distributed network;

[0049] Establish a mapping entry between the globally unique storage identifier and the complete content of the standard transaction data packet;

[0050] The mapping entries are written to the storage file of the local key-value pair state database in the form of key-value pairs, wherein the globally unique storage identifier is used as the key and the byte stream of the complete content serialized from the standard transaction data packet is used as the value.

[0051] After the write operation is completed, an index update operation is performed on the storage file to ensure that the complete content of the corresponding standard transaction data packet can be efficiently retrieved through the globally unique storage identifier.

[0052] Further, based on the transaction execution results recorded in the verified transaction data block, the local global state tree is updated, including:

[0053] Parse the verified transaction data block to obtain the transaction execution result, which includes a list of account addresses affected by the transaction and the updated status data of each account address;

[0054] Locate the root node of the current version of the global state tree in local storage;

[0055] Starting from the root node of the global state tree, based on the address information in the account address list, traverse the global state tree to locate each account state node that needs to be updated.

[0056] Replace the original data content of the corresponding account status node in the global status tree with the updated status data of each account address;

[0057] Starting from the updated leaf node, the hash value of its parent node is recalculated level by level from bottom to top until the new root node hash of the global state tree is recalculated, thus completing the update of the global state tree.

[0058] Compared with the prior art, the beneficial effects of the present invention are:

[0059] To address the complex structure and frequent state changes of intelligent engineering transaction data, an improved Merkle-Patricia tree algorithm is employed to construct the data index structure. This algorithm, based on the traditional Merkle-Patricia tree, optimizes node encoding and path organization for the multi-dimensional attributes of engineering transactions, directly embedding the mapping relationships between transaction states into the tree structure. This design enables rapid location and verification of all transaction states associated with specific project stages, participants, or contract terms, while maintaining the inherent cryptographic integrity guarantees of the Merkle tree. The index structure itself supports efficient tracing of state history and complex conditional queries, changing the conventional blockchain approach of traversing numerous blocks or relying on additional databases for relational queries, significantly improving state retrieval efficiency and system responsiveness in business scenarios.

[0060] To address the high demands for timeliness and finality of transaction data in engineering collaboration, a pre-defined consensus mechanism was designed and implemented. This mechanism, based on classic consensus algorithms, introduces verification rules and priority strategies related to engineering transaction logic, optimizing the transaction packaging and verification process. By incorporating engineering attributes such as transaction type and participant credit into the consensus weighting, the consensus process can reach agreement on key transactions more quickly. The mechanism optimizes network communication and state confirmation steps, reducing unnecessary duplicate verifications and achieving faster block generation and lower transaction confirmation latency in a decentralized environment. This enables nodes in the engineering network to synchronize and maintain a consistent transaction ledger state in near real-time, supporting high-frequency engineering transaction processing and coherent business operations, overcoming the limitations of general consensus mechanisms in specific domain applications, such as insufficient throughput and high latency. Attached Figure Description

[0061] Figure 1 This is a flowchart illustrating the steps of the blockchain-based intelligent engineering network transaction data management system described in this invention.

[0062] Figure 2 Workflow diagram for constructing a data index structure based on the improved Merkel-Patricia tree algorithm;

[0063] Figure 3 A flowchart illustrating the workflow for verifying the data index structure and encapsulating blocks to generate transaction data blocks to be stored. Detailed Implementation

[0064] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0065] See Figure 1 This invention provides a blockchain-based intelligent engineering network transaction data management system, specifically comprising:

[0066] The data processing module is responsible for acquiring raw transaction data from the intelligent engineering network, performing format parsing and information verification on this raw transaction data, and generating standard transaction data packets that conform to the specifications. The index construction module, based on an improved Merkle-Patricia tree algorithm, processes the generated standard transaction data packets to construct an efficient data index structure that can contain state mapping relationships. The block generation module uses a preset consensus mechanism to verify the constructed data index structure and perform block encapsulation operations, thereby generating transaction data blocks to be stored. The network consensus module is responsible for broadcasting the transaction data blocks to be stored to all nodes in the entire blockchain network, triggering a synchronous verification process for all network nodes. After network consensus is reached, the ledger storage module persistently stores the verified transaction data blocks in the distributed ledger and updates the global state of the network accordingly, thus completing a full round of transaction data on-chaining and management.

[0067] In one embodiment of the present invention, the data processing module acquires raw transaction data from the intelligent engineering network, performs format parsing and information verification on the raw transaction data, and generates a standard transaction data packet. In practice, the module extracts the transaction subject identifier, transaction object description, transaction value, transaction timestamp, and digital signature information from the raw transaction data. The extracted transaction subject identifier, transaction object description, transaction value, and transaction timestamp are compared one by one with a preset standard format template for intelligent engineering network transaction data. Missing fields are marked, and fields with inconsistent formats are standardized to form preliminary, organized transaction information. A preset signature verification algorithm verifies the digital signature information against the preliminary organized transaction information to confirm the reliability of the transaction source and the integrity of the information during transmission. All the verified preliminary organized transaction information, along with their corresponding valid digital signature information, are packaged according to a unified encapsulation format to generate a standard transaction data packet.

[0068] In practical implementation, the raw transaction data acquired by the data processing module originates from specific business interactions within the intelligent engineering network, such as an electronic transaction document recording the purchase of building materials. The raw transaction data may contain fields and codes with varying structures. The data processing module performs format parsing and information verification on the raw transaction data to generate a standard transaction data package. The format parsing operation extracts the transaction entity identifier, transaction object description, transaction value, transaction timestamp, and digital signature information from the raw transaction data. The transaction entity identifier can be a coded contractor's unified social credit code; the transaction object description can be a combination of material name, specifications, and quantity; the transaction value is expressed as a numerical value denominated in a specific currency unit; the transaction timestamp conforms to the RFC3339 standard; and the digital signature information is a piece of ciphertext data generated based on an asymmetric encryption algorithm.

[0069] In practice, the extracted transaction entity identifier, transaction object description, transaction value, and transaction timestamp are compared one by one with a pre-defined standard format template for intelligent engineering network transaction data. The standard format template defines the allowed data types, length ranges, and value domains for each field. Missing fields are marked; for example, if the original transaction data lacks a "transaction batch number" field, the marker "FIELD_MISSING" is inserted at the corresponding position. Fields with inconsistent formats are standardized and converted to form preliminary, well-organized transaction information. For example, the transaction timestamp in the original transaction data is "2023-12-25 15:30," which, after conversion, forms a format conforming to the ISO 8601 standard: "2023-12-25T15:30:00Z."

[0070] In practical implementation, a preset signature verification algorithm is used to verify the digital signature information against the initially structured transaction information. This verification algorithm can be based on an elliptic curve digital signature algorithm. The digital signature information is the result of the signer encrypting a digest of the initially structured transaction information using their private key. During verification, the corresponding public key is used to decrypt the digital signature information to obtain digest one. Simultaneously, the same hash function is used to calculate digest two from the received initially structured transaction information. Digest one and digest two are then compared to confirm the reliability of the transaction source and the integrity of the information during transmission. (Signature Verification) The process can be described by the formula:

[0071]

[0072] in: Represents digital signature information. This represents initially organized transaction information. The function output represents the public key paired with the signing private key. or This indicates whether the verification passed or failed.

[0073] In practice, all verified and pre-organized transaction information, along with their corresponding valid digital signature information, is packaged into a standard transaction data packet with a unified encapsulation format. The unified encapsulation format includes a fixed-length header, sequentially arranged field data areas, a digital signature appendix area, and a checksum at the end of the packet. The packaging operation concatenates the organized values ​​of four fields—transaction subject identifier, transaction object description, transaction value, and transaction timestamp—in a preset order, and calculates their hash value as the content index of the data packet. Subsequently, the content index, the concatenated organized values, the digital signature information, and the checksum at the end of the packet are serialized into a byte stream to form the final standard transaction data packet.

[0074] In one embodiment of the present invention, the index building module processes standard transaction data packets based on an improved Merkel-Patricia tree algorithm to construct a data index structure containing state mapping relationships. For implementation, see [reference needed]. Figure 2 The improved Merkel-Patricia tree algorithm extracts key feature information from standard transaction data packets and generates unique hash identifiers for the transaction data based on this information. Using these unique hash identifiers as leaf node keys and the corresponding standard transaction data packets as leaf node values, the underlying storage nodes of the improved Merkel-Patricia tree algorithm are initialized. The path construction logic of the improved Merkel-Patricia tree algorithm is then executed, recursively calculating the hash values ​​of intermediate nodes from the underlying storage nodes upwards to form a verification path connecting the leaf nodes and the root node. During the construction process, the state information of all currently active transactions is synchronously mapped to the intermediate nodes of the tree, forming a tree index capable of quickly locating and proving the existence and state of any transaction. This tree index is the data index structure, and its root hash value serves as the unique cryptographic commitment to the state of this batch of transaction data. This improved Merkel-Patricia tree algorithm, based on the node structure of the standard Merkel-Patricia tree, extends the storage of a state version identifier field and a compressed proximity summary field for each node. When inserting or updating transaction data, the algorithm not only updates the corresponding leaf nodes based on the key-value path, but also updates the state version identifier field of each node traversed along the path from the leaf node to the root node. This field is used to identify the version change of the node data. During the step-by-step update process, the algorithm synchronously calculates and updates the compressed proximity summary field of each traversed node. This proximity summary field is used to encode the local topological relationship of the currently processed node at a specific depth in the tree. When performing state queries or existence proofs, in addition to providing standard Merkel path nodes, the algorithm also provides the state version identifier field and compressed proximity summary field of the relevant nodes on the path. The verifier can verify the consistency of the transaction state's position in the tree while verifying the existence of the transaction.

[0075] In specific implementations, the index construction module processes standard transaction data packets based on an improved Merkel-Patricia tree algorithm to construct a data index structure containing state mapping relationships. Specifically, it extracts key feature information from the standard transaction data packets, including a combination of the transaction's unique sequence number and a nanosecond timestamp of the transaction creation time. Based on this key feature information, a unique hash identifier for the transaction data is generated using the SHA-256 hash function. Using the generated unique hash identifier as the leaf node key and the serialized byte stream of the complete standard transaction data packet as the leaf node value, the underlying storage nodes of the improved Merkel-Patricia tree algorithm are initialized. In some embodiments, the initialization operation creates a key-value pair mapping in memory and stores this mapping relationship in a temporary database. In specific implementations, the path construction logic of the improved Merkel-Patricia tree algorithm is executed, recursively calculating the hashes of intermediate nodes from the underlying storage nodes upwards to form a verification path connecting the leaf nodes and the root node. During recursive computation, the hash values ​​of two child nodes belonging to the same parent node are concatenated with the additional information stored in the parent node itself. The concatenated data is then hashed, and the result is used as the new hash value for the parent node. This process is described by the formula:

[0076]

[0077] in: Represents the hash value of the parent node. Represents a hash function. Represents the hash value of the left child node. Represents the hash value of the right child node. The value of the field representing the status version identifier of the parent node. The value of the compressed proximity summary field representing the parent node, symbol. This represents a byte concatenation operation. In practice, during the construction process, the state information of all currently active transactions is synchronously mapped to the intermediate nodes of the tree. The state information can include the hash representation of the transaction status code, forming a tree index for quickly locating and proving the existence and state of any transaction. This tree index is the data index structure, and its root hash value serves as the unique cryptographic commitment to the state of this batch of transaction data.

[0078] In its implementation, the improved Merkle-Patricia tree algorithm works by extending the standard Merkle-Patricia tree node structure by storing a state version identifier field and a compressed neighbor summary field for each node. The state version identifier field is a monotonically increasing integer value, and the compressed neighbor summary field is a fixed-length digest obtained by bitwise operations on the child node pointer addresses. In some embodiments, when inserting or updating transaction data, the algorithm not only updates the corresponding leaf nodes according to the key-value path but also updates the state version identifier field level by level along the path from the leaf node to the root node. Each update increments the value of the state version identifier field, which is used to identify version changes in node data. During the level-by-level update process, the algorithm synchronously calculates and updates the compressed neighbor summary field. The update operation involves collecting the hash prefixes of all directly adjacent nodes at a specific depth in the tree for the currently processed node, performing an XOR operation on these prefixes, and storing the result as the compressed neighbor summary field. The compressed neighbor summary field is used to encode the local topological relationships of the currently processed node at a specific depth in the tree. When performing state queries or existence proofs, the algorithm provides not only standard Merkle path nodes but also state version identifier fields and compressed proximity summary fields for related nodes on the path. This allows the verifier to verify the consistency of the transaction state's position in the tree while simultaneously verifying the transaction's existence. Optionally, the calculation of the compressed proximity summary field may include the existence flag of sibling nodes. In practice, consistency verification is accomplished by comparing whether the compressed proximity summary fields of adjacent nodes on the provided path can be mutually derived.

[0079] In one embodiment of the present invention, the block generation module utilizes a preset consensus mechanism to verify the data index structure and encapsulate blocks, generating transaction data blocks to be stored. For implementation, refer to... Figure 3 A specific node is selected from the blockchain network as a proposer node. This proposer node collects data index structures and their corresponding raw standard transaction data packets generated within a certain period. The proposer node verifies and calculates the root hash of all collected data index structures to ensure the consistency of its internal data. Multiple verified data index structures and their associated raw standard transaction data packets, along with the proposer node's identity information and current timestamp, are combined into a block body. A hash operation is performed on the block body to generate a block body hash. The block header hash of the previous transaction data block, the newly calculated block body hash, and other block metadata are packaged together to generate the block header of the new block. The generated block header is combined with the block body to form a complete transaction data block to be stored.

[0080] In implementation, the block generation module utilizes a pre-defined consensus mechanism to verify and encapsulate the data index structure, generating transaction data blocks to be stored. This pre-defined consensus mechanism can be based on proof-of-stake. Specifically, a particular node in the blockchain network is selected as the proposer node. The selection criteria can be a combination of the node's stake and a random number calculation. The proposer node collects data index structures and their corresponding original standard transaction data packets over a pre-configured fixed time window, such as 10 seconds. The proposer node verifies the root hash of all collected data index structures to ensure internal data consistency. This verification calculation includes recalculating the root hash of each data index structure and comparing it with the declared root hash value within the data index structure.

[0081] In practice, multiple verified data index structures and their associated original standard transaction data packets, along with the proposer node's identity information and current timestamp, are combined into a block body. The block body is a structured data collection; its organization is shown in Table 1.

[0082] Table 1: Block Data Structure Table

[0083] ProposerID String Unique identifier of proposer node Timestamp Plastic Surgery UNIX timestamp when block assembly is complete IndexStructureCount Plastic Surgery Number of data index structures included IndexStructures array A list consisting of multiple data index structure objects TransactionDataPackets array List of original standard transaction data packets corresponding to the above index structure

[0084] In practice, a hash operation is performed on the block body to generate a block body hash. The hash operation uses the SHA-256 algorithm, and the calculation process can be represented as follows:

[0085]

[0086] in: Represents the generated block body hash value, Represents the SHA-256 hash function. This represents the serialization operation on the data structure. This represents the block body data structure composed of proposer nodes. In specific implementations, the block header hash of the previous transaction data block, the calculated block body hash, and other block metadata are packaged to generate the block header of the new block. The block metadata includes the version number of the current block, the difficulty target value, and a random number. In some embodiments, the other block metadata may also include a field pointing to the root hash of the relevant smart contract state. It can be understood that the block header hash is a cryptographic commitment to all data in the previous block. In specific implementations, the generated block header is combined with the block body to form a complete transaction data block to be stored. The combination is achieved by sequentially concatenating the block header data structure and the block body data structure, and calculating the hash of the entire concatenated data as the identifier of the current block. Optionally, after forming a complete transaction data block to be stored, a short digital signature can be attached to the block. This signature is generated by the proposer node using its private key to sign the block identifier. In some embodiments, the verification calculation of the data index structure also includes verifying whether the number of transactions contained in each data index structure is within the threshold range allowed by the system. Optionally, when combining block bodies, the identity information of the proposer node can be an encrypted certificate digest.

[0087] In one embodiment of the present invention, the network consensus module broadcasts the transaction data block to the blockchain network nodes, triggering a synchronous verification process by the network nodes. In practice, the proposer node broadcasts the generated transaction data block to be stored to all known blockchain network nodes via a peer-to-peer network protocol. Each blockchain network node receiving the transaction data block to be stored independently executes a block verification process, which includes verifying the correctness of the block header hash, verifying the consistency between the block body hash and the record in the block header, verifying the accuracy of the root hash calculation of the data index structure, and verifying the digital signatures of all standard transaction data packets within the block. After completing independent verification, the blockchain network nodes broadcast their respective verification results again in the peer-to-peer network in the form of voting messages. Other blockchain network nodes in the network collect and count the voting messages from each blockchain network node, and determine whether to reach a consensus on the transaction data block to be stored based on preset consensus rules. The implementation of the consensus rules involves setting a network validation threshold associated with the total number of currently active online blockchain network nodes, counting the number of blockchain network nodes that cast valid votes in favor of a transaction block to be stored, and comparing this number with the network validation threshold. When the number of blockchain network nodes casting valid votes reaches or exceeds the network validation threshold, the network is deemed to have reached a consensus on the transaction block to be stored, and the state of the transaction block to be stored changes to a validated transaction block. When the number of blockchain network nodes casting valid votes does not reach the network validation threshold, network consensus is deemed not to have been reached, and the transaction block to be stored is marked as invalid.

[0088] In practice, the network consensus module broadcasts transaction data blocks to blockchain network nodes, triggering a synchronization verification process. Specifically, the proposer node broadcasts the generated transaction data block to be stored to all known blockchain network nodes via a peer-to-peer network protocol. This peer-to-peer network protocol can be a custom application layer protocol based on TCP / IP. The broadcasting process involves the proposer node sending the serialized data of the transaction data block to be stored to its directly connected neighbor nodes, which then forward the data to their other neighbor nodes. Each blockchain network node that receives a block of transaction data to be stored independently executes a block verification process. The block verification process includes verifying the correctness of the block header hash, i.e., recalculating the hash value of the received block header data and comparing it with the block's own identifier; verifying the consistency between the block body hash and the record in the block header, i.e., recalculating the hash value of the received block body and comparing it with the block body hash field stored in the block header; verifying the accuracy of the root hash calculation of the data index structure, i.e., reconstructing the data index structure based on the original standard transaction data packets in the block body and comparing it with the root hash value; and verifying the digital signatures of all standard transaction data packets in the block, i.e., executing a signature verification algorithm on each standard transaction data packet.

[0089] In practice, after completing independent verification, each blockchain network node broadcasts its verification results again within the peer-to-peer network in the form of a voting message. The voting message includes the node identifier, the hash of the block being voted on, the voting opinion (for / against), and the node's signature on the block. Other blockchain network nodes collect and analyze the voting messages from each node, and determine whether consensus has been reached on the transaction data block to be stored based on pre-defined consensus rules. The implementation of these consensus rules includes setting a network verification pass threshold, which is related to the total number of currently online, valid blockchain network nodes. The calculation method can be expressed as follows:

[0090]

[0091] in: This represents the threshold for network verification to pass. This represents the total number of currently active blockchain network nodes. This represents the preset consensus pass rate (e.g., 0.67). This represents a rounding down operation. It counts the number of blockchain network nodes that cast valid votes in favor of the transaction data block to be stored. A valid vote is determined by the voting message having a correct digital signature and originating from a list of recognized nodes. In some embodiments, the data structure of the voting message is shown in Table 2.

[0092] Table 2: Node Voting Message Data Structure Table

[0093] VoterID String "Node_05" Unique identifier of voting node BlockHash String(64) "a1b2c3…" The hash value of the transaction data block to be stored that was voted on. Vote Boolean type true Voting options: true indicates approval, false indicates disapproval. Timestamp Plastic Surgery 1678886400 timestamps generated by the vote Signature String "0x9f8a…" Voting nodes use their private keys to sign the first four fields.

[0094] In practice, the number of blockchain network nodes that cast valid votes is compared with a network verification threshold. When the number of blockchain network nodes that cast valid votes reaches or exceeds the network verification threshold, the network is deemed to have reached a consensus on the transaction data block to be stored, and the state of the transaction data block to be stored changes to a verified transaction data block. In some embodiments, the state transition is accompanied by broadcasting a consensus announcement message in the network. When the number of blockchain network nodes that cast valid votes does not reach the network verification threshold, the network consensus is deemed not to have been reached, the transaction data block to be stored is marked as invalid, and the marked invalid block will not be appended to the blockchain. It is understood that the statistical process needs to be completed within a preset time window. Optionally, the consensus rules may also require votes to come from nodes in different physical locations to resist specific attacks. In practice, the node collecting voting messages maintains a local vote counter and ignores voting messages that arrive after the specified time window or are duplicated.

[0095] In one embodiment of the present invention, after reaching network consensus, the ledger storage module persistently stores the verified transaction data blocks in the distributed ledger and updates the global network state. In practice, after network consensus is reached, each blockchain network node appends the verified transaction data blocks to its local blockchain data structure, which consists of transaction data blocks linked in chronological order. Simultaneously with writing the verified transaction data blocks, the blockchain network nodes extract all standard transaction data packets from the block bodies of the verified transaction data blocks. The extracted standard transaction data packets are stored in a local key-value pair state database, where the stored key is a unique identifier for the standard transaction data packet, and the stored value is the complete content of the standard transaction data packet. Based on the transaction execution results recorded in the verified transaction data blocks, the local global state tree is updated. This global state tree reflects the latest state of all smart engineering network transaction accounts and contracts on the current blockchain network. The process of storing standard transaction data packets includes generating a globally unique storage identifier for each standard transaction data packet within the distributed network, establishing a mapping entry between the globally unique storage identifier and the complete content of the standard transaction data packet, writing this mapping entry into a local key-value pair state database storage file in the form of key-value pairs, where the globally unique storage identifier serves as the key and the serialized byte stream of the complete content of the standard transaction data packet serves as the value, and performing an index update operation on the storage file after the write operation is completed to ensure that the complete content of the corresponding standard transaction data packet can be efficiently retrieved through the globally unique storage identifier in the future. The process of updating the local global state tree includes parsing verified transaction data blocks to obtain transaction execution results. The transaction execution results contain a list of account addresses affected by the transaction and the updated state data of each account address. The root node of the current version of the global state tree stored locally is located. Starting from the root node of the global state tree, based on the address information in the account address list, each account state node that needs to be updated is traversed in the global state tree. The data content of the corresponding account state node in the global state tree is replaced with the updated state data of each account address. Starting from the updated leaf node from the bottom up, the hash value of its parent node is recalculated level by level until the new root node hash of the global state tree is recalculated, thus completing the update of the global state tree.

[0096] In practice, after reaching network consensus, the ledger storage module persistently stores the verified transaction data blocks in the distributed ledger and updates the global network state. The network consensus is reached via a specific message identifier broadcast by the network consensus module. Following network consensus, each blockchain network node appends the verified transaction data blocks to its local blockchain data structure. This local blockchain data structure consists of transaction data blocks linked in chronological order. The append operation involves appending the serialized byte data of the verified transaction data block to the end of the locally stored blockchain file and updating the hash pointer of the last block. Simultaneously with writing the verified transaction data blocks, the blockchain network nodes extract all standard transaction data packets from the block body. This extraction process involves parsing the serialized byte stream of the block body and locating the standard transaction data packet array field.

[0097] In specific implementation, the extracted standard transaction data packets are stored in a local key-value pair state database. The stored key is the unique identifier of the standard transaction data packet, and the stored value is the complete content of the standard transaction data packet. The storage process includes generating a globally unique storage identifier for each standard transaction data packet within the distributed network. This generation method can be achieved by calculating the hash value of the standard transaction data packet content, concatenating it with the generation timestamp, and then hashing it again. A mapping entry is established between the globally unique storage identifier and the complete content of the standard transaction data packet. The mapping entry is written to the storage file of the local key-value pair state database in the form of key-value pairs, where the globally unique storage identifier serves as the key, and the serialized byte stream of the complete content of the standard transaction data packet serves as the value. After the write operation is completed, an index update operation is performed on the storage file. The index update operation involves updating the B+ tree index structure within the key-value pair state database to ensure that the complete content of the corresponding standard transaction data packet can be efficiently retrieved using the globally unique storage identifier. In some embodiments, the key-value pair state database adopts a log-structured merged tree design. Optionally, the generation of the globally unique storage identifier can incorporate the network identifier of the creating node to prevent conflicts.

[0098] In practice, the local global state tree is updated based on the transaction execution results recorded in the verified transaction data blocks. The global state tree reflects the latest state of all smart engineering network transaction accounts and contracts on the current blockchain network. The update process begins by parsing the verified transaction data blocks to obtain the transaction execution results, which include a list of account addresses affected by the transaction and the updated state data for each account address. The root node of the current version of the global state tree is located locally; its position is recorded in a specific metadata file. Starting from the root node, each account state node requiring updating is located by traversing the global state tree based on the address information in the account address list. The traversal process uses the account address as the path, selecting branches at each level of the tree based on the hexadecimal characters of the address. The updated state data for each account address replaces the original data content of the corresponding account state node in the global state tree; this replacement operation is performed directly on the tree structure in memory. From bottom to top, starting from the updated leaf node, the hash value of its parent node is recalculated level by level until a new root node hash of the global state tree is recalculated, completing the update of the global state tree. The operation of recalculating the parent node's hash value can be represented as:

[0099]

[0100] in: This represents the calculated new hash value of the parent node. Represents a hash and state merging function. Represents the hash value of the left child node. Represents the hash value of the right child node. This represents the state data stored by the parent node itself. In some embodiments, the global state tree employs a modified Merkel-Patricia tree structure. It is understood that the process of recalculating hash values ​​ensures a cryptographic binding between the global state tree root hash and the transaction execution result. Optionally, a snapshot of the current tree structure is created before updating the global state tree. In a specific implementation, after the global state tree update is complete, the new root node hash value is written to the state root field in the block header, forming a closed loop. It is understood that after all nodes perform the same update operation, the network's global state reaches consensus.

[0101] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A blockchain-based intelligent engineering network transaction data management system, characterized in that, include: The data processing module is used to acquire raw transaction data in the intelligent engineering network, perform format parsing and information verification on the raw transaction data, and generate standard transaction data packets; The index building module, based on the improved Merkel-Patricia tree algorithm, processes the standard transaction data packet to construct a data index structure containing state mapping relationships; The block generation module is used to verify and encapsulate the data index structure using a preset consensus mechanism to generate transaction data blocks to be stored. The network consensus module is used to broadcast the transaction data block to the blockchain network nodes, triggering the synchronous verification process of the network nodes; The ledger storage module is used to persistently store the verified transaction data blocks in the distributed ledger after reaching network consensus, and to update the global network state. The improved Merkel-Patricia tree algorithm processes the standard transaction data packet to construct a data index structure containing state mapping relationships, including: Extract key feature information from the standard transaction data packet, and generate a unique hash identifier for the transaction data based on the key feature information; The underlying storage nodes of the improved Merkel-Patricia tree algorithm are initialized using the unique hash identifier as the leaf node key and the standard transaction data packet as the leaf node value. The improved Merkel-Patricia tree algorithm is executed to construct the path by recursively calculating the hash of intermediate nodes from the bottom storage node upwards, forming a verification path connecting the leaf node and the root node. During the construction process, the state information of all active transactions is synchronously mapped to the middle node of the tree to form a tree index for quickly locating and proving the existence and state of any transaction, namely the data index structure. Its root hash value serves as the unique cryptographic commitment to the state of this batch of transaction data.

2. The blockchain-based intelligent engineering network transaction data management system according to claim 1, characterized in that, The original transaction data is parsed and validated to generate a standard transaction data packet, including: Extract the transaction entity identifier, transaction object description, transaction value, transaction timestamp, and digital signature information from the original transaction data; The transaction entity identifier, transaction object description, transaction value, and transaction timestamp are compared one by one with the preset intelligent engineering network transaction data standard format template. Missing fields are marked, and fields with inconsistent formats are standardized and converted to form preliminary and organized transaction information. The digital signature information and the pre-formulated transaction information are verified using a preset signature verification algorithm to confirm the reliability of the transaction source and the integrity of the information during transmission. All the verified preliminary transaction information, along with their corresponding valid digital signature information, are packaged into a standard transaction data packet with a unified encapsulation format.

3. The blockchain-based intelligent engineering network transaction data management system according to claim 2, characterized in that, The working principle of the improved Merkel-Patricia tree algorithm includes: Based on the node structure of the standard Merkel-Patricia tree, each node is extended with a state version identifier field and a compressed proximity summary field. When inserting or updating transaction data, the algorithm not only updates the corresponding leaf nodes according to the key-value path, but also updates the status version identifier field level by level along the path from the leaf node to the root node to identify the version change of the node data. During the step-by-step update process, the algorithm synchronously calculates and updates the compressed proximity summary field, which is used to encode the local topological relationship of the currently processed node at a specific depth in the tree; When performing state queries or existence proofs, the algorithm provides not only standard Merkel path nodes, but also state version identifier fields for relevant nodes on the path and compressed proximity summary fields, enabling the verifier to verify the consistency of the transaction state's position in the tree while verifying the transaction's existence.

4. The blockchain-based intelligent engineering network transaction data management system according to claim 3, characterized in that, The process of using a preset consensus mechanism to verify and encapsulate the data index structure to generate transaction data blocks to be stored includes: A specific node in the blockchain network is selected as a proposer node, and the proposer node collects the data index structure and its corresponding original standard transaction data packets over a period of time; The proposer node verifies and calculates the root hash of all the collected data index structures to ensure the consistency of its internal data. The multiple verified data index structures and their associated original standard transaction data packets, along with the identity information of the proposer node and the current timestamp, are combined into a block body. A hash operation is performed on the block body to generate a block body hash, and the block header hash of the previous transaction data block, the block body hash, and other block metadata are packaged together to generate the block header of the new block; The block header and the block body are combined to form a complete block of transaction data to be stored.

5. The blockchain-based intelligent engineering network transaction data management system according to claim 4, characterized in that, Broadcasting the transaction data block to blockchain network nodes triggers the network nodes' synchronization verification process, including: The proposer node will broadcast the generated block of transaction data to be stored to all known blockchain network nodes via a peer-to-peer network protocol; Each blockchain network node that receives the transaction data block to be stored independently executes the block verification process, which includes: verifying the correctness of the block header hash, verifying the consistency between the block body hash and the record in the block header, verifying the accuracy of the root hash calculation of the data index structure, and verifying the digital signatures of all standard transaction data packets in the block. After completing independent verification, each blockchain network node broadcasts its verification results again in the peer-to-peer network in the form of a voting message. Other blockchain network nodes in the network collect and count voting messages from each blockchain network node, and determine whether to reach a consensus on the transaction data block to be stored based on the preset consensus rules.

6. The blockchain-based intelligent engineering network transaction data management system according to claim 5, characterized in that, The step of determining whether consensus has been reached on the transaction data block to be stored based on preset consensus rules includes: Set a network verification threshold, which is related to the total number of currently online valid blockchain network nodes; The number of blockchain network nodes that cast valid votes in favor of the transaction data block to be stored is counted. The number of blockchain network nodes that cast valid affirmative votes is compared with the network verification pass threshold. When the number of blockchain network nodes that cast valid votes in favor reaches or exceeds the network verification threshold, it is determined that the network has reached a consensus on the transaction data block to be stored, and the state of the transaction data block to be stored is changed to a verified transaction data block. When the number of blockchain network nodes that cast valid votes in favor does not reach the network verification threshold, it is determined that network consensus has not been reached, and the transaction data block to be stored is marked as invalid.

7. The blockchain-based intelligent engineering network transaction data management system according to claim 6, characterized in that, After reaching network consensus, the verified transaction data blocks are persistently stored in the distributed ledger, and the global network state is updated, including: After a network consensus is reached, each blockchain network node appends the verified transaction data block to its local blockchain data structure, which consists of transaction data blocks linked in chronological order. While writing the verified transaction data block, the blockchain network nodes extract all standard transaction data packets from the block body of the verified transaction data block. The extracted standard transaction data packet is stored in a local key-value pair state database, where the stored key is the unique identifier of the standard transaction data packet and the stored value is the complete content of the standard transaction data packet; Based on the transaction execution results recorded in the verified transaction data blocks, the local global state tree is updated. The global state tree reflects the latest state of all smart engineering network transaction accounts and contracts on the current blockchain network.

8. The blockchain-based intelligent engineering network transaction data management system according to claim 7, characterized in that, The extracted standard transaction data packets are stored in a local key-value pair state database, including: Generate a globally unique storage identifier for each of the standard transaction data packets within the distributed network; Establish a mapping entry between the globally unique storage identifier and the complete content of the standard transaction data packet; The mapping entries are written to the storage file of the local key-value pair state database in the form of key-value pairs, wherein the globally unique storage identifier is used as the key and the byte stream of the complete content serialized from the standard transaction data packet is used as the value. After the write operation is completed, an index update operation is performed on the storage file to ensure that the complete content of the corresponding standard transaction data packet can be efficiently retrieved through the globally unique storage identifier.

9. The blockchain-based intelligent engineering network transaction data management system according to claim 8, characterized in that, Based on the transaction execution results recorded in the verified transaction data block, update the local global state tree, including: Parse the verified transaction data block to obtain the transaction execution result, which includes a list of account addresses affected by the transaction and the updated status data of each account address; Locate the root node of the current version of the global state tree in local storage; Starting from the root node of the global state tree, based on the address information in the account address list, traverse the global state tree to locate each account state node that needs to be updated. Replace the original data content of the corresponding account status node in the global status tree with the updated status data of each account address; Starting from the updated leaf node, the hash value of its parent node is recalculated level by level from bottom to top until the new root node hash of the global state tree is recalculated, thus completing the update of the global state tree.

Images