A blockchain-driven cost data on-chain method

Abstract

The application belongs to the technical field of engineering cost data management, and relates to a blockchain-driven cost data chaining method. The initial version and each change version of the cost data are managed by constructing a dynamic version tree model, a traceable version evolution link is formed, the cost data is subjected to role-based fragmentation processing, each participant only digitally signs the fragmented data within the scope of his / her own rights and responsibilities, and the unified signature after aggregation is associated to the corresponding version node, so that the problem of fuzzy rights and responsibilities definition is solved. A double-chain architecture composed of a business chain and an audit chain is constructed, the version tree data and signature information are stored in the business chain, the version tree core verification information of the business chain is anchored to the audit chain at regular intervals to realize hierarchical evidence storage, the target version data and audit anchor information are called during auditing, and audit verification is completed by combining signature verification and data consistency verification. The accuracy, traceability and multi-party collaboration efficiency of the cost data are improved.

Description

Technical Field

[0001] This application belongs to the field of engineering cost data management technology, and more specifically, relates to a blockchain-driven method for putting cost data on the blockchain. Background Technology

[0002] Throughout the entire lifecycle of an engineering construction project, cost data (such as bill of quantities, unit prices, change orders, contract terms, etc.) is the core management object. Its accuracy, traceability, and multi-party collaboration efficiency directly affect project investment control and engineering quality. As the project progresses, cost data undergoes multiple changes and adjustments, involving multiple participating entities such as the construction party, contractor, and developer.

[0003] Traditional cost data management often relies on offline file transfers or centralized system storage, which suffers from technical problems such as chaotic version management, unclear definition of responsibilities, and inefficient auditing and verification; specifically as follows:

[0004] After multiple revisions to cost estimates, different versions are easily retained by various parties. Versions can only be distinguished by filename annotations or manual records, making it impossible to accurately trace the specific fields, operation time, and related approval processes of a particular change. When data disputes arise, it is difficult to quickly locate the original version and the change trajectory. Secondly, key cost data such as change orders require confirmation from multiple parties. In traditional methods, signatures from all parties are mostly for the entire document, which cannot achieve field-level binding of rights and responsibilities. If a certain item of data (such as material unit price or quantity of work) is incorrect, it is difficult to accurately trace the corresponding responsible party. Furthermore, during the audit process, multiple historical documents need to be collected manually for comparison to verify the rationality of changes and the integrity of data. This is not only time-consuming and laborious, but manual comparison is also prone to deviations in audit results due to missing documents or version confusion. Summary of the Invention

[0005] This invention provides a blockchain-driven method for uploading cost data to the blockchain, aiming to solve the technical problems of chaotic version management, unclear definition of rights and responsibilities, and inefficient auditing and verification in traditional cost data management.

[0006] A blockchain-driven method for uploading cost data to the blockchain includes the following steps:

[0007] Step 1: Construct a dynamic version tree model to manage the initial version and each change version of the cost data through node-based management, forming a traceable version evolution link;

[0008] Step 2: The cost data is segmented into segments based on roles. Each participant only digitally signs the segmented data within their own scope of responsibility. The signatures are then aggregated to obtain a unified signature that is associated with the corresponding version node.

[0009] Step 3: Construct a dual-chain architecture consisting of a business chain and an audit chain. Store version tree data and signature information in the business chain, and periodically anchor the core verification information of the version tree in the business chain to the audit chain to achieve layered evidence storage.

[0010] Step 4: During the audit, the target version data and audit anchor information are retrieved through the business chain, and the audit verification is completed by combining signature verification and data consistency verification.

