BIM-based blockchain engineering contract evidence storage method

Abstract

This invention relates to the field of engineering management technology and discloses a blockchain-based method for preserving engineering contracts using BIM (Building Information Modeling). When an engineering contract data submission event is detected, the method processes the contract data based on BIM model data and blockchain preservation functions (including hash generation, smart contracts, consensus verification, and data uploading to the blockchain) to obtain processing results and determine the preservation information. For submission events involving multiple contract data sets, the method determines whether a second contract data set capable of processing multiple data sets exists. If not, the preservation information is directly determined; if it exists, the processing strength is determined based on processing parameters, and the result corresponding to the strongest processing strength is selected as the preservation information. The processing parameters can also be adjusted and the processing strength updated based on differences in data characteristics. After preservation is completed, the preservation information is retrieved using the blockchain query function, and the final result is output. This method improves the security, effectiveness, and collaboration of engineering contract preservation.

Description

Technical Field

[0001] This invention relates to the field of engineering management technology, specifically a blockchain-based method for storing engineering contracts based on BIM. Background Technology

[0002] From a data security perspective, traditional evidence storage methods often rely on centralized servers to store contract data, which presents a single point of failure risk. If a server is attacked by hackers, experiences hardware failure, or suffers human error, contract data may be lost, altered, or leaked, seriously threatening the legitimate rights and interests of both parties. For example, in one construction project, contract data was maliciously altered due to a server attack, making it difficult to effectively resolve contract disputes and causing significant economic losses to the company.

[0003] Regarding data consistency and collaboration, engineering construction often involves multiple stakeholders, such as owners, contractors, and supervision units. These stakeholders generate a large amount of interconnected data during contract execution. Traditional data storage methods struggle to achieve real-time synchronization and sharing between different stakeholders, easily creating data silos. Inconsistencies in data can lead to misunderstandings and disputes, impacting project progress. For example, in a large construction project, discrepancies in the owner's and contractor's records of changes in contract quantities caused a dispute during payment settlement, delaying the project's completion.

[0004] In terms of data verification and traceability, traditional evidence preservation methods lack effective data verification mechanisms and complete traceability chains. When disputes arise regarding contract data, it is difficult to quickly and accurately verify the authenticity and completeness of the data, and it is also impossible to trace the data's modification history. This makes the credibility of traditional evidence preservation data low in scenarios such as judicial evidence collection. For example, in a construction contract dispute case, because traditional evidence preservation data could not provide a complete modification record, the court found it difficult to determine the authenticity of the data, leading to a prolonged case trial period.

[0005] With the widespread application of BIM technology in building construction, although BIM models can integrate multi-dimensional data such as geometric and functional information of building projects, providing rich basic data for project management, how to effectively combine BIM model data with contract management to achieve efficient contract data storage remains an urgent problem to be solved. Meanwhile, blockchain technology, with its distributed storage, immutability, and consensus mechanism, has shown great potential in the field of data storage. However, current research and practice on applying BIM and blockchain technologies to engineering contract storage are still in the exploratory stage, lacking a systematic and comprehensive method to fully leverage the advantages of both to solve the security, consistency, verification, and traceability problems existing in traditional engineering contract storage. Therefore, it is urgent to propose a BIM-based blockchain engineering contract storage method to improve the reliability, efficiency, and collaboration of engineering contract storage, and promote the digital and intelligent development of engineering contract management. Summary of the Invention

[0006] The purpose of this invention is to provide a BIM-based blockchain engineering contract notarization method to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based engineering contract notarization method based on BIM, the method comprising:

[0008] When an engineering contract data submission event is detected, the engineering contract data is processed based on BIM model data and blockchain evidence storage function.

[0009] Based on the processed engineering contract data, evidence storage information corresponding to the engineering contract data submission event is determined.

[0010] Preferably, the blockchain evidence storage function includes one or more of the following: hash generation function, smart contract function, consensus verification function, and data on-chain function;

[0011] The process of processing the engineering contract data based on BIM model data and blockchain notarization includes:

[0012] The engineering contract data is processed based on the hash generation function to obtain a first hash value. When the first hash value meets preset conditions, the data identifier corresponding to the first hash value is determined according to a pre-set hash-data mapping relationship, and is used as the processing result of the engineering contract data; and / or,

[0013] Based on the smart contract function, the engineering contract data is parsed to obtain first parsed data, and second parsed data sent by the BIM model data is obtained. The first and second parsed data are then integrated to obtain the processing result of the engineering contract data; and / or,

[0014] Based on the consensus verification function, the validity of the engineering contract data is verified, and the verification result is parsed to obtain the processing result of the engineering contract data; and / or,

[0015] Based on the data on-chain function, the engineering contract data is written into the blockchain distributed ledger, and the writing result is parsed to obtain the processing result of the engineering contract data.

[0016] Preferably, the engineering contract event involves multiple contract data, each of which corresponds to BIM model data, and each of the contract data needs to be processed;

[0017] The method further includes:

[0018] Determine whether at least two of the aforementioned engineering contract data were simultaneously submitted separately;

[0019] If the judgment result is negative, the operation of determining the evidence storage information corresponding to the engineering contract data submission event based on the processed engineering contract data is executed.

[0020] When the judgment result is yes, it is determined whether there is a second contract data among all the engineering contract data. The second contract data is the contract data that the corresponding blockchain storage function can process multiple contract data at the same time.

[0021] When it is determined that the second contract data does not exist, the operation of determining the evidence storage information corresponding to the project contract data submission event based on the processed project contract data is executed.

[0022] Preferably, the method further includes:

[0023] When it is determined that the second contract data exists, for any piece of the second contract data:

[0024] The processing parameters of each contract data processed by the blockchain notarization function corresponding to the second contract data are obtained, and the processing strength of the blockchain notarization function of the second contract data for each contract data is determined according to all the contents included in the processing parameters of the second contract data for each contract data. The processing result of the contract data with the strongest processing strength is selected from the processing results of all the contract data as the notarization information of the second contract data.

