Blockchain-based building engineering quality responsibility tracing and multi-party collaborative supervision method

Abstract

The application relates to the technical field of building engineering quality management and control, in particular to a building engineering quality responsibility tracing and multi-party collaborative supervision method based on a block chain, which comprises the following steps: S100: establishing a block chain network and configuring the access authority and decentralized identity of each participant node, dividing quality data into core quality parameters, quality documents and on-site evidence, adopting the core quality parameters to directly store evidence on the chain, and adopting the distributed storage strategy of synchronously storing the encrypted quality documents and on-site evidence into an IPFS distributed storage network and synchronously chaining the content identifier hash value; S200: based on a BIM model, component-level pin annotation is carried out on the discovered quality problems, three-dimensional space coordinates of the components where the problems are located are collected, and quality problem record files are generated; the application effectively solves the problems of a large-capacity evidence file storage bottleneck and data tamper-proofing consistency by constructing the underlying architecture of "a consortium chain + an IPFS private network" and combining a JSON load with transaction strong binding technology.

Description

Technical Field

[0001] This invention relates to the field of construction engineering quality control technology, specifically to a blockchain-based method for tracing responsibility for construction engineering quality and multi-party collaborative supervision. Background Technology

[0002] Construction projects are characterized by long construction periods, numerous participating entities, and complex overlapping processes. Quality control is crucial throughout the entire lifecycle, from design and construction to acceptance. Clearly defined quality responsibilities and multi-party collaborative supervision are core elements in ensuring project quality. However, existing methods for quality control and accountability in construction projects suffer from the following three major technical deficiencies: Firstly, regarding the preservation and tamper-proofing of quality data, traditional centralized information systems are vulnerable to unilateral data alteration, often resulting in a lack of credible original evidence in the event of a quality dispute. While some existing technologies have introduced basic blockchain-based evidence preservation solutions, they suffer from severe data structure separation and storage bottlenecks: directly uploading large-capacity on-site videos or high-definition inspection reports to the blockchain would lead to a significant decrease in throughput and storage expansion; if only the file's digest hash value is uploaded to the blockchain, there is a lack of a mechanism to bind the file hash to the three-dimensional physical spatial coordinates of the quality issue at the underlying level, making it easy for the spatial positioning data of the engineering site and the off-chain evidence files to be tampered with or replaced separately, and the consistency of the data and the integrity of the evidence chain cannot be fundamentally guaranteed.

[0003] Secondly, regarding the granularity of quality responsibility traceability and the mechanism for assigning responsibility, existing traceability systems suffer from limited data dimensions and overly coarse granularity. When quality and safety hazards arise, current technologies typically only trace responsibility to the macro-level of "participating units," failing to accurately map and bind quality data to specific components and corresponding construction procedures in the BIM model across time and space. Furthermore, responsibility determination heavily relies on manual review of offline records and subjective experience-based deductions, lacking automated, objective reasoning models based on standard specifications. This leads to blurred responsibility boundaries during multi-party cross-operations, easily resulting in buck-passing and extremely low efficiency in collaborative rectification processes.

[0004] Finally, there is an irreconcilable contradiction between existing regulatory compliance verification methods and the protection of business privacy. When disputes arise regarding the determination of responsibility for quality defects, participating entities often have to disclose their core internal construction process parameters (such as real-time mix proportions and pressure curves) and company quality control records to regulatory platforms or third parties without reservation in order to prove their compliance. This approach severely exposes the company's core trade secrets, leading to resistance from participating entities to transparent data sharing. Regulatory authorities find it difficult to conduct efficient compliance verification and dynamic audits while ensuring data privacy and security. Summary of the Invention

[0005] To achieve the above objectives, the present invention provides the following technical solution: This invention provides a blockchain-based method for tracing responsibility for construction project quality and for multi-party collaborative supervision, comprising the following steps: S100: Establish a blockchain network and configure access permissions and decentralized identity identifiers for each participating node. Divide quality data into core quality parameters, quality documents, and on-site evidence. Adopt a distributed evidence storage strategy that directly stores core quality parameters on the chain, encrypts quality documents and on-site evidence, stores them in the IPFS distributed storage network, and synchronizes the content identifier hash value on the chain. S200: Based on the BIM model, the quality problems found are marked with component-level thumbnails, the three-dimensional spatial coordinates of the component where the problem is located are collected and a quality problem record file is generated. The hash value of the quality problem record file and the three-dimensional spatial coordinates are encapsulated in the same evidence storage transaction payload and synchronously uploaded to the blockchain, and the rectification process control smart contract is triggered. S300: The rectification process control smart contract automatically matches the responsible parties based on the attributes of the quality problem, drives the multi-party collaborative rectification process, and extracts the timestamps of the on-chain quality data and the spatial coordinates of the BIM model to construct a quality responsibility association map covering the three dimensions of time, space and responsible parties. S400: When responsibility tracing is initiated, the responsibility determination smart contract calls the quality defect discrimination rule base, combines the spatiotemporal information and subject information in the quality responsibility association graph, automatically infers and calculates the responsibility ratio of each participating subject, and generates a tracing report for on-chain storage.

[0006] Furthermore, in step S100, establishing a blockchain network and configuring the access permissions and decentralized identity identifiers of each participating node specifically includes: A licensed consortium blockchain underlying network is built, and six types of core nodes are independently deployed, including construction units, design units, construction units, supervision units, testing institutions, and government regulatory departments. A role-based access control (RBAC) mechanism is adopted to configure the construction unit with full access to project data, the design unit, construction unit and supervision unit with access to quality data within their respective responsibilities, and the government regulatory department with full audit and supervision permissions. A unique decentralized identity identifier (DID) is generated for each participating entity, and smart contracts for quality data storage, rectification process control, and liability determination are deployed simultaneously. After dividing the quality data, the process also includes standardization preprocessing and data source verification of the collected quality data. Data collection nodes are divided according to the four stages of architectural engineering: design, production, construction and acceptance. All collected quality data undergoes format standardization conversion, integrity verification and sensitive information desensitization. For multi-source quality data in the same process, a common source verification mechanism is introduced. The consistency of data between different data sources is verified by cross-comparison. If there is a deviation in the comparison, the data is marked as abnormal and pushed to the corresponding responsible node for review and correction, so as to ensure that the original quality data before being uploaded to the chain is true and accurate.

[0007] Furthermore, in step S100, the quality documents and on-site evidence are stored in the IPFS distributed storage network, specifically employing a storage strategy that combines private deployment with asymmetric encryption. The IPFS distributed storage network adopts a private node deployment mode, allowing only authorized nodes within the permissioned consortium blockchain network to access it. Quality documents and on-site evidence uploaded to the IPFS distributed storage network are encrypted and stored using the public key of the corresponding participating entity, and only authorized entities holding the corresponding private key have the right to decrypt and read them; All distributed evidence storage operations are automatically invoked and executed by the quality data evidence storage smart contract for format verification and permission verification. Only after the verification is passed can on-chain hash synchronization and off-chain storage be completed. The core quality parameters include component strength, installation accuracy, and material properties; the quality documents include inspection reports and acceptance records; and the on-site evidence includes on-site photos and video surveillance. When establishing a trusted mapping relationship between on-chain hash index and off-chain file, the content identifier hash value, file category and corresponding process information are encapsulated into a storage index tuple and written into the blockchain state database to realize the corresponding retrieval of on-chain index and off-chain encrypted file based on the unique component code.