[0011] This invention addresses the problem of chaotic version management by constructing a dynamic version tree model to manage the initial and subsequent versions of cost data in a node-based manner, forming a traceable version evolution chain. This model accurately tracks the specific fields, operation times, and associated approval processes of changes. Furthermore, by segmenting cost data into roles, each participant digitally signs only the segmented data within their own scope of responsibility and associates the aggregated unified signature with the corresponding version node, achieving field and responsibility binding and accurately tracing the responsible parties, thus resolving the problem of ambiguous responsibility definitions. Finally, by constructing a dual-chain architecture consisting of a business chain and an audit chain, version tree data and signature information are stored in the business chain, and the core version tree verification information from the business chain is periodically anchored to the audit chain for layered evidence storage. During audits, the target version data and audit anchor information are retrieved, and audit verification is completed by combining signature verification and data consistency verification. This achieves accurate and traceable cost data versions, clear and definable responsibilities, and efficient and accurate audit verification, effectively improving the accuracy, traceability, and multi-party collaboration efficiency of cost data, and ensuring investment control and project quality in engineering construction projects.

[0012] Preferably, step 1 includes the following steps:

[0013] Step 1.1: Obtain the initial version of the cost document, perform structured parsing on the initial version and extract key fields, generate an initial node based on the key fields, the initial node contains a business hash and a structure hash, the business hash is calculated by hashing the key fields of the initial version, and the structure hash is consistent with the business hash of the initial node;

[0014] Step 1.2: When a change in cost data is detected, identify the changed field and generate an incremental node. The incremental node contains a business hash, a structure hash, and a change tag. The business hash is obtained by hashing the changed field separately. The structure hash is obtained by concatenating the structure hash of the parent node and the business hash of the current node. The change tag records key information related to the change, including the change type, approval number, and timestamp.

[0015] Step 1.3: Construct a version tree topology based on the version type on which the change is based. When the change is based on the latest version, child nodes are created to form a linear branch. When the change is based on a historical version, sibling nodes are created to form a parallel branch, resulting in a dynamic version tree.

[0016] Preferably, the structured parsing follows the construction project cost data standard, and the key fields extracted after structured parsing include the quantity of work, unit price, and contract terms.

[0017] Preferably, in step 1.2, the changed content is obtained through optical character recognition technology or application programming interface, and the changed fields and the field values ​​before and after the change are automatically identified.

[0018] Preferably, step 2 includes the following steps:

[0019] Step 2.1: Divide the cost data into segments responsible for multiple participants according to business dimensions. Each participant is only responsible for the segment within their own business scope.

[0020] Step 2.2: Each participant generates a digital signature for the data shards they are responsible for, merges the multiple digital signatures using an aggregate signature algorithm to obtain a single aggregate signature, and associates the aggregate signature with the corresponding node in the dynamic version tree.

[0021] Preferably, the participating parties include the construction party, the contractor, and the supervisor. The construction party is responsible for the segmented data including the contract amount and payment terms; the contractor is responsible for the segmented data including the quantity of work and the unit price of materials; and the supervisor is responsible for the segmented data including the reasonableness assessment of changes and the basis for approval.

[0022] The aggregate signature algorithm is the BLS aggregate signature algorithm, which has a fixed scale and supports independent verification of fragmented signatures by a single participant.

[0023] Preferably, the dual-chain architecture is as follows:

[0024] The business chain uses a high-throughput consortium blockchain to store dynamic version tree node information, aggregate signatures, and change tags;

[0025] The audit chain adopts a highly secure public blockchain; the core verification information is a dynamic version tree root hash, which is anchored to the audit chain in batches according to a preset period, and the transaction identifier of the audit chain is written back to the business chain.

[0026] Preferably, the business chain adopts the Hyperledger Fabric consortium blockchain, which establishes independent data channels for different projects through channel isolation technology and dynamically adjusts the set of endorsement nodes according to the change of tag type;

[0027] The batch anchoring adopts the Merkle tree aggregation method, constructs a Merkle tree from the root hashes of multiple versions within a preset period, and anchors the Merkle tree root to the audit chain, which adopts Ethereum or BSC public chain.

[0028] Preferably, step 4 includes the following steps:

[0029] Step 4.1: Obtain the node set corresponding to the target version path and the anchored audit chain transaction identifier from the business chain, and query the anchored root hash on the audit chain through the transaction identifier;

[0030] Step 4.2: Reconstruct the version tree state at the corresponding time based on the business chain block number, calculate the root hash and compare it with the anchor root hash of the audit chain to verify the consistency of the global state;

[0031] Step 4.3: Extract the business hash of the target node, retrieve the original file from off-chain storage and calculate the corresponding field hash value, and compare and verify the consistency of the business data;