[0025] The determination of evidence storage information corresponding to the submission event of the engineering contract data based on the processed engineering contract data includes:

[0026] When evidence storage information is determined for each of the second contract data in all the second contract data, the evidence storage information corresponding to that second contract data is determined based on the processing result of each processed second contract data.

[0027] Preferably, the processing parameters for each contract data include one or more of the following: processing time, processing frequency, data size, and data type, centered on the location of the node corresponding to the blockchain notarization function.

[0028] Preferably, the method further includes:

[0029] Determine whether the processing parameters of each contract data include the processing frequency and / or data type of that contract data.

[0030] When the judgment result is negative, the operation of determining the processing strength of the blockchain evidence storage function of the second contract data for each contract data is performed based on all the contents included in the processing parameters of the second contract data for each contract data.

[0031] When the determination result is yes, the data characteristics of each contract data are determined, and the data characteristics of each contract data include format and / or structure;

[0032] Determine whether the data characteristics of each contract data item are the same across all the contract data;

[0033] When a match is determined, the operation of determining the processing strength of the blockchain notarization function for each contract data is triggered based on all the processing parameters of the second contract data for each contract data.

[0034] Preferably, the processing parameters for each contract data item also include the processing time of that contract data; the method further includes:

[0035] When a difference is found, the contract data with the shortest processing time is grouped in pairs with each of the remaining contract data to obtain at least one data group. Each data group contains the contract data with the shortest processing time and one other contract data.

[0036] For any of the data sets mentioned:

[0037] Based on all the data features of the two contract data in the data group, the feature difference between data features of the same type is calculated sequentially, and based on the feature difference between data features of the same type in the two contract data, the feature difference between the two contract data is calculated;

[0038] Based on the processing time and data characteristics of each of the two contract data sets, a target correction data matching the correction method is determined from the two contract data sets;

[0039] Based on the characteristic differences between the two contract data sets, the processing frequency and / or data type of the target modified data are corrected to obtain the corrected processing parameters. After the corrected processing parameters corresponding to all the data sets are determined, the operation of determining the processing strength of the blockchain notarization function of the second contract data for each contract data set is performed based on all the contents included in the processing parameters of the second contract data for each contract data set.

[0040] Preferably, the method further includes:

[0041] When the modified processing parameters are determined, the processing parameters of each contract data processed by the blockchain notarization function corresponding to the second contract data are re-acquired.

[0042] The process for determining the processing intensity is updated based on the reacquired processing parameters.

[0043] Preferably, the method further includes:

[0044] Based on the updated processing intensity, the processing results of the contract data corresponding to the strongest processing intensity are re-selected;

[0045] The re-filtered processing results are stored as the evidence information.

[0046] Preferably, the method further includes:

[0047] When the evidence storage information is stored, the stored evidence storage information is retrieved based on the blockchain query function;

[0048] The retrieved evidence information is parsed, and the final evidence storage result is output.

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

[0050] Regarding data security, the distributed storage characteristics of blockchain are leveraged to distribute engineering contract data across multiple nodes, avoiding the single point of failure risk inherent in traditional centralized storage. Even if some nodes fail or are attacked, other nodes can still preserve the data intact, ensuring its integrity and availability. Simultaneously, blockchain's encryption technology and immutability ensure that any tampering with contract data is detected by the system, and the altered data cannot pass consensus verification, effectively preventing malicious data modification and providing robust security for engineering contract data. For example, if contract data on one node is illegally altered, other nodes will refuse to recognize the altered data, guaranteeing its authenticity.

[0051] Data verification and traceability capabilities have been greatly enhanced. The consensus verification function of blockchain can quickly verify the validity of engineering contract data, ensuring the legality and accuracy of the data uploaded to the chain. Once data is uploaded, all its operation records are completely recorded in the blockchain's distributed ledger, forming an immutable traceability chain. In the event of a contract dispute, the blockchain query function can quickly retrieve the stored information and analyze its complete operation history, accurately tracing the source and modification process of the data, providing strong evidentiary support for resolving the dispute. For example, in disputes over changes to contract terms, the time of the change, the participating parties, and the specific content can be clearly viewed, clarifying the responsible party.

[0052] In terms of flexibility and efficiency in data processing, this method supports the combined use of multiple blockchain notarization functions, including hash generation, smart contract functionality, consensus verification, and data uploading. Hash generation quickly generates unique hash values ​​for engineering contract data, enabling rapid data identification and comparison. Smart contract functionality automatically parses engineering contract data and integrates it with BIM model data, improving the automation and accuracy of data processing. Consensus verification ensures data validity, preventing invalid data from being uploaded to the blockchain. Data uploading enables permanent data storage and sharing. Furthermore, for cases where multiple contract data are submitted simultaneously, this method intelligently determines whether a second contract data set capable of processing multiple contracts exists, determines the processing intensity based on processing parameters, and selects the optimal processing result. This effectively improves the system's efficiency and accuracy in handling complex business scenarios, avoiding data processing chaos and delays.

[0053] Collaborative management capabilities are significantly enhanced. Since engineering contract events involve multiple contract data sets, each corresponding to BIM model data, this method enables deep integration of BIM model data and contract data. All participating parties can share and synchronize contract data in real time based on a unified BIM model and blockchain-based evidence storage system, breaking down data silos inherent in traditional evidence storage methods and improving collaboration efficiency among participants. For example, owners, contractors, and supervision units can view the processing status and evidence storage information of contract data in real time, promptly identify problems, and communicate and coordinate to ensure the smooth progress of project construction.

[0054] It exhibits strong scalability and adaptability. This method can flexibly adjust processing parameters and processes according to different engineering contract scenarios and needs. For example, when processing parameters include processing frequency and data type, the system first determines whether the data characteristics of the contract data are the same, and then performs corresponding processing and corrections based on different situations, ensuring that the method can adapt to diverse engineering contract data processing needs. Simultaneously, by continuously updating processing intensity and filtering optimal processing results, the system can continuously optimize the evidence preservation process, improve evidence preservation quality and efficiency, and meet the ever-evolving needs of engineering contract management. Attached Figure Description