[0008] Further, in step S200, the quality data is mapped and component-level pin annotations are performed based on the BIM model, specifically including: A mapping mechanism for the association of two tables is established, in which the BIM client deploys the BIM component metadata table locally, and the blockchain status database stores the on-chain evidence index table. The two tables are associated with the unique code of the BIM component as the primary key and foreign key, so as to realize the one-to-one correspondence between the spatial data of the BIM model and the on-chain evidence data. When quality issues are discovered during engineering inspections, quality issue pins are marked at the corresponding locations in the 3D space of the BIM model and precisely bound to individual BIM components and specific parts. Acquire three-dimensional spatial coordinates and generate a quality problem record file, specifically including: Collect the millimeter-level three-dimensional spatial coordinates (X,Y,Z) of the quality problem pins in the world coordinate system of the BIM model, as well as the unique component code of the component where the problem is located; Collect the problem type, severity level, rectification requirements, and rectification deadline, and generate a standardized quality problem record file by combining the three-dimensional spatial coordinates and the unique code of the component.

[0009] Furthermore, in step S200, the hash value and three-dimensional spatial coordinates of the quality problem record file are encapsulated in the same evidence storage transaction payload and synchronously uploaded to the blockchain, specifically using a JSON structured encapsulation format: The transaction type identifier, unique issue number, unique component code, millimeter-level three-dimensional spatial coordinates, IPFS content identifier hash value of the quality issue record file, issue type, severity level, decentralized identity identifier of the operating entity, and timestamp are all uniformly encapsulated in the JSON payload of the same evidence storage transaction. The three-dimensional spatial coordinates and the hash value share the same transaction hash and timestamp, forming a strong technical binding that is indivisible and cannot be tampered with individually under the solidification of the blockchain consensus mechanism; The smart contracts that trigger the rectification process control include: While the notarized transaction payload is uploaded to the blockchain, the quality data notarization smart contract automatically calls the rectification process control smart contract to convert the generated quality problem record into an on-chain rectification event to be processed, and pushes a rectification notification containing spatial coordinates and problem details to the matching responsible node.

[0010] Furthermore, in step S300, the multi-party collaborative rectification process is driven by the rectification process control smart contract, specifically including: The rectification process control smart contract automatically matches the responsible entity, rectification execution entity, and review and acceptance entity based on the professional field, process, and scope of responsibility of the quality problem, and sends rectification notifications to the corresponding nodes. After completing the rectification, the entity responsible for rectification uploads the rectification record and the evidence file after rectification, and their hash values ​​are synchronously uploaded to the blockchain. The review and acceptance entity uses the original records and rectification materials online to perform tiered acceptance: general quality issues are handled by the supervision unit node in a single closed-loop acceptance process, while major quality issues are handled by the supervision unit node and the construction unit node in a sequential closed-loop acceptance process; if the acceptance fails, a second rectification process is automatically triggered. The quality responsibility association graph adopts a directed attribute graph model structure, including a tuple data structure of nodes and edges: The nodes are divided into quality event nodes and responsible entity nodes. The quality event node tuple contains the event ID, event type code, occurrence timestamp, BIM component code, three-dimensional spatial coordinates (X,Y,Z), process stage, IPFS content identifier hash value of the data file, and operation status. The responsible entity node tuple contains the entity's decentralized identity identifier (DID), entity type, role permissions, associated process scope, associated BIM component set, and historical performance score. The edges are divided into process flow edges and responsibility association edges. The process flow edge tuple includes the start event ID, end event ID, relationship type, time interval, and flow status. The responsibility association edge tuple includes the subject DID, event ID, responsibility type, basic weight, and associated process.

[0011] Furthermore, in step S300, when constructing the quality responsibility association graph, a four-step mapping and fusion rule is adopted for BIM spatial data, blockchain time-series data, and DID identity data: Step 1: Extract the transaction timestamps, event types, and operator DIDs from the blockchain blocks, generate corresponding quality event nodes, and write the occurrence timestamps to complete the time-dimensional graph transformation. Step 2: Extract component codes, 3D coordinates, and process information from the BIM model component library to establish a mapping dictionary. After matching the BIM component codes of the quality event nodes, write them into the spatial coordinates and process fields to complete the spatial dimension map conversion. Step 3: Extract identity identifiers and responsible procedures from the consortium blockchain DID system to generate responsible entity nodes; Step 4: Connect the discovery, assignment, rectification and acceptance event nodes of the same quality problem in the order of timestamps to generate process flow edges, and connect the responsible subject node and the quality event node according to the operator's DID and the responsible process to generate responsibility association edges; The quality responsibility correlation graph supports forward backtracking and backward deduction along the time axis: During forward backtracking, starting from the designated responsible entity node, all quality event nodes and flow paths under its responsibility are retrieved forward along the responsibility association edge and process flow edge; During reverse engineering, starting from the specific quality defect event node, the process is traced back along the flow edge and the responsibility association edge to the specific process that caused the defect, the preceding quality event and the corresponding responsible entity node, and the rectification overdue judgment is made based on the time interval field in the flow edge.

[0012] Furthermore, in step S400, the quality defect discrimination rule base adopts a three-level structured storage of "rule metadata + precondition set + responsibility weight set": The rule metadata layer stores the basic identification information of the rules, including the rule ID, defect type code, applicable process stage, associated specification clause number, and rule effective status. The precondition set layer stores multi-dimensional logical judgment conditions that trigger responsibility determination. The condition dimensions cover defect attributes, construction record status, supervision record status, test data deviation, and time node compliance. The responsibility weight set layer stores the basic responsibility weight coefficients of each participating entity after the preconditions are met, and the sum of the basic responsibility weight coefficients of all related entities is 1. Combining the spatiotemporal information and subject information in the aforementioned quality responsibility correlation map, the responsibility proportion of each participating subject is automatically inferred and calculated, specifically using a multi-factor weighted calculation model of "basic weight × impact factor correction": Extract the basic responsibility weights of the participating entities associated with defects, and calculate the time overlap between the operation node and the defect formation node based on blockchain timestamp data to generate a time correction factor; compare the spatial overlap between the defect location and the construction scope of each entity's responsibility based on BIM spatial coordinate data to generate a spatial correction factor; retrieve the occurrence rate of similar defects of each entity within a recent preset time from the knowledge base to generate a historical performance correction factor. The basic responsibility weight is multiplied by each correction factor to obtain the correction score of each entity. After normalization, the final responsibility ratio of each participating entity is calculated.

[0013] Furthermore, in step S400, after generating the traceability report, a dispute review process based on a zero-knowledge proof mechanism is also included: When the subject being traced has a dispute over the proportion of responsibility, the proof key of the zk-SNARKs algorithm framework is called locally. Commercial data containing construction process parameters or internal quality control records of the enterprise is used as privacy input, and defect type code, quality threshold, subject DID and timestamp range are used as public input. A zero-knowledge proof string is generated and submitted to the responsibility determination smart contract. The liability determination smart contract calls the built-in verification key to perform verification, verifying compliance without disclosing the privacy input. After verification, the compliance certificate is marked as valid and pushed to the government regulatory department node for liability determination adjustment. The entire review process is recorded and the adjudication result is synchronously stored on the blockchain.

[0014] Furthermore, step S400 also includes dynamic audit warnings and knowledge base self-updating based on on-chain evidence storage data: The system includes three types of warning rules: overdue rectification warning, repeated defect warning, and abnormal key indicator warning. When on-chain data triggers the threshold, the rectification process control smart contract will automatically push graded warnings to relevant responsible parties and regulatory department nodes. Regularly aggregate the evidence data within the blockchain network to generate multi-dimensional quality analysis reports. After the closed-loop quality defect cases, cause analysis, responsibility ratio conclusions and handling solutions are reviewed and approved by the regulatory node, the smart contract will automatically synchronize and write them into the quality defect handling knowledge base, so as to realize the continuous updating of the judgment rule base and the handling solution base. Beneficial effects