[0032] Step 4.4: Verify the validity of the aggregate signature according to the list of public keys of the participating parties, and confirm that the data changes have been authorized.

[0033] Preferably, the business chain adopts a cold and hot data tiered storage, archives the historical version tree metadata that is accessed infrequently to the InterPlanetary File System, and retains index information and the latest anchor data on the chain; the sharded data is stored using the AES-256 encryption algorithm.

[0034] The beneficial effects of the invention include:

[0035] This invention addresses the problem of chaotic version management by constructing a dynamic version tree model to manage the initial and subsequent versions of cost data in a node-based manner, forming a traceable version evolution chain. This model accurately tracks the specific fields, operation times, and associated approval processes of changes. Furthermore, by segmenting cost data into roles, each participant digitally signs only the segmented data within their own scope of responsibility and associates the aggregated unified signature with the corresponding version node, achieving field and responsibility binding and accurately tracing the responsible parties, thus resolving the problem of ambiguous responsibility definitions. Finally, by constructing a dual-chain architecture consisting of a business chain and an audit chain, version tree data and signature information are stored in the business chain, and the core version tree verification information from the business chain is periodically anchored to the audit chain for layered evidence storage. During audits, the target version data and audit anchor information are retrieved, and audit verification is completed by combining signature verification and data consistency verification. This achieves accurate and traceable cost data versions, clear and definable responsibilities, and efficient and accurate audit verification, effectively improving the accuracy, traceability, and multi-party collaboration efficiency of cost data, and ensuring investment control and project quality in engineering construction projects. Attached Figure Description

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

[0037] Figure 1 A dynamic version tree topology diagram provided for embodiments of the present invention.

[0038] Figure 2 A flowchart of role-based sharding and aggregate signature provided for embodiments of the present invention.

[0039] Figure 3 The dual-chain anchoring architecture and anchoring flowchart are provided for embodiments of the present invention.

[0040] Figure 4 An audit verification process is provided for embodiments of the present invention. Detailed Implementation

[0041] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0042] A blockchain-driven method for uploading cost data to the blockchain employs a four-tiered technical architecture: dynamic version tree, role-based sharding and signing, dual-chain anchored notarization, and full-process audit verification. First, the construction party uploads the initial cost document, and the system constructs a dynamic version tree to record all changes. Next, data is sharded according to the responsibilities of the construction party, contractor, and supervisor, and aggregated signatures are completed. Then, lightweight data is stored on the business chain, and core verification information is periodically anchored to the audit chain. Finally, the auditor completes the audit through cross-validation of the dual-chain data. The specific steps are as follows:

[0043] Step 1: The core function of the dynamic version tree is to achieve traceability, verifiability, and visualization of cost data changes through node-based management. This adapts to high-frequency change scenarios in engineering cost estimation, such as design changes and visa adjustments, avoiding the version chaos and constant revisions inherent in traditional Excel management. Specifically, it includes three sub-steps: initial node generation, incremental node generation, and topology structure construction.

[0044] Initial node generation:

[0045] The specific steps are as follows, using the "Bill of Quantities (V0 version)" in the initial cost estimate document as the implementation target:

[0046] Data Input and Parsing: The contractor uploads a PDF version V0 bill of quantities to the system. The system calls a parsing module conforming to GB / T 51269-2017 to automatically extract key fields including: quantity, unit price, contract amount, payment terms, and other core cost information. After parsing, the data is converted into standard JSON structured data, as shown in the example below: { "Project Number": "XM-YYYY-NNN", "Version Number": "V0", "Quantity": {"Sub-item A": "Q1 Unit", "Sub-item B": "Q2 Unit"}, "Unit Price": {"Material C": "P1 Unit Price", "Material D": "P2 Unit Price"}, "Contract Terms": {"Amount": "Total Cost Amount", "Payment Method": "Agreed Payment Method"}.

[0047] Hash Calculation and Root Node Creation: The system uses the SHA-256 hash algorithm to perform a comprehensive hash calculation on the complete set of key fields in the aforementioned JSON structured data to obtain the initial business hash. This is V0 version structured JSON data; since the initial node has no parent node, the structure hash... direct assignment The final output includes node numbers. , , Complete initial node data for node type (initial node); before hash calculation, the JSON data needs to be standardized and sorted in the order of project number → version number → quantity → unit price → contract terms to avoid hash value deviation due to different field order;

[0048] Incremental node generation:

[0049] During the implementation of cost data, the design unit issued a "Design Change Notice (No. CT-YYYY-NNN)" requesting adjustments to the quantity of a certain sub-item of the project. After the supervisor approved the change, it was submitted to the system, triggering the generation of an incremental node.

[0050] Change content acquisition and field recognition: The system uses OCR technology to recognize the text content of paper change orders and combines it with the electronic approval form API interface data uploaded by the supervisor to automatically extract the change fields as the target sub-item quantity: old value → new value, forming a change field key-value pair ΔD1={"target sub-item": {"old value": "old quantity value", "new value": "new quantity value"}}; thus adapting to the mixed office scenario of paper-based visas and electronic approvals in engineering cost, avoiding manual input errors;

[0051] Incremental node hash calculation: Only the changed field ΔD1 is hashed using SHA-256 to obtain the business hash BH1=H(ΔD1)=b8c4e1f0...; the structure hash SH1 is calculated by concatenating the parent node structure hash and the current business hash, i.e., SH1=H(SH0∥BH1)=c9d5f2a1... (∥ is the string concatenation character).

[0052] Change Tag Binding: Bind change tags to incremental nodes. The content includes: Change Type: Modification, Approval Number: CT-YYYY-NNN, Timestamp: YYYY-MM-DD HH:MM:SS, Operator ID: Supervisor-XXX. The tag information is strongly associated with the node, which solves the problem of untraceability in traditional changes.

[0053] Incremental node output: Generate incremental node V1.1, with node data shown in Table 1 below:

[0054] Table 1

[0055]

[0056] Version tree topology construction:

[0057] The topology structure is constructed by combining two typical change scenarios in the project (linear change and parallel change), as follows:

[0058] Linear change handling: After the V1.1 node is generated, if the construction party proposes to adjust the unit price of a certain material, the change is initiated based on the latest version V1.1. The system automatically creates a child node V2.0 of V1.1, forming a linear branch of V0→V1.1→V2.0.

[0059] Parallel change processing: At the same time as the V1.1 node is generated, the construction party submits a visa application to adjust the concrete quantity of a certain sub-item based on the initial version V0. The system recognizes that the change is initiated based on the historical version V0 and automatically creates a node V1.2 at the same level as V1.1, forming a parallel branch.

[0060] Topology visualization output: The system uses a tree structure to visualize the version evolution link, as shown in the attached diagram. Figure 1 As shown; Appendix Figure 1 In the diagram, V0 is the root node, V1.1 (change in steel reinforcement quantity) and V1.2 (change in concrete quantity) are parallel branches, and V2.0 (change in steel reinforcement unit price) is a child node of V1.1. Each node is labeled with the first 8 digits of the business hash and the core change content, which makes it easy for all parties to trace the changes intuitively.

[0061] Step 2: In project cost estimation, the responsibilities of the construction party, contractor, and supervisor are clearly defined, but data collaboration is difficult. The traditional model, where all personnel sign all documents, leads to inefficiency and unclear accountability. In this embodiment, responsibilities are divided into segments, and aggregated signatures are used to ensure accountability and traceability. The specific steps are as follows:

[0062] Role-based fragmentation rules implemented:

[0063] Based on the division of responsibilities in the engineering cost industry, the system pre-sets segmentation rules and segments the structured data of node V1.1 (reinforcement quantity change). The segmented data responsible for each participant is shown in Table 2 below:

[0064] Table 2

[0065]

[0066] The fragmented data is stored using the AES-256-GCM encryption algorithm (GCM mode supports encryption and integrity verification); key management rules: each project is assigned a unique master key MK, which is jointly managed by the consortium blockchain nodes; each participant's fragmented data uses a subkey derived from the master key. Encryption is used, with subkeys strongly bound to role identities; keys are automatically rotated every 90 days, and rotation records are synchronously uploaded to the blockchain for evidence storage; each participant can only obtain their own subkey through the permission system to decrypt the corresponding shard data.

[0067] Digital signatures and aggregation implementation:

[0068] Employing the BLS aggregate signature algorithm, it supports merging multiple signatures into a single fixed-length (48-byte) signature, adapting to the lightweight storage needs of blockchain. The specific process is as follows: Figure 2 As shown:

[0069] Key distribution: The system assigns exclusive private keys (SK1, SK2, SK3) and public keys (PK1, PK2, PK3) to the construction party, the construction party, and the supervision party respectively. The private keys are stored in the hardware security module (HSM) to prevent the private keys from being leaked.

[0070] Fragmented Signature: Each participant hashes the fragmented data they are responsible for and signs it with their private key: Builder: (SK1, H(Contract Amount || Payment Terms)); Contractor: (SK2, H(Quantity of Work | Material Unit Price)); Supervisor: (SK3, H(Reason for change∥Visa number)).

[0071] Signature aggregation: Each participating party uploads its signature to the system aggregator, which then calls... The algorithm will , , Merged into a single aggregate signature Compared with traditional multi-signature, aggregated signature is smaller and supports verifying the signature of a single party (such as verifying only the approval signature of the supervisor). When verifying aggregated signature, changes to core fields (such as quantity of work or contract amount) require all three parties' signatures to be valid, while changes to secondary fields (such as remarks) require at least two parties' signatures to be valid.

[0072] Signature association: The system will aggregate signatures. The business hash and structure hash of the V1.1 node are bound together to form a complete data unit of node data and aggregate signature, which prepares for subsequent on-chain processing.

[0073] Step 3: Engineering cost data needs to balance the dual requirements of high-frequency change processing and long-term audit reliability. A single blockchain cannot simultaneously meet the demands of high throughput and high security. In this embodiment, a dual-chain architecture of business chain and audit chain is constructed, as follows:

[0074] For dual-chain selection and deployment, please refer to Table 3:

[0075] Table 3

[0076]

[0077] In this embodiment, the consortium blockchain supports access control, channel isolation can avoid data interference between different projects, and high throughput is suitable for high-frequency cost change scenarios; while the public blockchain has strong immutability, is suitable for storing core audit information, and smart contracts can automatically execute anchoring logic.

[0078] Data on-chain and anchoring process:

[0079] As attached Figure 3 As shown, the specific process is divided into three stages: business chain storage, audit chain anchoring, and TxID write-back.

[0080] Business chain storage phase: The system will store the complete data units (SH1, BH1, change tag, ...) of the V1.1 node. The version tree topology relationship (ParentID: V0, ChildIDs: []) is written into “XM-YYYY-NNN-Channel”; at the same time, cold and hot data are stored in a hierarchical manner: the metadata of historical nodes such as V0 that are accessed infrequently is archived to IPFS, and the business chain only retains the index information and the latest node data such as V1.1 and V1.2, reducing the on-chain storage cost.

[0081] Audit chain anchoring phase: First, a Merkle tree is constructed from the version tree data of the business chain. The construction rules are as follows: leaf nodes are the root hashes of the version tree collected within the last 10 minutes, sorted in ascending order of timestamps (e.g., ...). , , The SHA-256 hash algorithm is used to concatenate adjacent leaf nodes pairwise and perform hash calculations to form the parent node of the next level. This process is repeated layer by layer upwards until a unique Merkle root is generated. If the number of leaf nodes is odd, the last leaf node is copied as a temporary node to participate in the concatenation calculation, ensuring the integrity of the tree structure. Subsequently, the Merkle root is anchored to the audit chain through the smart contract AnchorContract. This contract is deployed on the Ethereum Sepolia testnet (migrated to the Ethereum mainnet during mainnet deployment). The core logic includes:

[0082] The core interface is `anchorRoot(bytes32 merkleRoot)`, which returns `(bytes32 txID)`. When calling this interface, the digital signature of the business chain administrator must be passed for identity verification.

[0083] Data recording: After a successful call, the Merkle root, transaction ID, and anchor timestamp are automatically recorded to the audit chain block, forming an immutable anchor record;

[0084] Event callback: After anchoring is completed, the AnchorEvent(merkleRoot, txID, anchorTime) event is triggered. The auditing node can obtain anchoring information in real time by listening to this event, without having to actively query, thus improving efficiency.

[0085] TxID write-back phase: After anchoring is completed, the repeater writes the TxID back to the AnchorState of the business chain, realizing a closed loop of business chain data, audit chain anchoring, and business chain association. The auditor can quickly locate the anchoring record of the audit chain through the TxID of the business chain.

[0086] In addition, the business chain adopts a dynamic endorsement strategy: for changes to core fields such as steel reinforcement quantity and contract amount, the construction party, contractor, and supervisor all need to endorse; for minor changes such as remarks, only the contractor and supervisor need to endorse, thus balancing security and efficiency.

[0087] Step 4: The project cost audit needs to verify the authenticity of the data, the continuity of versions, and the legality of the authorization. In this embodiment, automated auditing is achieved through dual-chain data cross-validation. Taking the auditor's verification of the V0→V1.1→V2.0 version chain as an example, the process is as follows: Figure 4 As shown:

[0088] Data retrieval phase: The auditor inputs the target version path V0→V1.1→V2.0 into the system, and the system retrieves the corresponding node set from the business chain "XM-YYYY-NNN-Channel". And obtain the anchored audit chain TxID=0x7a9f....

[0089] Global state verification: The auditor queries the anchored Merkle root using the TxID in the Ethereum browser, and simultaneously reconstructs the version tree state at that time based on the block number of the business chain (corresponding to the anchoring time), and calculates the reconstructed root hash. ;contrast If it matches the Merkle root of the audit chain, it proves that the global state of the business chain at the anchoring moment has not been tampered with.

[0090] Business data consistency verification: Extract the business hash BH2.0 from Node2.0, retrieve the original change visa file corresponding to V2.0 from the off-chain database, extract the change field "target material unit price: old unit price → new unit price" through OCR, and recalculate the hash value BH2.0'; compare BH2.0' with BH2.0 of Node2.0. If they are consistent, it proves that the original off-chain file is consistent with the on-chain record.

[0091] Version continuity verification: This is achieved by tracing the chained relationship of the structure hash. The specific verification logic consists of two steps:

[0092] Structure hash relation 1 verification: Extract the structure hash of the node to be verified, Node1.1. At the same time, obtain the structure hash of its direct parent node Node0. And Node1.1's own business hash ,calculate If the calculation result is the same as If they are completely identical, it proves that the parent-child relationship between Node1.1 and Node0 is valid;

[0093] Structure hash relation 2 verification: Extract the structure hash of Node 2.0 Obtain the structure hash of its parent node Node1.1 Business hash of Node 2.0 ,calculate If with If they are consistent, it proves that the association between Node2.0 and Node1.1 is valid; if either relationship fails to be verified, the system will automatically mark the version link as broken, immediately trigger an anomaly alarm and push it to the auditor and project manager, and lock the modification permissions of that version until the anomaly investigation is completed.

[0094] Signature validity verification: Obtain the public key lists of the builder, contractor, and supervisor, and call the BLS_Verify function to verify the aggregate signature associated with Node 2.0. If the verification passes, it proves that the change has been signed by all authorized parties and complies with the process specifications.

[0095] Audit report output: The system automatically generates an "Audit Verification Report", which clearly marks the verification results of global status consistency, business data consistency, version continuity, and valid signature, and attaches evidence such as hash value and TxID of each step to achieve traceability of audit results.

[0096] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A blockchain-driven method for uploading cost data to the blockchain, characterized in that, Includes the following steps: Step 1: Construct a dynamic version tree model to manage the initial version and each change version of the cost data through node-based management, forming a traceable version evolution link; Step 1.1: Obtain the initial version of the cost document, perform structured parsing on the initial version and extract key fields, generate an initial node based on the key fields, the initial node contains a business hash and a structure hash, the business hash is calculated by hashing the key fields of the initial version, and the structure hash is consistent with the business hash of the initial node; The structured parsing follows the construction project cost data standard, and the key fields extracted after structured parsing include project quantity, unit price, and contract terms. Step 1.2: When a change in cost data is detected, identify the changed field and generate an incremental node. The incremental node contains a business hash, a structure hash, and a change tag. The business hash is obtained by hashing the changed field separately. The structure hash is obtained by concatenating the structure hash of the parent node and the business hash of the current node. The change tag records key information related to the change, including the change type, approval number, and timestamp. Step 1.3: Construct a version tree topology based on the version type on which the change is based. When the change is based on the latest version, child nodes are created to form a linear branch. When the change is based on a historical version, sibling nodes are created to form a parallel branch, thus obtaining a dynamic version tree. Step 2: The cost data is segmented into segments based on roles. Each participant only digitally signs the segmented data within their own scope of responsibility. The signatures are then aggregated to obtain a unified signature that is associated with the corresponding version node. Step 2.1: Divide the cost data into segments responsible for multiple participants according to business dimensions. Each participant is only responsible for the segment within their own business scope. Step 2.2: Each participant generates a digital signature for the data shards they are responsible for, merges the multiple digital signatures using an aggregate signature algorithm to obtain a single aggregate signature, and associates the aggregate signature with the corresponding node in the dynamic version tree; The participating parties include the construction party, the contractor, and the supervisor. The construction party is responsible for the contract amount and payment terms for each section of data; the contractor is responsible for the quantity of work and the unit price of materials for each section of data; and the supervisor is responsible for the reasonableness assessment of changes and the basis for approvals for each section of data. The aggregate signature algorithm is the BLS aggregate signature algorithm, and the aggregate signature scale is fixed and supports independent verification of fragmented signatures by a single participant. Step 3: Construct a dual-chain architecture consisting of a business chain and an audit chain. Store version tree data and signature information on the business chain, and periodically anchor the core version tree verification information from the business chain to the audit chain to achieve layered evidence storage. The dual-chain architecture is as follows: The business chain uses a high-throughput consortium blockchain to store dynamic version tree node information, aggregate signatures, and change tags; The audit chain adopts a highly secure public blockchain; the core verification information is a dynamic version tree root hash, which is anchored to the audit chain in batches according to a preset period, and the audit chain transaction identifier is written back to the business chain; The business chain adopts the Hyperledger Fabric consortium blockchain, which establishes independent data channels for different projects through channel isolation technology and dynamically adjusts the set of endorsement nodes according to changes in tag type. The batch anchoring adopts the Merkle tree aggregation method, constructs a Merkle tree from the root hashes of multiple versions within a preset period, and anchors the Merkle tree root to the audit chain, which adopts Ethereum or BSC public chain; Step 4: During the audit, the target version data and audit anchor information are retrieved through the business chain, and the audit verification is completed by combining signature verification and data consistency verification. Step 4 includes the following steps: Step 4.1: Obtain the node set corresponding to the target version path and the anchored audit chain transaction identifier from the business chain, and query the anchored root hash on the audit chain through the transaction identifier; Step 4.2: Reconstruct the version tree state at the corresponding time based on the business chain block number, calculate the root hash and compare it with the anchor root hash of the audit chain to verify the consistency of the global state; Step 4.3: Extract the business hash of the target node, retrieve the original file from off-chain storage and calculate the corresponding field hash value, and compare and verify the consistency of the business data; Step 4.4: Verify the validity of the aggregate signature according to the list of public keys of the participating parties, and confirm that the data changes have been authorized.

2. The blockchain-driven method for uploading cost data to the blockchain according to claim 1, characterized in that, In step 1.2, the changed content is obtained through optical character recognition technology or application programming interface, and the changed fields and the field values ​​before and after the change are automatically identified.

3. The blockchain-driven method for uploading cost data to the blockchain according to claim 1, characterized in that, The business chain adopts a cold and hot data tiered storage, archives the historical version tree metadata that is accessed infrequently to the InterPlanetary File System, and retains index information and the latest anchor data on the chain; the sharded data is stored using the AES-256 encryption algorithm.

Images