[0055] Figure 1 This is a schematic diagram illustrating the working principle of the BIM-based blockchain engineering contract notarization method described in this invention.

[0056] Figure 2 A flowchart for determining the data processing intensity of the second contract;

[0057] Figure 3 Flowchart for feature difference processing;

[0058] Figure 4 This is a flowchart for processing parameter content judgment. Detailed Implementation

[0059] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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.

[0060] Please see Figures 1-4 The present invention relates to a BIM-based blockchain engineering contract notarization method, the specific implementation steps of which are as follows:

[0061] When an engineering contract data submission event is detected, step 1 is executed: The engineering contract data is processed based on BIM model data and blockchain notarization functionality. The BIM model data contains structured data such as the three-dimensional geometric information, attribute information, and progress information of the engineering object. The blockchain notarization functionality performs data notarization operations through a blockchain node network. The specific processing includes one or more combinations of operations such as hash calculation, smart contract parsing, consensus verification, or data uploading to the blockchain.

[0062] After processing is complete, proceed to step 2: Based on the processed engineering contract data, determine the evidence storage information corresponding to the submission event of the engineering contract data. The evidence storage information includes at least parameters used to uniquely identify the evidence storage status, such as data identifier, processing result timestamp, and blockchain network node identifier, and achieves data immutability and traceability through distributed ledger recording.

[0063] Example 1:

[0064] The blockchain evidence storage function specifically includes hash generation, smart contract, consensus verification, and data on-chain functions. These functional modules work together to form a multi-layered processing system for engineering contract data.

[0065] The hash generation function's processing flow is as follows: The system processes the engineering contract data using a cryptographic hash algorithm. Taking the common SHA-256 algorithm as an example, this algorithm can convert input data of any length into a fixed-length 256-bit hash value, i.e., the first hash value. During processing, the system first preprocesses the engineering contract data, removing redundant spaces, newlines, and other irrelevant characters to ensure the input data's standardization and avoid hash value generation anomalies due to format differences. After preprocessing, the hash generation module calls the algorithm interface to perform hash calculations on the standardized engineering contract data, generating a unique first hash value.

[0066] The system pre-defines hash value verification rules, such as requiring hash values ​​to be 256 bits long and verifying their integrity using a checksum algorithm. When the generated first hash value meets the preset conditions, the system accesses a pre-established hash-data mapping table. This table stores the correspondence between hash values ​​and data identifiers in key-value pairs. The data identifier is a unique code used to identify engineering contract data and may contain information such as contract type, signing time, and identification of the client and contractor. By searching the mapping table for the hash value, the unique data identifier corresponding to that hash value can be quickly determined and used as one of the processing results for the engineering contract data. This process binds engineering contract data with data identifiers, providing a crucial index for the subsequent generation of evidence storage information.

[0067] The smart contract function involves the automated interaction between blockchain technology and engineering contract data. The system automatically parses engineering contract data by pre-deploying smart contract code on the blockchain. The smart contract code, written in blockchain programming languages ​​such as Solidity, includes rules for parsing structured fields in the engineering contract data, such as the logic for extracting key information like contract number, contract amount, construction period, and payment method. When the engineering contract data is submitted to the blockchain network, the smart contract automatically executes, parsing the data according to preset rules and extracting the first structured parsed data.

[0068] Simultaneously, the system extracts information related to the engineering contract data from the BIM model data to generate second-level analytical data. The BIM model data contains the three-dimensional geometric information, attribute information, and schedule information of the engineering objects. For example, in a building construction contract, the BIM model can provide data such as the structural dimensions, material types, and construction progress nodes for specific floors. By establishing a relationship between the engineering contract data and the BIM model data (e.g., matching the engineering part numbers stipulated in the contract with the component IDs in the BIM model), the system can accurately obtain the second-level analytical data corresponding to the contract data.

[0069] After obtaining the first and second sets of analytical data, the system processes them using a data integration engine. The engine first matches fields from both types of data, for example, linking the "material specifications" field in the contract with the "material type" field in the BIM model to ensure data consistency. Then, it verifies the accuracy of the data through a cross-validation mechanism, such as checking whether the construction period stipulated in the contract conflicts with the construction schedule in the BIM model. After field matching and cross-validation, the two types of data are integrated into a processed result containing information linking the contract and the model. This result not only preserves the original terms of the contract but also incorporates specific information about the engineering entity, providing richer context for the preservation of the engineering contract.

[0070] The consensus verification function relies on the consensus mechanism in the blockchain network to achieve distributed verification of engineering contract data. Common consensus mechanisms include PBFT (Practical Byzantine Fault Tolerance) and PoS (Proof-of-Stake), with different mechanisms suitable for different blockchain network scenarios. In this embodiment, the system uses the PBFT algorithm to perform consensus verification of engineering contract data.

[0071] Once the engineering contract data is parsed and integrated through smart contracts, it is broadcast to various nodes in the blockchain network. Each node independently verifies the integrity and validity of the data, including the compliance of the data format (e.g., whether it conforms to preset formats such as JSON and XML), the validity of the digital signature (ensuring the data has not been tampered with), and the consistency of the timestamp (ensuring the authenticity of the data submission time). During the verification process, the node first checks whether the digital signature of the data matches the sender's public key; if they do not match, the data is deemed invalid. Next, it verifies whether the timestamp of the data is within the system's allowed time window to prevent the submission of outdated data. Finally, it checks whether the data format conforms to the preset schema to ensure the correctness of the data structure.

[0072] After each node completes its verification, it generates a verification result containing its own signature and feeds the result back to the consensus node. Once the consensus node has collected more than a preset number (e.g., more than two-thirds) of valid verification results, it determines that the engineering contract data has passed the consensus verification and generates a final verification result containing the signatures of all verification nodes. This result, as part of the processing result, ensures the immutability and consensus of the data.