[0015] This invention effectively solves the bottleneck of large-capacity evidence file storage and the problem of data tamper-proof consistency by constructing an underlying architecture of "consortium blockchain + IPFS private network" combined with JSON payload and transaction strong binding technology. By leveraging BIM component-level spatial mapping and blockchain timestamp sequences, it systematically constructs a quality responsibility association graph covering three dimensions: time, space, and subject, accurately sinking the granularity of responsibility traceability down to the specific component and process levels. Combined with a smart contract-driven automated rectification flow closed loop, an objective quantitative responsibility determination model based on a three-level rule base and multi-factor weighted algorithm, and an objection verification mechanism introducing zk-SNARKs zero-knowledge proof, it significantly shortens the cycle of multi-party collaborative rectification and dispute resolution without disclosing the commercial privacy of all parties, and effectively improves the objectivity and accuracy of responsibility definition and the credibility of penetrating quality supervision. Attached Figure Description

[0016] Figure 1 This is an overall flowchart of the present invention; Figure 2 This is a flowchart of the BIM pin + multi-party collaborative rectification process of the present invention; Figure 3 This is a flowchart of the intelligent responsibility traceability process for quality defects in this invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but includes other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] The present invention will now be described in further detail with reference to the accompanying drawings: Example

[0020] like Figures 1-3 As shown, the blockchain-based method for tracing responsibility for construction project quality and for multi-party collaborative supervision includes the following steps:

[0021] S100: Establish a blockchain network and configure access permissions and decentralized identity identifiers for each participating node. Divide quality data into core quality parameters, quality documents, and on-site evidence. Adopt a distributed evidence storage strategy that directly stores core quality parameters on the chain, encrypts quality documents and on-site evidence, stores them in the IPFS distributed storage network, and synchronizes the content identifier hash value on the chain. S200: Based on the BIM model, the quality problems found are marked with component-level pins, the three-dimensional spatial coordinates of the component where the problem is located are collected and a quality problem record file is generated. The hash value of the quality problem record file and the three-dimensional spatial coordinates are encapsulated in the same evidence storage transaction payload and synchronously uploaded to the blockchain, and the rectification process control smart contract is triggered. S300: The rectification process control smart contract automatically matches the responsible parties based on the attributes of the quality issues, drives the multi-party collaborative rectification process, and extracts the timestamps of on-chain quality data and spatial coordinates of BIM models to construct a quality responsibility association map covering three dimensions: time, space, and responsible parties. S400: When responsibility tracing is initiated, the responsibility determination smart contract calls the quality defect discrimination rule base, combines the spatiotemporal information and subject information in the quality responsibility association graph, automatically infers and calculates the responsibility ratio of each participating subject, and generates a tracing report for on-chain storage.

[0022] Furthermore, the specific implementation process of step S100 is as follows: In the specific implementation process, step S100 is used to construct the infrastructure layer, identity and access control system, and data storage base of the entire construction project quality responsibility traceability and multi-party collaborative supervision system. The specific implementation process and technical details are as follows: 1. Deployment and implementation of permissioned consortium blockchain networks and nodes: During the system initialization phase, a foundational consortium blockchain network based on a permissioned consensus algorithm is established. This network employs either the Raft or PBFT consensus mechanism, with the network communication layer based on a P2P protocol and enabling TLS two-way authentication. Six types of core nodes are independently deployed within the network: nodes representing construction units, design units, construction companies, supervision units, testing agencies, and government regulatory departments.

[0023] Each core node comprises an independently operating blockchain server and a data access client. The blockchain server is responsible for maintaining a local copy of the ledger, executing smart contracts, and participating in block consensus. The data access client provides RESTful API and RPC interfaces to receive business requests from participating parties. Each node is assigned a fixed network IP address and communication port and is issued a digital certificate by a Certificate Authority (CA). Only nodes holding valid CA certificates can access the underlying consortium blockchain network.

[0024] 2. Decentralized Identity (DID) and Role-Based Access Control (RBAC) Configuration: The system generates a decentralized identity identifier (DID) that conforms to W3C standards for each participating entity.

[0025] The DID generation process is as follows: Participating entities generate an ECC elliptic curve public-private key pair (using the secp256k1 curve) on their local client. The public key is then hashed using SHA-256 and RIPEMD-160 algorithms, and combined with a network identifier prefix to form a unique identity string in the form of "did:cn:construction:123456789abcdef". The generated DID, along with the participating entity's identity information and public key, is encapsulated into a DID document and written to the blockchain ledger for network-wide broadcast and trusted storage.

[0026] Regarding access control, the system adopts a role-based access control (RBAC) mechanism, configuring a permission mapping matrix in the underlying blockchain's permission management module. The specific configuration of the mapping matrix is ​​as follows: Configure the role identifier corresponding to the construction unit node as "ROLE_OWNER", grant read permission (READ_ALL) to all project data in the ledger and write permission to the initial parameters of the project; Configure the role identifiers of the design unit node (ROLE_DESIGN), construction unit node (ROLE_CONTRACTOR), and supervision unit node (ROLE_SUPERVISOR), and restrict them to read and write permissions (READ_SCOPE, WRITE_SCOPE) only for the data within their own professional and process responsibilities. Configure the role identifier of the testing agency node (ROLE_TESTING), authorizing it to only submit and sign testing data and testing reports; Configure the role identifier of the government regulatory department node (ROLE_REGULATOR), and grant it full data access permissions (AUDIT_ALL), data authenticity verification permissions, and early warning rule configuration permissions.

[0027] After completing the node and permission configuration, three types of core smart contracts are compiled and deployed to the underlying consortium blockchain network: a quality data notarization smart contract, a rectification process control smart contract, and a responsibility determination smart contract. The smart contracts are written in Solidity or Go, compiled into bytecode by each consensus node, and then written to the underlying blockchain's state database through transaction deployment, completing the initial configuration of the on-chain runtime environment.

[0028] 3. Implementation of full lifecycle quality data classification and standardized preprocessing: Data collection covers the design, production, construction, and acceptance phases of a building project. After the corresponding procedures are completed at each stage, quality data is automatically captured by front-end data acquisition devices or business terminals, or uploaded by operators.

[0029] All collected quality data are divided into three categories according to data attributes and volume: The first category consists of core quality parameters, with data in the form of structured numerical values. Specifically, these include key physical indicators such as the test values ​​of concrete component compressive strength test blocks (unit: MPa), the deviation of the installation axis and verticality of precast components (unit: mm), and the tensile strength and yield strength of steel bars. The second category is quality documents, which are structured or semi-structured electronic documents, specifically including PDF test reports issued by third-party testing agencies, concealed works acceptance records, and construction logs. The third category is on-site evidence, which is in the form of unstructured multimedia files, specifically including high-definition photos of the construction site (JPG / PNG format), video surveillance recordings of concealed procedures (MP4 format), and drone inspection images.