[0073] The data on-chain processing flow involves writing the engineering contract data, which has undergone hash calculation, smart contract parsing, and consensus verification, into the blockchain distributed ledger. The system first performs fragmentation processing on the engineering contract data and its associated BIM model data, dividing large files into smaller data blocks suitable for blockchain storage to improve data transmission and storage efficiency. Fragmentation rules can be set according to data type and size; for example, text-based contract data can be fragmented into 1MB blocks, and the 3D geometric data of the BIM model can be fragmented into component units.

[0074] After sharding, the data is transmitted to the blockchain nodes via a P2P network. Each node, upon receiving a data shard, verifies its integrity by comparing hash values ​​to ensure the data has not been lost or tampered with during transmission. Once verified, the node packages the data shards into blocks according to the blockchain protocol rules and completes the generation and verification of these blocks using proof-of-work or other consensus mechanisms.

[0075] After a block is generated, the data is written to the distributed ledger. Each block contains the hash value of the previous block, forming a chain structure to ensure data traceability. Once the writing is complete, the system parses the transaction receipt returned by the blockchain to obtain the writing result, which includes information such as block height, transaction ID, and timestamp. This information constitutes the final processing result of the engineering contract data, marking the completion of data notarization.

[0076] Example 2:

[0077] When an engineering contract data submission event involves multiple contract data, each contract data corresponds to a unique BIM model data fragment, and each contract data needs to be processed independently. The system is designed with differentiated processing logic for multi-data submission scenarios to ensure accurate and efficient evidence preservation operations under different submission modes.

[0078] The system monitors the submission status of engineering contract data in real time through an event listening module. When an engineering contract data submission event is detected, it determines whether the event involves the simultaneous submission of multiple contract data. "Multiple contract data" here includes related contract documents such as contracts for different sections of the same project, supplementary agreements, and change orders. Each contract data carries a unique identifier (such as contract number, project ID, etc.) and is mapped to the corresponding components, schedule nodes, or cost items in the BIM model. For example, in a large construction project, a main structure construction contract and a mechanical and electrical installation subcontract may be submitted simultaneously, corresponding to structural components and mechanical and electrical pipeline model data in the BIM model, respectively.

[0079] If the judgment result is negative, meaning only a single contract data is submitted, the system directly proceeds to step 2 of the overall solution, generating evidence storage information based on the processing result of that single contract data. The processing flow at this point is consistent with the single data scenario, involving sequential processing through modules such as hash generation, smart contract parsing, consensus verification, and data uploading to the blockchain, ultimately generating an evidence storage record containing information such as data identifiers, timestamps, and node signatures.

[0080] If the judgment result is yes, meaning at least two contract data were detected to be submitted simultaneously, the system enters a multi-data processing branch to further determine whether a second contract data exists among all contract data. Here, "second contract data" refers to contract data for which the corresponding blockchain notarization function has the capability to process multiple contract data simultaneously. This capability is typically reflected in the compatibility of blockchain nodes or smart contracts with data types and formats, such as standardized construction contract templates and supplementary protocols for structured data formats. Their data structures conform to the parallel processing rules of the blockchain notarization function, allowing for simultaneous hash calculations, consensus verification, and other operations through the same smart contract instance or node cluster.

[0081] When it is determined that no second contract data exists, it means that all simultaneously submitted contract data cannot be processed in parallel by the blockchain notarization function. In this case, the system adopts a serial processing logic, processing each contract data sequentially according to the submission time order or preset priority (e.g., the main contract takes precedence over supplementary agreements). Specifically, for the first contract data, the system initiates a hash generation function to generate a first hash value, parses its structured fields through a smart contract, integrates it with the BIM model data, and writes it to the blockchain after verification by consensus nodes. After processing the first contract data and generating notarization information, the same process is followed for the next contract data, until all simultaneously submitted contract data has been processed. While this serial processing method is relatively inefficient, it ensures that each contract data can be processed according to the complete process of a single data scenario, avoiding data loss or verification failure due to insufficient compatibility with parallel processing.

[0082] During serial processing, the system creates an independent processing thread for each contract data. Threads coordinate with each other through a message queue to ensure the accuracy of the processing order. Simultaneously, the system monitors the status of each thread in real time. If an anomaly occurs during the processing of a contract data (such as hash value calculation failure or consensus verification timeout), the execution of that thread is paused, an anomaly log is recorded, and an error recovery mechanism is triggered (such as resubmitting data or switching to a backup node). Processing resumes after the anomaly is resolved, ensuring the integrity of the entire multi-data submission event.

[0083] When all simultaneously submitted contract data are not second contract data, even with a large data volume, the system still completes the notarization through a stable serial processing mechanism. For example, if three non-standardized change agreements are submitted simultaneously in the middle of a project, each with different data formats and field structures, the blockchain notarization function cannot process them simultaneously. In this case, the system will parse, verify, and upload each agreement to the blockchain separately, ultimately generating three independent notarization records. The system will also indicate the relationship between the notarization records (such as change files belonging to the same project ID) in the comprehensive notarization record, facilitating subsequent querying and management.

[0084] It should be noted that when determining whether second contract data exists, the system uses a pre-established knowledge base of contract data types for matching. This knowledge base stores information such as the format characteristics, field structure, and blockchain compatibility identifiers of various types of contract data. When new contract data is submitted, the system first extracts its metadata (such as file type, field list, data structure description, etc.) and compares it with the records in the knowledge base. If a match is found for a certain type of contract data marked as "can be processed in parallel," it is determined to be second contract data; if no type that can be processed in parallel is matched, it is determined that no second contract data exists.

[0085] Furthermore, the system supports dynamic updates to the knowledge base. New contract data types that can be processed in parallel can be identified through manual input by administrators or automatic identification via machine learning algorithms, adapting to the ever-changing contract management needs in the engineering field. For example, when a new type of electronic contract becomes widely used and has a standardized structure, it can be updated in the knowledge base to become a new secondary contract data type, thereby enabling parallel processing in subsequent multi-data submission scenarios and improving the system's adaptability and processing efficiency.

[0086] Example 3:

[0087] When a second contract is identified, the system must perform a processing intensity assessment and evidence screening on multiple corresponding contract data for any given second contract. The specific processing flow is as follows:

[0088] The system acquires the processing parameters of each contract data item processed by the blockchain notarization function corresponding to the second contract data. These processing parameters are collected centered on the location of the node corresponding to the blockchain notarization function and include multi-dimensional information such as processing time, processing frequency, data size, and data type. Specifically, the processing time is the UTC timestamp indicating when the node begins processing the contract data, accurate to the millisecond level; the processing frequency refers to the number of times the node performs operations such as hash calculations and smart contract parsing on the contract data per unit time; the data size is the number of bytes in the contract data, including all content such as text, attachments, and BIM model-related data; and the data type is categorized into structured data (such as JSON and XML formats), semi-structured data (such as CSV and Excel formats), and unstructured data (such as PDF and image formats).

[0089] Taking a construction project that simultaneously submits a main contract (structured data, 500KB) and a supplementary agreement (semi-structured data, 800KB) as an example, the system collects the processing parameters of the blockchain nodes for both: the processing time of the main contract is 14:00:05.123 on June 6, 2025, the processing frequency is 2 times per second, the data size is 500KB, and the data type is structured; the processing time of the supplementary agreement is 14:00:05.125 on June 6, 2025, the processing frequency is 1 time per second, the data size is 800KB, and the data type is semi-structured.