[0030] Before uploading, the collected raw quality data must undergo standardized preprocessing on the client side: Data cleaning and format conversion: Non-standard format data is uniformly converted into JSON structured data packets, with uniform character encoding UTF-8 and uniform timestamp format as millisecond-level UNIX timestamp; Integrity verification: The hash value of the original data is calculated using the SHA-256 algorithm and written as the data integrity check code in the header of the data packet; Sensitive information desensitization: The desensitization algorithm is invoked to perform masking or hashing of sensitive business information (such as contract prices and trade secrets) and personal privacy information (such as construction workers' ID numbers and mobile phone numbers) in the data packet.

[0031] In the preprocessing stage, the system implements a data cross-validation mechanism. For the same work process node, data uploaded from multiple sources is extracted and compared for consistency. For example, for concrete component strength data, data values ​​uploaded by the construction unit for self-inspection are extracted. Data values ​​uploaded independently by the testing agency Calculate the absolute deviation between the two: The system will then calculate the absolute deviation value. $ and the preset allowable deviation threshold Logical comparison is performed: if the absolute deviation value is less than or equal to the allowable deviation threshold, the data is determined to meet the same source consistency standard and is allowed to enter the subsequent on-chain evidence storage process; if the absolute deviation value is greater than the allowable deviation threshold, the system automatically adds an abnormal flag bit to the data packet and pushes the abnormal data packet to the construction unit node and the supervision unit node in real time through the on-chain message channel, blocking the on-chain evidence storage of the current data, requiring the responsible party to re-sample and verify the data on-site until the data after verification and correction passes the same source comparison.

[0032] 4. Implementation of distributed evidence storage and private IPFS network with on-chain and off-chain collaboration: The three types of quality data after preprocessing are stored using a hybrid on-chain and off-chain distributed storage strategy: For core quality parameters, due to the small data volume and extremely high requirements for immutability, the system directly constructs the blockchain transaction data payload using core quality parameters, the operation entity DID, process code, and millisecond-level timestamp. The client initiates a notarization transaction to the underlying consortium blockchain network. After the consensus nodes perform format verification and signature verification, the transaction is packaged into a new block using the Raft or PBFT consensus protocol and written to the blockchain state database, achieving full node synchronization and immutable notarization.

[0033] For large files such as quality documents and on-site evidence, a privately deployed IPFS distributed storage network is used for off-chain storage. The IPFS distributed storage network consists of private IPFS nodes deployed by the participating parties. Swarm keys are used for network isolation within the network, and public IPFS network nodes are prohibited from accessing it.

[0034] The specific process for encrypting and storing large files is as follows: The client generates a 256-bit AES symmetric key and uses the AES-256-GCM algorithm to locally encrypt the original quality document or on-site evidence file to generate an encrypted ciphertext file. The client calls the ECC public key of the target receiver or the consensus node of the whole network to perform asymmetric encryption on the 256-bit AES symmetric key, generate an encrypted key package, and append the encrypted key package to the header of the ciphertext file; The client sends the encrypted file containing the encryption key to the private IPFS node. The IPFS node calculates the hash of the file content based on the content addressing mechanism to generate a unique content identifier (CID, in the form of "QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco"). The IPFS node returns the generated CID to the client.

[0035] After obtaining the CID, the client constructs an on-chain evidence storage transaction. The transaction payload includes the SHA-256 hash of the Content Identifier (CID), the file category code, the corresponding process code, the unique component code, and the operating entity's DID. The client digitally signs the evidence storage transaction using its own DID private key and broadcasts the transaction to the underlying consortium blockchain network.

[0036] Upon receiving a data storage transaction, the smart contract for quality data storage automatically triggers the execution of verification logic. First, retrieve the caller's DID and match it with the RBAC permission matrix in the ledger to verify whether the caller has the data write permission for the current process. Secondly, verify the format validity and hash value length of each field in the transaction payload; If the verification passes, the quality data storage smart contract will construct a storage index tuple consisting of <storage transaction hash, component unique code, quality file CID hash, data type, operating entity DID, and on-chain timestamp>, write it into the blockchain state database, and establish a trusted binding mapping between the on-chain hash index and the off-chain private IPFS encrypted file.

[0037] When an authorized entity needs to access off-chain files, it first retrieves the corresponding evidence index tuple from the blockchain state database based on the unique component code, obtains the quality file CID hash and evidence transaction records, and verifies the integrity of the on-chain data; then, it downloads the encrypted ciphertext file from the private IPFS network using the CID; finally, it uses the private key corresponding to its own DID to decrypt the encrypted key packet in the file header to obtain the AES symmetric key, and then decrypts the ciphertext file to obtain the original quality document or on-site evidence.

[0038] Furthermore, the specific implementation process of step S200 is as follows: 1. Implementation of BIM model import and dual-table association mapping: The system acquires the BIM 3D model corresponding to the building project and establishes a mapping mechanism that links the component codes in the BIM model with the evidence storage data on the underlying blockchain.

[0039] A BIM component metadata table is deployed locally on the BIM client to store component attributes and spatial location data of the BIM model. The data fields of the BIM component metadata table include: a unique component code as the primary key, the component business name, the X-coordinate, Y-coordinate, and Z-coordinate in the world coordinate system, the relevant work process stage, and the responsible entity's DID. The 3D coordinates in the world coordinate system are set to millimeter-level precision. The unique component code is generated using the rule "Project ID-Professional Code-Component Type-Serial Number," and it maintains a one-to-one correspondence with the built-in component IDs generated within the BIM modeling software.

[0040] A blockchain-based evidence storage index table is deployed synchronously in the blockchain state database to store the on-chain index information of all quality data evidence storage, and is automatically maintained by the evidence storage smart contract. The data fields of the on-chain evidence storage index table include: the evidence storage transaction hash as the primary key, the component unique code as the foreign key, the quality file CID hash, the data type, the operation entity DID, and the on-chain timestamp.

[0041] The BIM component metadata table and the on-chain evidence index table are forcibly associated through the component's unique code field. When the system receives the input component's unique code, it synchronously retrieves the corresponding 3D spatial location information in the BIM model on the front end, and retrieves all associated quality evidence data in the back-end status database, thus achieving a one-to-one mapping between the model's 3D space and the on-chain data source.

[0042] 2. Implementation of quality issue pin marking and record file generation: When participating or supervising parties discover quality and safety hazards or defects during on-site engineering inspections, operators load the corresponding BIM 3D model in the BIM client and trigger the marking of quality issue pins at the specific spatial locations of the defects. These quality issue pins utilize component-level spatial positioning precision to accurately attach and bind to the specific surface or internal parts of individual target components in the BIM model.

[0043] Once the annotation action is triggered, the system automatically reads the world coordinate system 3D coordinates (X, Y, Z) of the pin's location and the unique component code of the annotated component. Simultaneously, the system's front-end interface collects the core parameters entered by the operator: problem type, severity level, rectification requirements, and rectification deadline. The system then formats and assembles the 3D coordinates, unique component code, and the aforementioned four parameters to generate a standardized quality problem record file.

[0044] 3. Structured encapsulation and strong binding of transaction payloads for on-chain implementation: To prevent spatial coordinates and evidence files from being tampered with separately during network transfer and storage, the system uses a structured encapsulation method with the same transaction payload to achieve a strong technical binding of the underlying data, combining the hash value of the quality problem record file with the spatial coordinates of the thumbtack.

[0045] The hash value and 3D coordinates of the quality issue record file are encapsulated in the same blockchain evidence storage transaction payload. Synchronization with the blockchain is achieved through a single consensus process, ensuring that the hash and coordinates are indivisible and cannot be tampered with individually. The on-chain evidence storage transaction payload uses a JSON structured format, and the specific field mapping structure is configured strictly according to the following rules: the `tx_type` field maps to the evidence storage transaction type identifier, assigned by the system as `quality_issue_deposit`; the `issue_id` field maps to the unique issue number assigned by the system; the `component_code` field maps to the unique code of the extracted BIM component; the `pin_coordinate` field maps to a nested set of 3D coordinates, containing x-axis, y-axis, and z-axis coordinate values ​​accurate to the millimeter level; the `issue_file_hash` field maps to the hash value of the content identifier corresponding to the aforementioned quality issue record file in the IPFS network; the `issue_type` field maps to a text description of the specific quality defect type; the `severity` field maps to the severity level of the issue; the `operator_did` field maps to the decentralized identity identifier of the entity that triggered the annotation operation; and the `timestamp` field maps to the millisecond-level timestamp when the evidence storage operation was triggered.

[0046] After the notarized transaction containing the aforementioned JSON payload is broadcast to the consensus nodes and packaged into a block, the three-dimensional spatial coordinate data and the hash value of the quality issue record file share the same blockchain transaction hash and the same block timestamp in the underlying chain structure. The underlying blockchain consensus mechanism solidifies the coordinate data and file hash into an inseparable whole. Any attempt to modify the coordinate values ​​or replace the file hash will cause a cascading effect on the original transaction hash value, completely changing it and being identified as an invalid tampering operation by all consensus nodes in the network, thus ensuring the strong consistency and immutability of the binding between spatial coordinates and file hash.

[0047] 4. Implementation of automated event triggering for smart contracts: After the evidence storage transaction corresponding to the quality issue pin completes the network consensus, is confirmed on the chain, and written to the state database, the event listening module at the bottom layer of the blockchain listens to the newly generated evidence storage transaction event in real time, and then triggers the quality data evidence storage smart contract to automatically call the rectification process management smart contract deployed on the chain.

[0048] The rectification process control smart contract receives the call instruction, parses the aforementioned on-chain JSON payload data, automatically extracts the professional and location parameters of the problem, and initiates the subsequent automated rectification collaboration process.

[0049] Furthermore, the specific implementation process of step S300 is as follows: In practical implementation, step S300 is used to automate the multi-party collaborative rectification process driven by smart contracts, and to construct a three-dimensional quality responsibility correlation map of "time-space-subject". The specific implementation process and technical details are as follows: 1. Smart contract-driven multi-party collaborative rectification process and tiered acceptance: After the quality issue evidence storage transaction is completed and uploaded to the blockchain in step S200, the rectification process control smart contract automatically parses the JSON data in the on-chain transaction payload and extracts the unique issue number, unique component code, severity level, rectification requirements, and rectification deadline.

[0050] The rectification process control smart contract retrieves the responsibility configuration matrix from the ledger based on the extracted component unique code and process stage, automatically matching the responsible entity DID, rectification execution entity DID, and review and acceptance entity DID corresponding to the current quality issue. Subsequently, the rectification process control smart contract sends an on-chain rectification notification to the rectification execution entity node and marks the current issue's flow status as pending rectification (Flow_Status=0x01) in the blockchain status database.

[0051] Upon receiving the rectification notice, the entity responsible for rectification organizes on-site personnel to carry out quality rectification work. After rectification is completed, the entity's client encrypts and uploads the rectification implementation record, post-rectification on-site photos, and third-party testing report to the private IPFS network to obtain a Content Identifier (CID). The entity's client constructs a transaction containing the rectification record's CID hash and the rectification completion event, digitally signs it, and broadcasts it to the blockchain network. After successful notarization, the rectification process control smart contract automatically updates the flow status to "Pending Acceptance" (Flow_Status=0x02) and pushes an online acceptance notification to the review and acceptance entity node.

[0052] The main node for review and acceptance retrieves original quality issue records and rectification submission materials online, executing a tiered closed-loop acceptance process: First, the rectification process control smart contract reads the severity field from the transaction payload. When the severity field is at the general level (severity=general), the rectification process control smart contract sets the closed-loop approval chain to a single-level closed loop. After the supervisory unit node retrieves and verifies the materials, it submits an acceptance transaction containing acceptance opinions and signature data to the chain. If the acceptance opinion field is "passed" (Opinion=0x01), the rectification process control smart contract marks the issue's flow status as closed-loop (Flow_Status=0x03), completing a single closed loop for a general quality issue.

[0053] When the severity level field is set to critical (severity=critical), the rectification process control smart contract automatically activates a two-level closed-loop mechanism.

[0054] In the first stage, the supervision unit node conducts the initial review. After the supervision unit node submits its approval opinion, the issue flow status is updated to the initial review approved and awaiting re-review status (Flow_Status=0x02A), and a re-review notification is automatically pushed to the construction unit node. In the second stage, the construction unit node retrieves the complete set of materials and the supervisor's preliminary review opinions for review. After the construction unit node submits the transaction and the review is approved, the rectification process control smart contract party updates the flow status to the closed loop status (Flow_Status=0x03).

[0055] If, during a single-level or two-level acceptance process, any audit node submits an acceptance opinion of "Opinion=0x00," the rectification process control smart contract automatically resets the rectification period, generates a secondary rectification event notification, resets the flow status to a secondary pending rectification status (Flow_Status=0x01B), and resends a warning notification to the rectification execution entity node. Throughout the entire rectification process, each node's receiving, submitting, auditing, and rejecting actions are packaged in real time into independent blockchain transactions, ensuring full-process traceability and evidence preservation.

[0056] 2. Implementation of the data model and tuple structure for the directed attribute graph responsibility graph: To structurally integrate the spatiotemporal and identity data scattered across blockchain and BIM models, the system employs a directed attribute graph model to construct a quality responsibility association graph covering three dimensions: time, space, and responsible entity. Data elements in the graph include quality event nodes, responsible entity nodes, process flow edges, and responsibility association edges, all defined with a fixed tuple attribute structure.

[0057] The tuple structure of a quality event node is defined as follows: ; in, A globally unique identifier for quality events; Code the event type (distinguish between data upload, problem discovery, rectification submission, and acceptance). Millisecond-level block timestamps; A unique code is assigned to each BIM component; The coordinates are in millimeter-level world coordinates; Stage represents the construction process stage. Store the CID hash of the file in IPFS; This indicates the current operational state of the event.

[0058] The tuple structure of the responsible entity node is defined as follows:

[0059] in, Decentralized identity identifiers for participating entities; As the main type; RBAC role permission identifier; The scope of work processes under responsibility; The associated set of BIM component codes; Scoring based on historical quality of contract performance.

[0060] The tuple structure of the process flow edge is defined as follows:

[0061] in, and These are the start event node number and the end event node number, respectively; The flow relationship type (including "discovery-dispatch", "dispatch-rectification", "rectification-acceptance"); This represents the time interval between two adjacent events. This represents the state of the flowing edge.

[0062] The tuple structure of responsibility-related edges is defined as follows:

[0063] in, and These are the main node identifier and the event node number, respectively; The type of liability attribution (including direct liability, supervisory liability, and management liability); The initial basic responsibility weights are retrieved from the rule base; Stage represents the corresponding construction procedure.

[0064] 3. Four-step mapping and fusion algorithm for multi-source heterogeneous data: When constructing the quality responsibility association graph, the system calls the graph database service engine and, according to the following four-step mapping and fusion rules, uniformly maps and merges blockchain time-series data, BIM spatial data, and DID identity data into a directed attribute graph: Step 1: Perform time-series data mapping. The graph database service engine subscribes to the underlying blockchain ledger, extracts all blockchain transactions related to quality evidence storage, and parses the transaction timestamp, event type code, transaction hash, and operator DID within the transaction body. The engine instantiates a quality event node for each transaction, writes the block transaction timestamp into the node's Timestamp attribute, and completes the graph transformation of the time-dimensional data.

[0065] Step 2: Perform spatial data mapping. The graph database service engine retrieves the local BIM component metadata table and constructs a spatial mapping dictionary:

[0066] When the generated quality event node contains When accessing attributes, the engine retrieves the space mapping dictionary. The corresponding millimeter-level three-dimensional coordinates (X,Y,Z) and process stage are extracted and written into the (X,Y,Z) and Stage attribute fields of the quality event node, thus completing the graph transformation of the spatial dimension data.

[0067] Step 3: Perform identity data mapping. The engine extracts the consortium blockchain DID registry and permission configuration file. Each registered participating entity is instantiated in the graph to generate a responsible entity node. The entity's DID is used as the primary key attribute Subject_DID of the node, and the entity's role and scope of authority are filled into the Role_Auth and Scope_Stage attribute fields, respectively.

[0068] Step 4: Perform relationship binding and edge construction.

[0069] For process flow edges: The engine sorts all quality event nodes under the same unique problem number in ascending order by the Timestamp attribute, generating a time-series event linked list. The engine establishes directed process flow edges between adjacent quality event nodes in chronological order. During this process, the engine automatically calculates the time difference between two adjacent event nodes.

[0070] The engine will calculate the millisecond-level values. Fill in the Time_Interval attribute of the process flow edge.

[0071] For responsibility association edges: The engine parses the operator DID and the responsibility attribution of BIM components in the quality event nodes, and establishes directed responsibility association edges between the corresponding responsible entity nodes and the quality event nodes. The engine retrieves the discrimination rule library, and writes the initial responsibility type and preset basic weight coefficients into the Resp_Type and Base_Weight attributes of the responsibility association edges according to the event type and process stage, thus completing the construction of the "time-space-entity" three-dimensional quality responsibility association map.

[0072] 4. Algorithms for forward backtracking and backward deduction of the graph: The generated quality responsibility association graph is deployed in a graph database, supporting two types of graph retrieval algorithms: forward backtracking and backward deduction.

[0073] The implementation process of the forward backtracking algorithm is as follows: When it is necessary to query the performance trajectory of a certain participating entity, the Subject_DID of the target entity is input. The graph database service engine takes the corresponding responsible entity node as the starting point, finds all the associated quality event nodes along the responsibility association edge, and then performs breadth-first search (BFS) along the process flow edge to traverse all the rectification flow paths and final closed loop status of the quality issues that the target entity has participated in.

[0074] The implementation process of the reverse inference algorithm and overdue calculation is as follows: When the traceability program is started for a certain quality defect, the Event_ID of the target quality defect event node is input. The engine takes the target node as the starting point, reverses along the flow edge to perform a depth-first search (DFS), and forwards back the complete path of the problem from discovery, assignment to rectification, until the initial construction event node and the corresponding responsible entity node that caused the problem are located.

[0075] During the reverse engineering process, the engine automatically extracts the Time_Interval attribute value from the process flow edges. And retrieve the rectification time limit preset in the evidence storage transaction. Calculate the timeout difference for rectification:

[0076] If the calculated difference The engine determines that the current workflow node has an overdue violation, automatically adds an overdue flag (Overdue_Flag=0x01) to the Flow_Status attribute of the workflow edge, and sets the calculated overdue duration. As input parameters for subsequent responsibility determination and performance evaluation.

[0077] Furthermore, the specific implementation process of step S400 is as follows: In practical implementation, step S400 is used to realize intelligent responsibility reasoning calculation for quality defects, review of objection appeals under zero-knowledge proof privacy protection, dynamic audit early warning, and self-iterative updating of the quality defect knowledge base. The specific implementation process and technical details are as follows: The responsibility determination smart contract invokes the built-in quality defect identification rule library. The quality defect identification rule library is stored in the blockchain state database using a three-level structured data structure: "rule metadata + precondition set + responsibility weight set". The first layer is the rule metadata layer, which defines the basic retrieval identifiers for rules. The field combination tuple is as follows:

[0078] in, Each rule has a unique identifier; Code the type of quality defect; For applicable process stages; For the relevant national or industry engineering quality acceptance standard clause number; The rule is in effect.

[0079] The second layer is the precondition set layer, which stores multi-dimensional judgment conditions that trigger the liability determination logic, supporting combinations of logical AND, logical OR, and logical NOT. The logical conditions for the judgment dimensions include defect attribute matching, construction record status, supervisor's on-site monitoring record status, third-party testing data deviation, and compliance of process time nodes.

[0080] The third layer is the responsibility weight set layer, which stores the initial basic responsibility weight coefficients of each associated participating entity after the preconditions are met. The value range of the basic responsibility weight coefficient is set between 0 and 1, and for the same defect rule, the sum of the basic responsibility weight coefficients of all associated entities is limited to 1.

[0081] Taking the rule for incomplete grouting at precast wall panel joints (Rule_ID=RULE-PC-007) as an example, the rule configuration is as follows: The metadata layer is configured as follows: Defect_Code=DEF-023, Stage=Precast wall panel installation procedure, Standard_No=Article 6.5.8 of "Technical Standard for Prefabricated Concrete Structures" GB / T51231-2016; The precondition set is configured as a logical AND combination: Condition 1 (defect type equals incomplete grouting) AND Condition 2 (construction unit's grouting pressure or duration record is abnormal) AND Condition 3 (supervision unit's on-site acceptance record is qualified) AND Condition 4 (precast component factory inspection report is qualified) AND Condition 5 (design drawings and construction conform to specifications). The responsibility weight set is configured as follows: basic weight of construction unit. Basic weight of supervision unit Basic weight of design unit Basic weight of component production unit .

[0082] When a responsibility tracing procedure is initiated for a specific quality defect, the responsibility determination smart contract extracts spatiotemporal data and subject operation records from the quality responsibility association graph, matches them with the quality defect discrimination rule base, and automatically triggers a multi-factor weighted responsibility ratio calculation model.

[0083] Participating entities Ultimate responsibility percentage The calculation formula is defined as follows:

[0084] The specific extraction and calculation logic for each factor in the formula is configured as follows: The main body output of the quality defect discrimination rule base Basic responsibility weights; A time-dimensional correction factor is set, with a value range of 0.8 to 1.2. The responsibility determination smart contract extracts the blockchain block timestamp and calculates the overlap between the entity's operation time and the defect formation time. The higher value is used when the operation time and defect formation time completely overlap. When coverage is insufficient, take the lower value. ; This is a spatial dimension correction factor, with a value range of 0.8 to 1.2. The liability determination smart contract compares the spatial coordinates of defects in the BIM model with the construction liability spatial range stipulated in the main contract. The higher value is used when the defect location completely falls within the main construction liability range. ; This is a historical performance correction factor, with a value range of 0.9 to 1.1. The liability determination smart contract retrieves the incidence rate of similar defects recorded on-chain by the entity within a preset time period (e.g., 12 months). If the historical defect incidence rate exceeds the industry average threshold, the higher value is used. When the incidence rate is low, take the lower value. ; This represents the total number of participating entities associated with the current quality defects.

[0085] Numerical calculations were performed using an example of incomplete grouting defects in precast wall panels during a prefabricated residential project: Match the aforementioned RULE-PC-007 rule to extract the foundation weight of the construction unit. Basic weight of supervision unit .

[0086] The smart contract retrieval graph for liability determination shows that the construction unit's operation time and the defect formation time completely overlap, with a time correction factor. The defect location is entirely within the construction area of ​​the construction unit, and the spatial correction factor is [not specified]. The construction unit's historical defect rate for similar issues is normal, and the historical performance correction factor is [not specified]. The calculated corrected score for the construction unit is:

[0087] Insufficient on-site supervision time coverage by the supervision unit, time correction factor ; Supervision scope coverage area, spatial correction factor The supervision unit has a history of normal contract performance, and the historical performance correction factor is [not specified]. The calculated corrected score for the supervision unit is:

[0088] The total corrected score is:

[0089] Substituting into the formula and normalizing, we obtain the final responsibility ratio: Construction unit's liability percentage:

[0090] Percentage of responsibility of the supervision unit:

[0091] The liability determination smart contract assembles the calculated liability ratio conclusion, defect spatial coordinates, cause analysis and standard basis into a comprehensive traceability report, calculates the SHA-256 hash value of the traceability report, stores it on the blockchain, and writes the full text of the report into the private IPFS network.

[0092] When the subject being traced objects to the liability percentage conclusion generated by the liability determination smart contract, the system initiates a zero-knowledge proof objection review mechanism based on the zk-SNARKs algorithm framework (specifically using the Groth16 proof system).

[0093] The entity being traced constructs a compliance verification arithmetic circuit on its local client. The circuit's input and output definitions are configured as follows: Privacy Input (held locally only by the entity being traced, uploading to the network is prohibited): Contains the entity's core trade secrets, specifically the numerical matrix of real-time grouting pressure sampling curves during construction. and material proportioning parameters; public input (publicly readable on the blockchain): including defect type codes. The minimum grouting pressure threshold specified in the standard The traceable entity's DID identifier, process timestamp range, and BIM component code; internal circuit verification logic: performing range constraint verification for all sampling points.

[0094] The complete interactive workflow for objection review is as follows: First, the entity being traced invokes a pre-generated proof key locally, inputs privacy-preserving input data into an arithmetic circuit, and calculates and generates a fixed-length (200-byte) zero-knowledge proof string. ; Secondly, the entity being traced constructs an objection appeal transaction, the payload of which contains a zero-knowledge proof string. First, publicly input data, the issue number, and the entity's DID are submitted to the liability determination smart contract; then, the liability determination smart contract calls the verification key deployed on the chain ( ), millisecond-level verification calculation:

[0095] If the verification function outputs 1, the liability determination smart contract, without obtaining the encrypted construction pressure curve of the traced entity, logically confirms that the entity's construction parameters in the corresponding process meet the standard threshold, and marks the appeal status as valid compliance proof (Proof_Valid=0x01) on the chain, automatically pushing it to the government regulatory department node; the government regulatory department node retrieves the valid proof mark and related evidence on the chain, makes a ruling adjustment on the liability ratio, and the ruling result and the zero-knowledge proof string are simultaneously stored on the chain.

[0096] Government regulatory nodes can initiate dynamic audits of quality data at any time. Once an audit is triggered, the regulatory client retrieves the evidence storage index tuple stored on the blockchain, extracts the CID hash of the quality file, retrieves the original encrypted ciphertext file from the private IPFS network, calculates the hash value of the ciphertext file, and performs a matching comparison with the on-chain CID hash to verify data integrity and consistency.

[0097] The system is configured with three types of dynamic anomaly warning rules, which are monitored in real time by the smart contract controlling the rectification process: Overdue rectification warning: When the millisecond time interval of the process flow edges in the graph... Greater than the preset rectification period Triggered at time; Repeated Defect Warning: Triggered when the same BIM component or the same construction team repeatedly shows the same type of defect code (Defect_Code) twice or more within a preset period; Key indicator anomaly warning: triggered when the value of the core quality parameter on the blockchain exceeds the upper and lower limit threshold range specified by the national standard.

[0098] When an early warning rule is triggered, the smart contract for rectification process control executes tiered push notifications: general early warnings are pushed to the responsible unit's node; severe early warnings are simultaneously pushed to the construction unit's node and the government regulatory department's node. Early warning trigger records and processing results are packaged and generated into a blockchain for evidence storage.

[0099] Periodically (e.g., monthly), the blockchain aggregation engine automatically retrieves all closed-loop quality evidence data from the entire network, calculates statistical indicators based on four dimensions: professional type, severity level, responsible party, and construction stage, and generates standardized quality analysis reports. Simultaneously, the system assembles completed closed-loop quality defect cases, causal analyses, responsibility percentage conclusions, and rectification plans into a knowledge base update data package. After the knowledge base update data package undergoes digital signature verification by government regulatory department nodes, it is automatically and synchronously written into the quality defect handling knowledge base by smart contracts, achieving automatic iterative updates of the judgment rule base and handling solution base.

[0100] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based method for tracing responsibility for construction project quality and for multi-party collaborative supervision, characterized in that: Includes the following steps: S100: Establish a blockchain network and configure access permissions and decentralized identity identifiers for each participating node. Divide quality data into core quality parameters, quality documents, and on-site evidence. Adopt a distributed evidence storage strategy that directly stores core quality parameters on the chain, encrypts quality documents and on-site evidence, stores them in the IPFS distributed storage network, and synchronizes the content identifier hash value on the chain. S200: Based on the BIM model, the quality problems found are marked with component-level thumbnails, the three-dimensional spatial coordinates of the component where the problem is located are collected and a quality problem record file is generated. The hash value of the quality problem record file and the three-dimensional spatial coordinates are encapsulated in the same evidence storage transaction payload and synchronously uploaded to the blockchain, and the rectification process control smart contract is triggered. S300: The rectification process control smart contract automatically matches the responsible party based on the attributes of the quality problem, drives the multi-party collaborative rectification process, and extracts the timestamp of the on-chain quality data and the spatial coordinates of the BIM model to construct a quality responsibility association map covering the three dimensions of time, space and responsible party; S400: When responsibility tracing is initiated, the responsibility determination smart contract calls the quality defect discrimination rule base, combines the spatiotemporal information and subject information in the quality responsibility association graph, automatically infers and calculates the responsibility ratio of each participating subject, and generates a tracing report for on-chain storage.

2. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 1, characterized in that, In step S100, a blockchain network is established and the access permissions and decentralized identity identifiers of each participating node are configured, specifically including: A licensed consortium blockchain underlying network is built, and six types of core nodes are independently deployed, including construction units, design units, construction units, supervision units, testing institutions, and government regulatory departments. A role-based access control (RBAC) mechanism is adopted to configure the construction unit with full access to project data, the design unit, construction unit and supervision unit with access to quality data within their respective responsibilities, and the government regulatory department with full audit and supervision permissions. A unique decentralized identity identifier (DID) is generated for each participating entity, and smart contracts for quality data storage, rectification process control, and liability determination are deployed simultaneously. After dividing the quality data, the process also includes standardization preprocessing and data source verification of the collected quality data. Data collection nodes are divided according to the four stages of architectural engineering: design, production, construction and acceptance. All collected quality data undergoes format standardization conversion, integrity verification and sensitive information desensitization. For multi-source quality data of the same process, a common source verification mechanism is introduced. The consistency of data between different data sources is verified by cross-comparison. If there is a deviation in the comparison, the data is marked as abnormal and pushed to the corresponding responsible party node for review and correction.

3. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 2, is characterized in that... In step S100, the quality documents and on-site evidence are stored in the IPFS distributed storage network, specifically employing a storage strategy that combines private deployment with asymmetric encryption. The IPFS distributed storage network adopts a private node deployment mode, allowing only authorized nodes within the permissioned consortium blockchain network to access it. Quality documents and on-site evidence uploaded to the IPFS distributed storage network are encrypted and stored using the public key of the corresponding participating entity, and only authorized entities holding the corresponding private key have the right to decrypt and read them; All distributed evidence storage operations are automatically invoked and executed by the quality data evidence storage smart contract for format verification and permission verification. Only after the verification is passed can on-chain hash synchronization and off-chain storage be completed. The core quality parameters include component strength, installation accuracy, and material properties; the quality documents include inspection reports and acceptance records; and the on-site evidence includes on-site photos and video surveillance. When establishing a trusted mapping relationship between on-chain hash index and off-chain file, the content identifier hash value, file category and corresponding process information are encapsulated into a storage index tuple and written into the blockchain state database to realize the corresponding retrieval of on-chain index and off-chain encrypted file based on the unique component code.

4. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 3, is characterized in that... In step S200, the quality data is mapped and component-level pin annotations are performed based on the BIM model, specifically including: A mapping mechanism for the association of two tables is established, in which the BIM client deploys the BIM component metadata table locally, and the blockchain status database stores the on-chain evidence index table. The two tables are associated with the unique code of the BIM component as the primary key and foreign key, so as to realize the one-to-one correspondence between the spatial data of the BIM model and the on-chain evidence data. When quality issues are discovered during engineering inspections, quality issue pins are marked at the corresponding locations in the 3D space of the BIM model and precisely bound to individual BIM components and specific parts. Acquire three-dimensional spatial coordinates and generate a quality problem record file, specifically including: Collect the millimeter-level three-dimensional spatial coordinates (X,Y,Z) of the quality problem pins in the world coordinate system of the BIM model, as well as the unique component code of the component where the problem is located; Collect the problem type, severity level, rectification requirements, and rectification deadline, and generate a standardized quality problem record file by combining the three-dimensional spatial coordinates and the unique code of the component.

5. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 4, characterized in that, In step S200, the hash value and three-dimensional spatial coordinates of the quality problem record file are encapsulated in the same evidence storage transaction payload and synchronously uploaded to the blockchain, specifically using a JSON structured encapsulation format: The transaction type identifier, unique issue number, unique component code, millimeter-level three-dimensional spatial coordinates, IPFS content identifier hash value of the quality issue record file, issue type, severity level, decentralized identity identifier of the operating entity, and timestamp are all uniformly encapsulated in the JSON payload of the same evidence storage transaction. The three-dimensional spatial coordinates and the hash value share the same transaction hash and timestamp, forming a strong technical binding that is indivisible and cannot be tampered with individually under the solidification of the blockchain consensus mechanism; The smart contracts that trigger the rectification process control include: While the notarized transaction payload is uploaded to the blockchain, the quality data notarization smart contract automatically calls the rectification process control smart contract to convert the generated quality problem record into an on-chain rectification event to be processed, and pushes a rectification notification containing spatial coordinates and problem details to the matching responsible node.

6. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 5, is characterized in that... In step S300, the multi-party collaborative rectification process is driven by the rectification process control smart contract, specifically including: The rectification process control smart contract automatically matches the responsible entity, rectification execution entity, and review and acceptance entity based on the professional field, process, and scope of responsibility of the quality problem, and sends rectification notifications to the corresponding nodes. After completing the rectification, the entity responsible for rectification uploads the rectification record and the evidence file after rectification, and their hash values ​​are synchronously uploaded to the blockchain. The review and acceptance entity uses the original records and rectification materials online to perform tiered acceptance: general quality issues are handled by the supervision unit node in a single closed-loop acceptance process, while major quality issues are handled by the supervision unit node and the construction unit node in a sequential closed-loop acceptance process; if the acceptance fails, a second rectification process is automatically triggered. The quality responsibility association graph adopts a directed attribute graph model structure, including a tuple data structure of nodes and edges: The nodes are divided into quality event nodes and responsible entity nodes. The quality event node tuple contains the event ID, event type code, occurrence timestamp, BIM component code, three-dimensional spatial coordinates (X,Y,Z), process stage, IPFS content identifier hash value of the data file, and operation status. The responsible entity node tuple contains the entity's decentralized identity identifier (DID), entity type, role permissions, associated process scope, associated BIM component set, and historical performance score. The edges are divided into process flow edges and responsibility association edges. The process flow edge tuple includes the start event ID, end event ID, relationship type, time interval, and flow status. The responsibility association edge tuple includes the subject DID, event ID, responsibility type, basic weight, and associated process.

7. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 6, is characterized in that... In step S300, when constructing the quality responsibility association graph, a four-step mapping and fusion rule is adopted for BIM spatial data, blockchain time-series data, and DID identity data: Step 1: Extract the transaction timestamps, event types, and operator DIDs from the blockchain blocks, generate corresponding quality event nodes, and write the occurrence timestamps to complete the time-dimensional graph transformation. Step 2: Extract component codes, 3D coordinates, and process information from the BIM model component library to establish a mapping dictionary. After matching the BIM component codes of the quality event nodes, write them into the spatial coordinates and process fields to complete the spatial dimension map conversion. Step 3: Extract identity identifiers and responsible procedures from the consortium blockchain DID system to generate responsible entity nodes; Step 4: Connect the discovery, assignment, rectification and acceptance event nodes of the same quality problem in the order of timestamps to generate process flow edges, and connect the responsible subject node and the quality event node according to the operator's DID and the responsible process to generate responsibility association edges; The quality responsibility correlation graph supports forward backtracking and backward deduction along the time axis: During forward backtracking, starting from the designated responsible entity node, all quality event nodes and flow paths under its responsibility are retrieved forward along the responsibility association edge and process flow edge; During reverse engineering, starting from the specific quality defect event node, the process is traced back along the flow edge and the responsibility association edge to the specific process that caused the defect, the preceding quality event and the corresponding responsible entity node, and the rectification overdue judgment is made based on the time interval field in the flow edge.

8. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 7, is characterized in that... In step S400, the quality defect discrimination rule base adopts a three-level structured storage of "rule metadata + precondition set + responsibility weight set": The rule metadata layer stores the basic identification information of the rules, including the rule ID, defect type code, applicable process stage, associated specification clause number, and rule effective status. The precondition set layer stores multi-dimensional logical judgment conditions that trigger responsibility determination. The condition dimensions cover defect attributes, construction record status, supervision record status, test data deviation, and time node compliance. The responsibility weight set layer stores the basic responsibility weight coefficients of each participating entity after the preconditions are met, and the sum of the basic responsibility weight coefficients of all related entities is 1. Combining the spatiotemporal information and subject information in the aforementioned quality responsibility correlation map, the responsibility proportion of each participating subject is automatically inferred and calculated, specifically using a multi-factor weighted calculation model of "basic weight × impact factor correction": Extract the basic responsibility weights of the participating entities associated with defects, and generate a time correction factor based on the time overlap between the operation node and the defect formation node by calculating the blockchain timestamp data; A spatial correction factor is generated by comparing the spatial overlap between the defect location and the construction scope of each responsible party based on BIM spatial coordinate data. Historical performance correction factors are generated by retrieving the occurrence rate of similar defects of each entity within a preset time period from the knowledge base. The basic responsibility weight is multiplied by each correction factor to obtain the correction score of each entity. After normalization, the final responsibility ratio of each participating entity is calculated.

9. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision as described in claim 8, characterized in that, In step S400, after generating the traceability report, a dispute review process based on a zero-knowledge proof mechanism is also included: When the subject being traced has a dispute over the proportion of responsibility, the proof key of the zk-SNARKs algorithm framework is called locally. Commercial data containing construction process parameters or internal quality control records of the enterprise is used as privacy input, and defect type code, quality threshold, subject DID and timestamp range are used as public input. A zero-knowledge proof string is generated and submitted to the responsibility determination smart contract. The liability determination smart contract calls the built-in verification key to perform verification, verifying compliance without disclosing the privacy input. After verification, the compliance certificate is marked as valid and pushed to the government regulatory department node for liability determination adjustment. The entire review process is recorded and the adjudication result is synchronously stored on the blockchain.

10. The blockchain-based method for tracing responsibility for construction project quality and conducting multi-party collaborative supervision according to claim 9, characterized in that, Step S400 also includes dynamic audit warnings and knowledge base self-updating based on on-chain evidence storage data: The system includes three types of warning rules: overdue rectification warning, repeated defect warning, and abnormal key indicator warning. When on-chain data triggers the threshold, the rectification process control smart contract will automatically push graded warnings to relevant responsible parties and regulatory department nodes. Regularly aggregate the evidence data within the blockchain network to generate multi-dimensional quality analysis reports. After the closed-loop quality defect cases, cause analysis, responsibility ratio conclusions and handling solutions are reviewed and approved by the regulatory node, the smart contract will automatically synchronize and write them into the quality defect handling knowledge base, so as to realize the continuous updating of the judgment rule base and the handling solution base.

Images