[0090] The system determines the processing intensity of the blockchain notarization function for each contract data based on all the processing parameters included in the second contract data. The processing intensity assessment is achieved through a pre-set comprehensive evaluation model, which quantitatively analyzes various processing parameters. For example, the closer the processing time is to the current time (based on the node's processing completion time), the higher the time dimension score; a higher processing frequency indicates higher priority in node resource allocation, resulting in a higher frequency dimension score; smaller data size indicates lower processing complexity, leading to a higher size dimension score; structured data scores higher in the type dimension than semi-structured and unstructured data because it is easier for smart contracts to parse.

[0091] In the specific evaluation process, the system sets standardized ranges for each processing parameter. Processing time is based on the submission event trigger time; processing within 10 seconds scores 100 points, with 5 points deducted for each second exceeding this limit. Processing frequency is based on once per second; each increase adds 20 points, and each decrease deducts 10 points. Data size is based on 1MB; each decrease of 100KB adds 10 points, and each increase of 100KB deducts 5 points. Data type scores are set as follows: structured 100 points, semi-structured 80 points, and unstructured 60 points. The processing intensity value for each contract data item is calculated by weighting and summing the scores from each dimension (the weights can be dynamically adjusted according to project management needs, such as processing frequency 30%, data type 25%, processing time 25%, and data size 20%).

[0092] Taking the aforementioned main contract and supplementary agreement as examples, the main contract's processing time is 5.123 seconds (score 97.35), processing frequency is 2 times per second (score 120), data size is 500KB (score 100), data type is structured (score 100), and the weighted processing intensity value is: 97.35×25%+120×30%+100×20%+100×25%=106.84; the supplementary agreement's processing time is 5.125 seconds (score 97.32), processing frequency is 1 time per second (score 100), data size is 800KB (score 85), data type is semi-structured (score 80), and the weighted processing intensity value is: 97.32×25%+100×30%+85×20%+80×25%=91.83. Therefore, it can be seen that the processing intensity of the main contract is higher than that of the supplementary agreement.

[0093] Based on the processing intensity assessment results, the system selects the processing result with the strongest processing intensity from all contract data processing results as the evidence information for the second contract data. The selection logic follows the "intensity priority" principle, meaning that the processing result of the contract data with the highest processing intensity value will be selected first. The processing result includes the data identifier obtained through the hash generation function, the associated data after smart contract parsing and BIM model integration, the node signature set in the consensus verification result, and information such as the block height and transaction ID after the data is uploaded to the blockchain.

[0094] Once evidence storage information has been determined for each of the second contract data sets, the system enters the comprehensive evidence storage phase. For each second contract data set, corresponding evidence storage information is generated based on its processed results (such as hash values ​​of multiple contract data sets, integrated related data, verification signatures, etc.). The evidence storage information is stored in a structured format, including fields such as contract data identifier, processing strength value, processing result timestamp, and blockchain node identifier. A Merkle tree structure is used to associate multiple data sets, ensuring the integrity and traceability of the evidence storage records.

[0095] During parameter collection, the system obtains raw data in real time through the blockchain node's log system, avoiding errors caused by human intervention. The log records include detailed information such as the start and end times of processing each contract data point, operation type (e.g., hash calculation, smart contract call), and data transmission volume, providing a reliable basis for processing intensity assessment. Simultaneously, the system supports historical parameter query and recalculation functions, allowing for the retrieval of historical parameters for processing intensity verification during subsequent audits or dispute resolution, ensuring the transparency and auditability of the evidence preservation process.

[0096] It should be noted that the processing intensity assessment model is not fixed; the system allows project managers to customize parameter weights based on project characteristics. For example, in projects with high timeliness requirements, the weights of processing time and frequency can be increased; in scenarios with high data complexity, the weights of data type and data size can be increased. This flexible design enables the system to adapt to the evidence preservation needs of different engineering scenarios, enhancing the practicality of the solution.

[0097] Furthermore, when the same second contract data corresponds to three or more contract data, the processing flow remains consistent: processing parameters for each contract data are collected one by one, processing intensity values ​​are calculated, and the processing result with the highest intensity is selected as the evidence information. For example, if a certain second contract data corresponds to three subcontracting contracts, namely steel structure subcontracting (structured, 300KB), curtain wall subcontracting (semi-structured, 600KB), and decoration subcontracting (unstructured, 1MB), the system calculates the processing intensity values ​​for each of the three, and finally selects the processing result of the steel structure subcontracting contract with the highest intensity as the evidence information.

[0098] Example 4:

[0099] When the system processes multiple contract data corresponding to the second contract data, it is necessary to further determine the integrity of the processing parameters and the consistency of the data characteristics to optimize the calculation logic of the processing intensity. The specific implementation is as follows:

[0100] The system determines whether all the contents included in the processing parameters of each contract data contain the processing frequency and / or data type of the contract data. The processing frequency refers to the number of operations performed by the blockchain node on the contract data per unit time, and the data type refers to the degree of structuring of the contract data (such as structured, semi-structured, unstructured). If the judgment result is negative, that is, the processing frequency and data type are not included in the processing parameters, the operation of determining the processing intensity according to the processing parameters is directly executed, and no data feature analysis is required.

[0101] If the judgment result is positive, that is, the processing parameters include the processing frequency and / or data type, the system needs to first determine the data characteristics of each contract data. The data characteristics include data format and data structure: the data format refers to the file type (such as PDF, XML, JSON, etc.), and the data structure refers to the internal organization form of the data (such as tree structure, table structure, key-value pair structure, etc.). For example, a certain contract data is in XML format, and its data structure presents a tree-like hierarchy, including a root node, child nodes, and attribute values; another contract data is in PDF format, and its data structure is an unstructured text stream without clear field division.

[0102] The system determines whether the data characteristics of each contract data in all contract data are the same. If the data characteristics are the same (such as all contract data are in XML format and have a similar tree structure), the operation of determining the processing intensity according to the processing parameters is triggered. At this time, there is no need to correct the processing parameters, and the intensity value can be directly calculated based on the original parameters.

[0103] If the data characteristics are different (such as some contract data are in structured XML format and some are in unstructured PDF format), the data characteristic difference processing process is entered. First, the system extracts the contract data with the minimum processing time (that is, the contract data with the earliest node start processing time) as the reference data, and groups it pairwise with each contract data in the remaining all contract data to obtain at least one data group. Each data group contains the reference data and one other contract data. For example, assume there are three contract data A, B, and C, with processing times t1, t2, and t3 (t1 < t2 < t3) respectively. Then the reference data is A, and the data groups are (A, B) and (A, C).

[0104] For any given dataset, the system sequentially calculates the feature differences between data features of the same type. Taking dataset (A, B) as an example, if A is in XML format (structured) and B is in PDF format (unstructured), their data formats are different, so there's no need to calculate format differences. However, if both A and B are in XML format but have different structures (e.g., A's root node is "Contract" and B's root node is "Agreement"), then structural differences need to be calculated. The method for calculating structural differences is as follows: compare the field hierarchy depth, number of nodes, and number of attribute key-value pairs between the two datasets, and measure the degree of structural difference by the proportion of differing fields. Assuming A has a field hierarchy depth of 3 levels, 10 nodes, and 5 attribute key-value pairs; and B has a field hierarchy depth of 2 levels, 6 nodes, and 3 attribute key-value pairs, then the formula for calculating the degree of structural difference is:

[0105] ;

[0106] in, For structural differences, and The data structure hierarchy depths of A and B are respectively. and These represent the number of nodes, and These represent the number of attribute key-value pairs. This formula uses standardized differences to quantify structural differences into values ​​within the range [0,3], with larger values ​​indicating greater differences.

[0107] After calculating the feature differences between two contract data sets within the data group, the system needs to determine the target correction data that matches the correction method. The correction method is determined based on a combination of processing time and data characteristics: if the baseline data (with the shortest processing time) has a more complex data structure (e.g., a higher degree of structure), then the contract data with a longer processing time and simpler data structure is selected as the target correction data; conversely, if the baseline data has a simpler structure, then the contract data with a more complex structure is selected as the target correction data. For example, in data group (A, B), if A is structured XML data and B is unstructured PDF data, and A has a higher structural complexity than B, then the target correction data is B, because it has lower processing difficulty but a longer processing time, and its processing priority needs to be increased through correction parameters.

[0108] After determining the target correction data, the system adjusts the processing frequency and / or data type of the target correction data based on the characteristic differences between data groups. The correction rules are as follows: if the data feature differences are... If the value exceeds a preset threshold (e.g., 1.5), the processing frequency of the target correction data will be increased. (For example, increase by 50%), and label the data type as "complex" (e.g., unstructured data as "complex", semi-structured data as "medium", and structured data as "simple"); if the variance is less than or equal to the threshold, only fine-tune the processing frequency (e.g., increase by 20%). For example, if B is unstructured PDF data, the feature variance... Then its processing frequency is from Adjusted to The data type is marked as "complex".

[0109] Once the corrected processing parameters for all data sets are determined, the system executes the operation of determining the processing intensity based on these parameters. At this point, the corrected processing parameters (such as the adjusted processing frequency and data type labeling) will participate in the processing intensity calculation, making the processing intensity assessment more closely reflect the differences in data characteristics. For example, if the processing frequency of data B is increased after correction, and the data type label is "complex," its processing intensity value may increase due to the increased frequency, but because of the deduction in points for type complexity, the final intensity value needs to be recalculated.

[0110] During the data feature difference processing, the system ensures the rationality of the correction logic through the following steps:

[0111] Data Feature Extraction Module: Employing Natural Language Processing (NLP) technology and document parsers, this module automatically identifies the format and structure of contract data. For example, it extracts node levels using an XML parser and identifies unstructured content using a PDF text extraction tool.

[0112] Difference Calculation Engine: Based on the above formulas and preset rules, it quantifies the differences in data characteristics to provide a basis for corrective decisions.

[0113] Parameter correction controller: Based on the difference calculation results and correction rules, it automatically adjusts the processing frequency and data type marking to ensure the consistency and traceability of correction operations.

[0114] It should be noted that processing time is used as the grouping benchmark because data processed earlier usually already occupies node resources. Subsequent data needs to have its processing priority adjusted based on its characteristic differences from the benchmark data to balance node load and processing efficiency. Furthermore, the parameters in the data characteristic difference formula (such as layer depth and number of nodes) can be expanded according to the characteristics of engineering contract data. For example, dimensions such as field type (numerical, text) and component types associated with the BIM model can be added to improve the comprehensiveness of the difference calculation.

[0115] When the number of contract data is N (N≥3), the grouping logic is as follows: the benchmark data and the remaining N-1 data are respectively divided into N-1 data groups. Each data group independently performs feature difference calculation and parameter correction to ensure that each non-benchmark data is compared with the benchmark data, avoiding complex cross-comparison between multiple data and reducing computational complexity.

[0116] Example 5:

[0117] Once the revised processing parameters are determined, the system needs to dynamically update the calculation process for processing intensity to ensure the accuracy and timeliness of the evidence storage information. The specific implementation method is as follows:

[0118] After the system completes the correction of the processing parameters for the target data (such as adjusting the processing frequency and marking the data type as "complex"), it triggers a re-acquisition process to obtain the processing parameters for each contract data corresponding to the second contract data from the blockchain node in real time. These parameters include the original processing parameters (such as processing time and data size) and the corrected parameters (such as the adjusted processing frequency and data type marking), forming an updated parameter set. For example, if the original processing frequency of a certain contract data is once per second, and it is adjusted to 1.5 times per second after correction, and the data type is marked from "semi-structured" to "complex semi-structured", the system needs to synchronize these updated parameters to the processing intensity calculation module.

[0119] Based on the reacquired processing parameters, the system initiates the processing intensity update process. The update process follows the same logic as the initial calculation, namely, calculating the processing intensity value for each contract data point using a multi-dimensional parameter comprehensive evaluation model, but replacing the original parameters with revised ones. For example, when calculating the processing frequency dimension score, the adjusted 1.5 times / second is used instead of the original 1 time / second; when scoring the data type dimension, points are deducted according to the "complex semi-structured" label (e.g., if the original score for semi-structured data is 80 points, marking it as "complex" deducts 10 points, resulting in a score of 70 points).

[0120] After the processing strength update is complete, the system enters a re-filtering process. Based on the updated processing strength value, it re-filters the processing results corresponding to the strongest processing strength from all contract data processing results. The filtering logic still follows the "strength priority" principle, that is, the processing result of the contract data with the highest processing strength value will be determined as the new evidence storage information. For example, if a contract data had a processing strength value of 90 points before the correction, and after the correction, due to the increased processing frequency and adjustment of data type complexity, the strength value increases to 95 points, exceeding the strength values ​​of other contract data, then its processing result will replace the original evidence storage information.

[0121] The re-screening results must be encapsulated according to the blockchain notarization format, including the updated processing strength value, corrected processing parameters, processing result timestamp, and other information. A smart contract then triggers the update operation of the notarization information. The update operation involves appending a new transaction record to the blockchain distributed ledger. This record includes the hash value of the original notarization information, the hash value of the corrected notarization information, and the update timestamp, ensuring the traceability of the notarization history.

[0122] Once the evidence storage information is re-screened and stored, the system automatically triggers the blockchain query function to retrieve and verify the newly stored information. The retrieval process calls the API provided by the blockchain node, inputting the unique identifier of the evidence storage information (such as contract number + timestamp) to obtain the corresponding block data and transaction details. When parsing the retrieved evidence storage information, the system needs to verify the following:

[0123] Hash consistency: Compare the stored hash value of the processing result with the hash value of the re-filtered processing result to ensure that the data has not been tampered with;

[0124] Timestamp order: Check whether the updated timestamp is later than the original stored timestamp to ensure the correctness of the operation order;

[0125] Node signature validity: Verifies whether the blockchain node's signature on the updated evidence information complies with the consensus mechanism requirements, ensuring the legality of the operation.

[0126] After parsing, the system organizes the verified evidence information into a final evidence storage result, outputting it in a structured format (such as a JSON file) or a visual interface. The final evidence storage result includes the following core content:

[0127] Basic contract data information: contract number, names of Party A and Party B, signing date, etc.;

[0128] Processing parameter details: original processing time, data size, corrected processing frequency, and data type;

[0129] Processing intensity assessment results: scores for each dimension, overall intensity value, and ranking;

[0130] Blockchain evidence storage records include: block height, transaction ID, evidence storage timestamp, and list of verification nodes.

[0131] During the dynamic updating of processing strength, the system ensures real-time performance at each stage through an event-driven mechanism. For example, when the revised processing parameters are generated, an update command is sent to the processing strength calculation module via a message queue; after the evidence storage information is updated, a notification message is sent to the user terminal, indicating that the evidence storage status has changed. This mechanism ensures the timeliness of the system in key operations such as parameter correction, strength update, and evidence storage information replacement, avoiding inconsistencies in evidence storage information due to delays.

[0132] Furthermore, the system supports manual intervention during the intensity update process. For example, engineering managers can view the corrected processing parameters and updated intensity values ​​through the backend management interface. If they disagree with the results, they can pause the automatic update process, manually adjust the parameter weights or correct the rules, and recalculate the processing intensity. This human-computer interaction design ensures the system's automation efficiency while providing an interface for human decision-making in special scenarios, thus enhancing the flexibility of the solution.

[0133] It should be noted that the frequency of re-acquiring processing parameters is related to the system's set update cycle. In scenarios with high real-time requirements, the update cycle can be set to the second level to ensure that the corrected parameters are used in strength calculations in a timely manner; in non-real-time scenarios, it can be set to the minute or hour level to reduce the load on blockchain nodes. The update cycle can be dynamically adjusted through the system configuration interface to adapt to the network environment and data processing needs of different engineering scenarios.

[0134] When multiple second contract data exist simultaneously, the above process is executed independently for each second contract data. For example, a project contains two second contract data groups, each corresponding to a different set of contract data. The system performs parameter correction, strength update, and evidence information filtering on each group of data, and finally generates independent evidence records for each group, displaying the processing status and result comparison of each group in the overview interface.

[0135] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0136] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based method for storing engineering contracts using BIM, characterized in that, The method includes: When an engineering contract data submission event is detected, the engineering contract data is processed based on BIM model data and blockchain evidence storage function. Based on the processed engineering contract data, determine the evidence storage information corresponding to the engineering contract data submission event; The project contract data submission event involves multiple contract data, each of which corresponds to BIM model data, and each of the contract data needs to be processed. The method further includes: Determine whether at least two of the aforementioned engineering contract data were simultaneously submitted separately; If the judgment result is negative, the operation of determining the evidence storage information corresponding to the engineering contract data submission event based on the processed engineering contract data is executed. When the judgment result is yes, it is determined whether there is a second contract data among all the engineering contract data. The second contract data is the contract data that the corresponding blockchain storage function can process multiple contract data at the same time. When it is determined that the second contract data does not exist, the operation of determining the evidence storage information corresponding to the project contract data submission event based on the processed project contract data is executed. The method further includes: When it is determined that the second contract data exists, for any piece of the second contract data: The processing parameters of each contract data processed by the blockchain notarization function corresponding to the second contract data are obtained, and the processing strength of the blockchain notarization function of the second contract data for each contract data is determined according to all the contents included in the processing parameters of the second contract data for each contract data. The processing result of the contract data with the strongest processing strength is selected from the processing results of all the contract data as the notarization information of the second contract data. The determination of evidence storage information corresponding to the submission event of the engineering contract data based on the processed engineering contract data includes: When evidence storage information is determined for each of the second contract data in all the second contract data, the evidence storage information corresponding to that second contract data is determined based on the processing result of each processed second contract data.

2. The BIM-based blockchain engineering contract notarization method according to claim 1, characterized in that, The blockchain evidence storage function includes one or more of the following: hash generation function, smart contract function, consensus verification function, and data on-chain function; The process of processing the engineering contract data based on BIM model data and blockchain notarization includes: The engineering contract data is processed based on the hash generation function to obtain a first hash value. When the first hash value meets preset conditions, the data identifier corresponding to the first hash value is determined according to a pre-set hash-data mapping relationship, and is used as the processing result of the engineering contract data; and / or, Based on the smart contract function, the engineering contract data is parsed to obtain first parsed data, and second parsed data sent by the BIM model data is obtained. The first and second parsed data are then integrated to obtain the processing result of the engineering contract data; and / or, Based on the consensus verification function, the validity of the engineering contract data is verified, and the verification result is parsed to obtain the processing result of the engineering contract data; and / or, Based on the data on-chain function, the engineering contract data is written into the blockchain distributed ledger, and the writing result is parsed to obtain the processing result of the engineering contract data.

3. The BIM-based blockchain engineering contract notarization method according to claim 1, characterized in that, The processing parameters for each contract data include one or more of the following, centered on the location of the node corresponding to the blockchain notarization function: processing time, processing frequency, data size, and data type.

4. The BIM-based blockchain engineering contract notarization method according to claim 1 or 3, characterized in that, The method further includes: Determine whether the processing parameters of each contract data include the processing frequency and / or data type of that contract data. When the judgment result is negative, the operation of determining the processing strength of the blockchain evidence storage function of the second contract data for each contract data is performed based on all the contents included in the processing parameters of the second contract data for each contract data. When the determination result is yes, the data characteristics of each contract data are determined, and the data characteristics of each contract data include format and / or structure; Determine whether the data characteristics of each contract data item are the same across all the contract data; When a match is determined, the operation of determining the processing strength of the blockchain notarization function for each contract data is triggered based on all the processing parameters of the second contract data for each contract data.

5. The BIM-based blockchain engineering contract notarization method according to claim 4, characterized in that, The processing parameters for each contract data item include the processing time for that contract data; the method also includes: When a difference is found, the contract data with the shortest processing time is grouped in pairs with each of the remaining contract data to obtain at least one data group. Each data group contains the contract data with the shortest processing time and one other contract data. For any of the data sets mentioned: Based on all the data features of the two contract data in the data group, the feature difference between data features of the same type is calculated sequentially, and based on the feature difference between data features of the same type in the two contract data, the feature difference between the two contract data is calculated; Based on the processing time and data characteristics of each of the two contract data sets, target correction data matching the correction method is determined from the two contract data sets, wherein the correction method is determined comprehensively based on processing time and data characteristics; Based on the characteristic differences between the two contract data sets, the processing frequency and / or data type of the target modified data are corrected to obtain the corrected processing parameters. After the corrected processing parameters corresponding to all the data sets are determined, the operation of determining the processing strength of the blockchain notarization function of the second contract data for each contract data set is performed based on all the contents included in the processing parameters of the second contract data for each contract data set.

6. The BIM-based blockchain engineering contract notarization method according to claim 5, characterized in that, The method further includes: When the modified processing parameters are determined, the processing parameters of each contract data processed by the blockchain notarization function corresponding to the second contract data are re-acquired. The process for determining the processing intensity is updated based on the reacquired processing parameters.

7. The BIM-based blockchain engineering contract notarization method according to claim 6, characterized in that, The method further includes: Based on the updated processing intensity, the processing results of the contract data corresponding to the strongest processing intensity are re-selected; The re-filtered processing results are stored as the evidence information.

8. The BIM-based blockchain engineering contract notarization method according to claim 7, characterized in that, The method further includes: When the evidence storage information is stored, the stored evidence storage information is retrieved based on the blockchain query function; The retrieved evidence information is parsed, and the final evidence storage result is output.

Images