A blockchain-based intelligent bidding and procurement management system

Abstract

This invention belongs to the field of bidding and procurement technology, specifically relating to a blockchain-based intelligent bidding and procurement management system. Built on a domestically developed consortium blockchain, it includes a data platform module, a data on-chain module, an intelligent interface partitioning module, a contract intelligent management module, and a dispute identification and processing module. It achieves trusted data collaboration among multiple participating nodes through hierarchical PBFT consensus, automatically generates bidding and procurement interface partitioning schemes driven by on-chain data, achieves full-chain traceability of key contract terms through three-layer cross-binding traceability identifiers, and realizes full lifecycle management of contracts and intelligent dispute resolution through smart contracts. This invention solves the problems of isolated data, reliance on manual interface partitioning, and insufficient intelligent contract management in existing bidding and procurement systems, thereby improving the credibility and intelligence level of engineering bidding and procurement management.

Description

Technical Field

[0001] This invention belongs to the field of bidding and procurement management technology, specifically relating to a blockchain-based intelligent bidding and procurement management system. Background Technology

[0002] In the process of engineering construction project management, bidding and procurement management is a crucial link connecting various stages such as project design, cost estimation, construction, and post-construction operation and maintenance. However, existing bidding and procurement management systems and related methods still have the following technical problems: First, data silos exist between systems, hindering information flow. Existing bidding and procurement systems are typically independent of cost consulting, design collaboration, project schedule management, and operation and maintenance management systems, lacking standardized data interfaces and real-time synchronization mechanisms. This results in subsequent design changes failing to drive procurement adjustments, cost data not being automatically linked to the bidding control price, and operation and maintenance requirements not being pre-constrained on procurement content. Consequently, bidding and procurement decisions lack comprehensive data support, impacting project progress and quality. Furthermore, the lack of effective integration of multi-disciplinary data from design, cost, and operation and maintenance means that the bidding and procurement interface has long relied on manual experience, lacking intelligent analysis rules based on multi-disciplinary needs. This easily leads to issues such as double-counting, blurred responsibility boundaries, and omissions of operation and maintenance requirements, causing audit risks, contract disputes, and project delays. For example, the unclear work interface between civil engineering and electromechanical installation engineering results in some pipeline pre-embedded content being included in both bids simultaneously, wasting investment and potentially leading to blame-shifting during construction. In addition, after the bidding contract is signed, the existing system can only realize the electronic storage of the contract and the basic process approval. It is weak in the substantive application of contract terms, dynamic tracking and dispute resolution capabilities.

[0003] In summary, existing technologies suffer from significant deficiencies in the accuracy, timeliness, and traceability of interface segmentation because multidisciplinary data, such as design, cost, and operation and maintenance, cannot be automatically aggregated and analyzed in the bidding and procurement process. Summary of the Invention

[0004] To address the aforementioned problems in existing technologies, this invention provides a blockchain-based intelligent bidding and procurement management system. This system solves the problem that the interface division for engineering bidding and procurement relies on manual experience and lacks intelligent integration and rule-driven approaches from multiple disciplines, resulting in significant deficiencies in the accuracy, timeliness, and traceability of the interface division process.

[0005] The objective of this invention can be achieved through the following technical solutions: To address the aforementioned problems in existing technologies, this invention provides a blockchain-based intelligent bidding and procurement management system. This system solves the problems of relying on manual experience for the division of engineering bidding and procurement interfaces, lacking intelligent integration of multi-disciplinary data and rule-driven mechanisms, resulting in low accuracy of interface division and easy occurrence of duplicate pricing and liability disputes.

[0006] The objective of this invention can be achieved through the following technical solution: a blockchain-based intelligent bidding and procurement management system, comprising: The data platform module consists of multiple blockchain nodes, including cost consulting system nodes, design collaboration system nodes, project progress management system nodes, operation and maintenance management system nodes, and bidding and procurement management platform nodes. Each blockchain node maintains the same distributed ledger through a hierarchical PBFT consensus algorithm and executes cross-node business logic through smart contracts. The data on-chain module is used to encapsulate design change data, cost data, progress data, and operation and maintenance requirement data into transactions in a structured form, write them into the distributed ledger after consensus, and trigger smart contract events for updating each data. The intelligent interface segmentation module is used to listen for data update smart contract events, read the latest design data, cost data and operation and maintenance requirements data from the blockchain ledger, call the pre-set interface segmentation rule library, automatically generate a bidding and procurement interface segmentation scheme, and store the segmentation scheme on the blockchain in the form of a transaction. The smart contract management module is used to perform compliance analysis on contract terms based on smart contracts, embed traceability identifiers in the key terms of the generated contract text through a three-layer cross-binding method, publish the contract text to various blockchain nodes, and record the publishing and execution operations on the chain. The dispute identification and processing module, when a contract dispute arises, uses intelligent algorithms to match similar cases and generate dispute resolution suggestions based on contract performance data stored on the blockchain and on-chain / off-chain case libraries. Based on the traceability identifier carried by the disputed clauses, it traces back the generation process, modification history and signatures of the participating parties from the blockchain ledger to form a verifiable traceability evidence chain.

[0007] Preferably, the contract intelligent management module includes performing the following processes: Before bidding, the legal and policy database and project data are read from the blockchain. The rule engine is used to analyze the compliance, risk, feasibility and owner needs of the proposed contract terms, generate a demonstration report, and record the demonstration process on the blockchain. Based on the approved contract terms, generate deployable smart contract bytecode and corresponding contract text, deploy the smart contract to the underlying blockchain platform and generate a unique contract address, and embed the generated traceability identifier in the key terms of the generated contract text. Key terms are parsed from deployed smart contracts to generate contract disclosure information, which is then pushed to various blockchain nodes through the blockchain's event subscription mechanism. Smart contracts automatically execute contract signing confirmation, payment condition verification, change confirmation, default judgment, and contract archiving.

[0008] Preferably, the contract disclosure information includes: project service content, payment terms, liability for breach of contract, interface division, pricing rules for changes, and warranty period requirements.

[0009] Preferably, the traceability identifier includes a block timestamp, the digital signature of the contract writer, the unique address of the deployed smart contract, the unique identifier of the bidding project, and the text hash value of the corresponding key terms.

[0010] Preferably, the generation of the traceability identifier includes the following process: Four types of information—block timestamp, digital signature of the contract drafter, unique address of the deployed smart contract, unique identifier of the bidding project, and text hash value of corresponding key terms—are each compressed using the national cryptographic algorithm SM3 with salting, generating four independent fixed-length compressed identifiers. The compression formula is as follows: ; In the formula, Let C1 be the nth compression identifier, where n = 1, 2, 3, 4, corresponding to the block timestamp compression identifier C1, the digital signature compression identifier C2, the smart contract address compression identifier C3, and the text hash compression identifier C4, respectively. For the original text corresponding to the nth type of basic information, K is the unique identifier of the on-chain bidding project, H is the real-time block height, SM3 is the national cryptographic hash algorithm, and the output is a fixed 256-bit compressed result; Four compressed identifiers are used as leaf nodes of the Merkle tree. The root node value of the Merkle tree is generated by SM3 hash iteration and used as the global traceability identifier Root. The unique identifier K of the bidding project is used as the fixed salt value generated by the Merkle tree.

[0011] Preferably, the generated traceability identifier is embedded in the key clauses of the generated contract text, including the following process: First layer: The traceability identifier Root is split into multiple data blocks of equal length. A digital watermarking algorithm is used to embed the watermark of the blocks into the background layer of the contract text in an invisible form. The watermark blocks carry the position index parameters of the second layer of embedding. The embedded parameters are stored on the blockchain for evidence. The second layer: For timestamp compression identifiers and digital signature compression identifiers, dynamic zero-width character encoding driven by on-chain seeds is adopted. The embedding position is calculated based on on-chain parameters and embedded in key clause paragraphs of the contract text. The encoding mapping table seed and the embedding position sequence are stored on the chain for evidence. The third layer: The smart contract address compression identifier and the text hash compression identifier are concatenated with the verification code embedded in the first two layers and written into the file attribute extension field of the contract text. At the same time, the national cryptographic SM3 encryption algorithm is used to encrypt the data in this field. The encryption public key is stored on the blockchain for evidence, and the private key is kept offline by the bidding party.

[0012] Preferably, the encoding process using on-chain seed-driven dynamic zero-width character encoding is as follows: The 256-bit binary bitstream of the block timestamp compression identifier and digital signature compression identifier is split into 64 4-bit segments, each consisting of 4 bits. Using the unique identifier K of the on-chain project plus the current block height H as a seed, a pseudo-random sequence is generated, and a preset zero-width character set is randomly sorted to generate a dynamic mapping table. According to the dynamic mapping table, each 4-bit segment is converted into the corresponding zero-width character to complete the encoding.

[0013] Preferably, in the second layer, the formula for calculating the embedding position is: ; In the formula, The insertion position of the i-th zero-width character (in character offset). This is the starting offset of the key clause text. Let be the bit segment of the i-th compressed identifier, K be the unique identifier of the current bidding project read from the blockchain ledger, M be the preset total number of candidate positions, and d be the minimum interval number of characters between adjacent candidate positions. This is the dynamic offset factor.

[0014] Preferably, when the dispute identification and processing module performs source tracing verification, it extracts and restores the source tracing identifiers from the three embedded positions respectively, cross-verifies the restoration results with the original records stored in the distributed ledger, determines the integrity and authenticity of the disputed clauses based on the consistency of the restoration results at each layer, and automatically locates the specific level and location where the tampering occurred.

[0015] Preferably, the specific process by which the intelligent interface partitioning module automatically generates the bidding and procurement interface partitioning scheme is as follows: Step a: Based on the read design BIM data, the project is divided into multiple professional sections, and the corresponding process nodes, construction scope and spatial boundaries of each section are clarified. Step b: Based on the cost data, match the bill of quantities and cost items corresponding to each section, cross-check and eliminate duplicate pricing items, mark the work content corresponding to missing pricing, and form a matching draft of section cost and construction scope. Step c: Based on the operation and maintenance requirements data, supplement the operation and maintenance pre-constraints in the procurement content of the corresponding bid section, call the interface division rule library to complete the intelligent division of the work scope, responsibility boundaries and process connection nodes of each bid section, and generate the initial draft of the interface division. Step d: Based on the rule base, perform multi-disciplinary cross-validation on the initial draft, identify and supplement missing items, and generate the final bidding and procurement interface division scheme.

[0016] The beneficial effects of this invention are as follows: This invention breaks down data silos among multiple participating parties through a hierarchical PBFT consensus mechanism, enabling trusted cross-system collaboration. Through on-chain data-driven and rule-based matching, it transforms the manual experience-dependent bidding interface into an intelligent process that can be automatically generated and cross-verified. Using a traceability identifier embedding mechanism based on the national cryptographic standard SM3 (Salted Hash Compression), Merkle tree aggregation, and three-layer cross-binding, the traceability identifier is decomposed and embedded in a heterogeneous layer. On-chain parameters and verification codes achieve strong logical binding and closed-loop verification between the three layers, ensuring that any breach of a single layer will prevent integrity verification. It also possesses the ability to accurately locate the tampering level, solving the technical challenges of tamper-proofing, concealed traceability, and anti-stripping of electronic contracts. Through the smart contract deployment of contract terms and automatic on-chain performance data, it achieves autonomous execution throughout the contract lifecycle and automatic generation of dispute evidence chains, significantly improving the credibility, standardization, and intelligence of engineering bidding and procurement management. Attached Figure Description

[0017] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0018] Figure 1 This is a schematic diagram of the system structure of the management system of the present invention; Figure 2 This is a schematic diagram illustrating the execution steps of the intelligent contract management module of the present invention; Figure 3 This describes the specific process by which the intelligent interface partitioning module of this invention automatically generates a bidding and procurement interface partitioning scheme. Detailed Implementation

[0019] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0020] Please see Figures 1-3This embodiment provides a blockchain-based intelligent bidding and procurement management system, applied to the bidding and procurement management of general contracting projects for housing construction engineering. The system is built on the domestic consortium blockchain platform FISCO BCOS, and includes a data middleware module, a data upload module, an intelligent interface partitioning module, a contract intelligent management module, and a dispute identification and processing module, all of which are communicatively connected to the data middleware module. The specific functional implementation of each module is as follows: The data platform module consists of multiple consortium blockchain nodes that have been authenticated by a CA. These blockchain nodes include cost consulting system nodes, design collaboration system nodes, project progress management system nodes, operation and maintenance management system nodes, and bidding and procurement management platform nodes. Each node is assigned a unique identifier and permission allocation. In addition, nodes for participating parties such as supervision system nodes, construction unit nodes, and audit unit nodes can be added according to project needs. Each blockchain node maintains the same distributed ledger through the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm, ensuring the consistency and immutability of data across all nodes. For multi-node scenarios in engineering bidding projects, a hierarchical consensus mechanism consisting of a core consensus node and synchronization nodes is adopted. At the same time, standardized business logic across nodes is executed through smart contracts, enabling business collaboration across systems and participants.

[0021] The data upload module, deployed in the front-end services of each blockchain node, is used to achieve trusted upload of project data throughout its entire lifecycle. In practice, the data upload module first preprocesses the design change data, cost data, progress data, and operation and maintenance requirement data to be uploaded to the blockchain. This includes: verifying the data format based on a pre-set standardized data template to ensure the data conforms to cross-system interaction standards; performing data integrity verification to remove invalid data with missing key fields; and performing CA authentication on the data sender's identity and verifying the sender's digital signature to ensure the data source is trustworthy.

[0022] After preprocessing, the data on-chain module adopts a differentiated on-chain strategy for structured and unstructured data. Structured data (including design change parameters, cost engineering quantity list, progress node data, operation and maintenance requirement indicators, etc.) are encapsulated into blockchain transactions in JSON structured form after preprocessing, with the sender's digital signature and timestamp attached, and broadcast to the blockchain network. Unstructured data (including large files such as design BIM models, revised drawings, and on-site acceptance images) adopts a solution of hash value on-chain combined with distributed storage of source files: the source file is subjected to the national cryptographic SM3 hash operation to generate a unique file hash value, and the hash value, file storage address, sender digital signature and timestamp are encapsulated into a blockchain transaction and broadcast to the network. The source file is stored in a private distributed storage cluster bound to blockchain nodes, and only authorized nodes can verify the integrity of the file and retrieve the source file through the on-chain hash value.

[0023] After the encapsulated blockchain transaction achieves consensus among all network nodes through the PBFT consensus algorithm, it is written into the distributed ledger, triggering the corresponding data update smart contract event. The relevant business modules are then notified to execute subsequent business logic through the blockchain's event subscription mechanism.

[0024] When multiple nodes simultaneously upload conflicting data of the same project and the same dimension, the smart contract's preset conflict handling rules are triggered: the data uploaded by the node responsible for the data takes precedence, and the data of the non-responsible party is only recorded as a note; if there is a dispute over responsibility among multiple parties, the arbitration process of the bidding and procurement management platform node is automatically triggered. After the arbitration result is recorded on the blockchain, the ledger is updated based on the data confirmed by the arbitration, and the entire conflict handling process is recorded.

[0025] The intelligent interface segmentation module is used to listen for data update smart contract events, read the latest design data, cost data and operation and maintenance requirements data from the blockchain ledger, call the pre-set interface segmentation rule library, automatically generate a bidding and procurement interface segmentation scheme, and store the segmentation scheme on the blockchain in the form of transactions.

[0026] In the specific implementation process, the intelligent interface segmentation module continuously monitors data update smart contract events in the blockchain network. When it detects an update in design data, cost data, or operation and maintenance requirements data, it automatically reads the latest full data from the blockchain distributed ledger, including professional engineering data split from the design BIM model, bill of quantities and tender control price data uploaded by the cost consulting system, and facility operation and maintenance requirements and quality assurance requirements data uploaded by the operation and maintenance management system.

[0027] The intelligent interface segmentation module has a built-in pre-set interface segmentation rule library. The rule library package is sorted by priority from high to low as follows: national and industry mandatory standard rules, local standard rules of the project location, owner's internal control management rules, full-cycle process connection rules, cost item and bid section matching rules, operation and maintenance requirement pre-constraint rules, and similar historical project benchmark case rules. When rule conflicts occur, they are automatically executed according to priority. The mandatory standard rules include professional engineering interface segmentation rules in national standards such as the "Construction Engineering Quantity List Pricing Specification". The process connection rules include the construction sequence of various specialties in building construction and the division of responsibilities for cross-operations.

[0028] The specific process by which the intelligent interface partitioning module automatically generates a bidding and procurement interface partitioning scheme is as follows: Step a, split the mapping between segments and process nodes: The intelligent interface partitioning module reads the latest version of design BIM data uploaded by nodes of the design collaboration system from the blockchain distributed ledger. The design BIM data is stored in a structured format according to the IFC standard and includes component geometric information, spatial location information, material property information and process logic association information.

[0029] First, a spatial area segmentation algorithm is executed on the BIM model. Based on the pre-defined professional classification rules of the "Unified Standard for Acceptance of Construction Quality of Building Engineering," the project is divided into professional sections such as civil engineering, mechanical and electrical installation engineering, decoration and renovation engineering, or fire protection engineering. For each professional section, its corresponding process node sequence is further extracted. The process nodes include the construction start event, construction completion event, and milestone events of each intermediate process. The set of boundary coordinates of the construction scope of each process node in three-dimensional space is recorded. At the same time, the spatial intersection areas between the professional sections are identified, a list of intersection areas is generated and marked as areas to be verified, and stored in a temporary buffer.

[0030] Step b, match cost data and perform duplicate cross-validation: The latest version of cost data uploaded by the cost consulting system nodes is read from the blockchain distributed ledger. The cost data includes bill of quantities data, comprehensive unit price data, and a mapping table of tender control price items. The list of each professional bid section generated in step a is matched item by item with the bill of quantities data. The matching rules adopt a preset association mapping table between the standard item codes of the "Construction Engineering Bill of Quantities Pricing Specification" and BIM component types. For items that cannot be automatically matched, a manual confirmation event is triggered and pushed to the cost consulting system nodes through the blockchain event subscription mechanism to request manual annotation. After matching is completed, a duplicate pricing cross-validation procedure is executed. This includes: traversing the matching results of each bidding section, extracting the BIM component ID set for all pricing items, performing set intersection operations, and identifying BIM component IDs that are simultaneously included in two or more bidding sections. For each duplicated component ID, the unique responsible bidding section to which it should belong is automatically determined based on the responsibility priority rules in the interface-based rule base, and a duplicate pricing removal recommendation report is generated. For example, when a pipeline pre-embedded component is included in both the civil engineering and mechanical and electrical installation bidding sections, the rule base determines that it belongs to the civil engineering bidding section based on the process priority rule of "pre-embedded components are first pre-embedded by the structural construction party, and the mechanical and electrical installation party cooperates in verification," and removes it from the pricing items of the mechanical and electrical installation bidding section. Simultaneously, a "pre-embedded pipeline verification and connection" cooperation work item is added to the mechanical and electrical bidding section. The duplicate pricing removal recommendation report is digitally signed by the module and stored on the blockchain in the form of a transaction for subsequent manual review. Step c, establish pre-operation and maintenance constraints and generate an initial draft of the interface layout: The system reads the latest version of operation and maintenance (O&M) requirement data uploaded by the O&M management system nodes from the blockchain distributed ledger. This O&M requirement data includes a list of facilities and equipment, warranty periods for each piece of equipment, O&M interface protocol requirements, and spare parts requirements. It then iterates through the equipment procurement lists for each professional bidding section, automatically adding corresponding O&M prerequisite constraint fields to the procurement technical specifications for each equipment item. These constraint fields include, but are not limited to: minimum warranty period, O&M data interface standards, remote monitoring point reservation requirements, and after-sales response time. After completing the supplementation of operation and maintenance constraints, the pre-set interface partitioning rule library is invoked to perform intelligent partitioning. The interface partitioning rule library stores the following rule sets in descending order of priority: national and industry mandatory standard rules, local standard rules of the project location, owner's internal control management rules, work process connection responsibility rules, cost item attribution rules, and operation and maintenance pre-constraint rules.

[0031] The results of the bid segmentation in step a, the cost matching and duplicate pricing verification results in step b, and the supplementary operation and maintenance constraints in this step are used as the input fact set. The Rete pattern matching algorithm is used to match each rule against the rule base, generating a description of the work scope, a definition of responsibility boundaries, a list of process connection nodes, and a list of finished product protection responsibilities for each bid segment. The definition of responsibility boundaries adopts a dual approach of spatial scope and component affiliation. For components within overlapping areas, the bid segment to which they belong and the cooperation obligations that the cooperating bid segments must fulfill are indicated.

[0032] After summarizing the matching results, a preliminary draft of the interface layout is generated.

[0033] Step d: After cross-validation, the final solution is generated. The initial draft of the interface partitioning is subjected to multi-disciplinary cross-validation based on the pre-set cross-validation rule set in the rule base. The cross-validation rule set includes: full-discipline coverage integrity rule (checking whether each component in the BIM model is covered by the work scope of at least one contract section), process connection closure rule (checking whether there are any responsibility gaps between adjacent process nodes), cost item and work scope consistency rule (checking whether each cost item has a corresponding work scope description, and whether each work scope description has a corresponding cost item), and operation and maintenance requirement closure rule (checking whether each operation and maintenance requirement item is reflected in the technical requirements of the corresponding contract section). When the cross-validation program detects uncovered components, unclosed processes, or unmatched requirements, it automatically triggers a supplementary procedure: for uncovered components, it matches the closest work scope template in the rule library based on the component type and spatial location to supplement them; for blank areas in the process, it calls the standard process connection template to fill them and marks the suggested responsible party; for unmatched maintenance requirements, it traces back to the section where the corresponding equipment is located to add technical requirement items.

[0034] After the supplementation is completed, the final bidding and procurement interface division scheme is generated. The scheme includes a description of the work scope of each professional section, a detailed list of responsibility boundaries, a process connection matrix, a finished product protection responsibility table, and a summary table of pre-operation and maintenance constraints. The final scheme is accompanied by the digital signature, generation timestamp, and rule base version number of the bidding and procurement management platform, and is stored on the blockchain in the form of a transaction, triggering the contract generation preparatory event of the contract intelligent management module.

[0035] The contract intelligent management module is used to perform compliance analysis on contract terms based on smart contracts, embed traceability identifiers in key clauses of the generated contract text, and the traceability identifiers consist of a timestamp, the drafter's digital signature, the smart contract address, the tender text identifier, and the text hash value. The module also publishes the contract text to various blockchain nodes and records the publication and execution operations on the blockchain. The contract intelligent management module includes the following processes: Before bidding, the contract intelligent management module reads the pre-built legal and policy database, the design, cost, and interface division data of the entire project lifecycle, as well as the owner's internal control management requirements from the blockchain distributed ledger, and inputs the draft contract terms into the built-in rule engine.

[0036] The rules engine incorporates built-in compliance check rules, prioritized according to priority, including mandatory provisions from the "Tendering and Bidding Law of the People's Republic of China," the Contract Law section of the "Civil Code of the People's Republic of China," the general specifications for "Construction Project Contracts (Model Text)," industry standards for housing construction engineering, local regulations of the project location, and internal control rules concerning the owner's payments, changes, and liability for breach of contract. The rules engine compares each contract clause item by item, automatically identifying non-compliant mandatory clauses, high-risk clauses, and missing essential clauses, outputting targeted modification suggestions, and generating a complete report demonstrating the compliance, risk, feasibility, and fulfillment of owner needs of the contract clauses. The entire demonstration process, comparison results, and modification suggestions are timestamped and digitally signed by the operator, with the entire process recorded on the blockchain for evidence preservation, ensuring the traceability of the contract drafting process. Based on the approved contract terms, the executable clauses (including payment terms, changes in pricing rules, liability for breach of contract, and warranty requirements) are transformed into executable smart contract code, compiled into deployable smart contract bytecode, and a corresponding formal contract text is generated. The compiled smart contract is deployed to the underlying blockchain platform, generating a unique smart contract address across the entire network upon deployment. Simultaneously, the contract smart management module generates a unique traceability identifier for all key clauses in the formal contract text. This identifier is composed of the current timestamp, the digital signature of the contract writer, the deployed smart contract address, the unique identifier of this bidding project, and the text hash value of the corresponding clause. This traceability identifier is embedded in the corresponding key clause of the contract text, ensuring that each key clause can be traced throughout the entire chain. The formal contract text with the embedded traceability identifier is simultaneously uploaded to the blockchain for notarization and published to all blockchain nodes.

[0037] The system parses key clauses from deployed smart contracts to generate contract disclosure information, which is then pushed to all blockchain nodes via a blockchain event subscription mechanism. This contract disclosure information includes: project service content, payment terms, liability for breach of contract, interface division, change pricing rules, and warranty period requirements. The smart contract management module writes the disclosure information structure into the blockchain log through events defined in the smart contract. Relevant party nodes automatically obtain the disclosure information by listening to these events. The system also writes the disclosure information structure into the blockchain log through predefined disclosure events in the smart contract. Relevant party nodes (including construction units, supervision units, cost consulting units, and operation and maintenance units) automatically obtain complete contract disclosure information by pre-subscribing to these events, eliminating the need for manual offline pushes and ensuring that all participating parties receive consistent and tamper-proof contract disclosure content synchronously. Furthermore, the entire disclosure process is recorded and documented on the blockchain.

[0038] Smart contracts automatically execute contract signing confirmation, payment terms verification, modification confirmation, default determination, and contract archiving, specifically including the following processes: The online signing and confirmation of the contract by all parties is completed through smart contracts, and the digital signatures of all parties and the signing time are recorded on the blockchain in real time. Real-time monitoring of project progress and acceptance data on the blockchain; automatic verification of payment conditions stipulated in the contract; automatic triggering of payment approval process when all payment conditions are met; generation of payment notification after verification; and on-chain storage of payment execution status. When design change data is detected on the blockchain, it automatically matches the change pricing rules agreed in the contract, automatically calculates the change price, pushes it to all parties for confirmation, and uploads the confirmation result to the blockchain in real time to update the contract execution data; Real-time monitoring of progress, quality, and performance data on the blockchain; automatic comparison with breach of contract clauses; and automatic generation of breach of contract notices and suggestions for accountability when a breach is determined, with simultaneous on-chain evidence storage. Once all contractual obligations are fulfilled, the contract is automatically archived, packaging all data from the entire contract lifecycle onto the blockchain to generate an immutable contract archive file for permanent preservation.

[0039] In the specific implementation of the dispute identification and processing module, when disputes arise among project participants regarding contract terms, the module first extracts the traceability identifier embedded in the disputed terms. Based on information such as the smart contract address, text hash value, and timestamp in the traceability identifier, it traces back the entire process of the disputed terms from the blockchain distributed ledger, including drafting, compliance verification, multiple rounds of revisions, signing by all parties, contract disclosure, and execution. It extracts all relevant on-chain evidence records, including the content of each revision, the digital signature of the operating party, timestamps, confirmation records of all parties, and performance process data, forming a complete, tamper-proof, and verifiable traceability evidence chain, providing complete evidentiary support for dispute resolution.

[0040] Meanwhile, the dispute identification and processing module extracts the core elements of the dispute, including the dispute type (such as payment disputes, interface division disputes, pricing change disputes, breach of contract disputes, etc.), the subject matter of the dispute, contractual terms, and actual performance. It extracts core feature words using the TF-IDF algorithm and combines this with the cosine similarity algorithm to match the built-in on-chain / off-chain case library. This library includes guiding cases on construction contract disputes issued by the Supreme People's Court, judicial rulings from provincial and municipal high people's courts, industry mediation cases, and corresponding adjudication rules and tendencies. The module matches the top five most similar cases and, based on current laws, regulations, and judicial rules, generates targeted dispute resolution suggestions, including negotiation and settlement plans, key points of mediation, key points for evidence preparation in litigation / arbitration, and predictions of judgment outcomes. This provides professional and intelligent assistance to both parties, significantly improving the efficiency of dispute resolution and reducing the cost of protecting rights.

[0041] To enhance the end-to-end traceability, immutability, and anti-counterfeiting verification capabilities of key contract clauses, the intelligent contract management module further embeds traceability identifiers into the key clauses of the generated corresponding tender text, including the following processes: Obtain the block timestamp, the blockchain digital certificate number and digital signature of the writer, the currently deployed smart contract address, and the SM3 text hash value corresponding to the key terms. Perform salted hash compression on these four types of information to generate four fixed-length and independent compressed identifiers. The compression formula is as follows: ; In the formula, Let C1 be the nth compression identifier, where n = 1, 2, 3, 4, corresponding to the block timestamp compression identifier C1, the digital signature compression identifier C2, the smart contract address compression identifier C3, and the text hash compression identifier C4, respectively. For the original text corresponding to the nth type of basic information, K is the unique identifier of the on-chain bidding project; H is the real-time block height; SM3 is the national cryptographic hash algorithm; and the output is a fixed 256-bit compressed result.

[0042] The four types of raw information—block timestamp, digital signature, smart contract address, and text hash value—are concatenated with the unique identifier of the on-chain bidding project and the real-time block height, respectively. Then, they are input into the national cryptographic SM3 hash algorithm for salted hashing, generating four compressed identifiers of fixed 256-bit length. By introducing dynamic on-chain parameters as salt values, this process not only unifies the variable-length raw data into a fixed-length output, facilitating efficient subsequent storage and computation, but also strongly binds the compression result to the specific bidding project and on-chain state, effectively resisting hash reuse attacks across projects or blocks, ensuring that each compressed identifier possesses uniqueness, irreversibility, and anti-counterfeiting properties.

[0043] The four compressed identifiers are combined according to preset rules and then subjected to secondary hashing to generate a traceability identifier. Specifically, the four compressed identifiers C1-C4 are used as the four leaf nodes of a Merkle tree. Each pair of these leaf nodes is grouped and subjected to SM3 hash iteration calculation to generate the root node value of the Merkle tree. This root node value is the global traceability identifier Root. Through secondary compression in the Merkle tree, global binding of the four compressed identifiers is achieved (if any compressed identifier is tampered with, the Root value will inevitably change), while also supporting single-dimensional local verification, allowing for precise location of the dimension in which the tampering occurred.

[0044] The traceability identifier is split and embedded into three layers within the contract text, with the embedding locations including: The first layer: The global traceability identifier is embedded as an invisible digital watermark in the background layer of the contract text. The traceability identifier Root is divided into eight equal-length 32-bit data blocks, each with a corresponding block number and checksum. Using a digital watermarking algorithm based on Discrete Cosine Transform (DCT), the watermark blocks are embedded in the background layer of the contract text PDF / format document in a semi-transparent, invisible form. The embedding position of the watermark blocks is dynamically calculated using the unique on-chain project identifier K, with no fixed embedding pattern, making it impossible to batch crop and remove using conventional image editing software. Simultaneously, each watermark block carries the position index parameter for the second-layer zero-width character embedding. Only by completely extracting all watermark blocks and restoring the Root value can the decoding and positioning parameters for the second-layer embedding be obtained, achieving a strong binding between the first and second layers. After embedding, the embedding parameters and block checksums of the watermark blocks are all stored on the blockchain for evidence.

[0045] The second layer uses dynamic mapping zero-width character encoding for the timestamp compression identifier C1 and the digital signature compression identifier C2. Based on an on-chain anchored formula, the embedding position is calculated and distributed across pre-defined key paragraphs of the contract text (including core clauses such as payment terms, liability for breach of contract, interface division, and pricing changes). The specific process is as follows: The encoding process for dynamic zero-width characters using an on-chain seed-driven dynamic encoding mapping table is as follows: ① Divide the 256-bit binary bit stream of C1 and C2 into 64 4-bit segments, each consisting of 4 bits. ② Using the unique identifier K of the on-chain project plus the current block height H as the seed, a pseudo-random sequence is generated, and the preset zero-width character set is randomly sorted to generate a dynamic mapping table; the zero-width character set contains four non-interfering Unicode zero-width characters: zero-width space (U+200B), zero-width non-connector (U+200C), zero-width connector (U+200D), and zero-width non-newline space (U+FEFF), which correspond to 16 random mappings of 4-bit binary; ③ According to the dynamic mapping table, each 4-bit segment is converted into the corresponding zero-width character to complete the encoding.

[0046] Because the mapping table is driven by immutable on-chain data throughout the process, each embedding generates a unique mapping relationship with no fixed encoding rules. Even if the presence of zero-width characters is detected, the original data cannot be decoded and restored without an on-chain seed. This completely solves the industry pain point that fixed encoding is easily identified and cleared by regular expression matching. At the same time, compared with 8-bit mapping, 4-bit mapping shortens the encoding code length, reduces the number of embedded zero-width characters, further improves concealment, and does not affect the normal reading, printing, and format verification of the contract text.

[0047] The embedding position of each zero-width character is calculated based on on-chain parameters, avoiding the vulnerability of fixed embedding positions to easy stripping. The formula for calculating the embedding position is: ; In the formula, The insertion position of the i-th zero-width character (in character offset). The starting offset of the key clause text is obtained from the structured data of the contract template document. Let be the 4-bit segment corresponding to the i-th zero-width character, K be the unique identifier of the current bidding project read from the blockchain ledger, M be the preset total number of candidate positions, which is 1 / 5 of the total number of characters in the corresponding key paragraph to ensure that the embedding position covers the entire paragraph, and d be the minimum number of characters between adjacent candidate positions. The preferred value of d is 5, and d is not less than (total number of characters in the paragraph) / M to avoid overly dense embeddings from being recognized. For dynamic offset factor, This ensures that there is no fixed interval between adjacent embedding positions, further enhancing the ability to resist batch removal.

[0048] Using the starting offset of the key clause text as the baseline anchor point, the embedding range is locked within the core clause area. Next, the compressed identifier bit segment to be embedded is concatenated with the unique identifier of the on-chain bidding project, and a hash operation is performed. Then, the result is modulo the preset total number of candidate positions M to generate a randomized index value within the candidate position pool. This index value is multiplied by the minimum interval between adjacent candidate positions to obtain the basic step offset relative to the baseline position. Finally, the offset factor dynamically calculated from the previous embedding position (the result of modulo 3 of the previous position's hash value) is added to generate the final character offset. Thus, the embedding position is driven by three factors: the data content to be embedded, the on-chain project identifier, and the state of the previous position. This achieves pseudo-randomness and no fixed interval pattern in the position distribution, effectively avoiding the security flaw of fixed-position embeddings being easily identified and stripped in batches.

[0049] After calculation, the encoded zero-width characters are sequentially embedded into the corresponding key paragraphs according to their calculated embedding position values. Priority is given to embedding them in core, unmodifiable positions of the contract, such as after clause numbers and punctuation marks, between characters of the legal entity's name, and between characters of the amount in capital letters. These positions are essential elements of the contract's validity, cannot be arbitrarily modified, and cannot be removed in batches by conventional text cleaning tools. After embedding, the dynamic mapping table seed, embedding position sequence, and paragraph offset are all stored on the blockchain for evidence.

[0050] The third layer: The smart contract address C3 and the compressed identifier C4 of the text hash value are concatenated with the verification code (SM3 (Root||embedded position sequence)) embedded in the first two layers and written into the file attribute extension field of the tender text. Simultaneously, this part of the data is encrypted using AES256, with the encryption key being the project's unique identifier K stored on the chain. Without the key, it cannot be read or modified. Since the stored verification code is the basis for verifying the integrity of the data embedded in the first two layers, only by fully extracting and verifying the traceability identifiers of the first two layers can the full verification of the third layer be completed. Furthermore, C3 and C4 stored in the third layer are the core binding elements between the contract terms and the on-chain smart contract, ensuring that the contract text is completely consistent with the smart contract executed on the chain.

[0051] When subsequent processes require traceability verification of contract terms, such as when the dispute identification and processing module needs to perform traceability verification, the verification node must first pass identity authentication and obtain data such as the unique project identifier K, block height H, embedded parameters, dynamic mapping table seed, and verification code corresponding to the contract from the blockchain ledger, and then perform verification in the following order: Step 1: Extract C3, C4 and the checksum from the extended fields of the contract file attributes. After decryption with the on-chain key, first verify the consistency between C3 and the on-chain smart contract address, and the consistency between C4 and the hash of the key contract terms text, to preliminarily determine whether the contract text has been tampered with. Step 2: Extract watermark blocks from the contract background layer, restore the global traceability identifier Root, verify the consistency between Root and the root node of the Merkle tree generated by C1-C4, and obtain the embedding position sequence of the second-layer zero-width characters through the index parameters in the watermark blocks. Step 3: Based on the dynamic mapping table seed on the chain, restore the encoding mapping table, extract the zero-width character from the corresponding embedding position, decode and restore C1 and C2, and verify the consistency between C1 and the on-chain block timestamp and the consistency between C2 and the writer's digital signature. Finally, through three layers of cross-validation, a verifiable traceability report is generated, and the verification data is synchronously uploaded to the blockchain for evidence storage throughout the entire process.

[0052] The process of generating and embedding traceability identifiers employs on-chain dynamic salt hashing combined with Merkle tree aggregation to generate identifiers, a three-layer cross-binding anti-stripping embedding method, and a blockchain-anchored closed-loop verification and automatic early warning mechanism. This not only achieves a deep and strong binding between the traceability information of key contract terms and the blockchain ledger, effectively resisting hash collisions, rainbow table attacks, and the risks of forgery and reuse, but also significantly improves the concealment and anti-mass erasure capabilities of traceability information through dynamic zero-width character encoding and discretized position calculation. At the same time, relying on three layers of data mutual verification and full on-chain verification, it eliminates contract tampering and enhances the traceability, immutability, and security of the bidding contract lifecycle.

[0053] This invention constructs a closed-loop consortium blockchain architecture adapted to multi-participant, long-cycle scenarios in engineering bidding and procurement. It adopts a hierarchical PBFT consensus mechanism combining consensus nodes and synchronization nodes, along with a multi-dimensional hierarchical permission control system. This not only ensures data consistency and immutability but also solves the performance degradation problem of traditional consensus algorithms in multi-node scenarios, while simultaneously achieving secure management of confidential bidding data. Through an intelligent segmentation mechanism for the bidding and procurement interface driven by real-time on-chain data, an industry rule base sorted by priority has been established, realizing full-process automation from bid segment splitting and cross-verification to multi-party confirmation and contract linkage, filling the industry gap in intelligent segmentation of engineering bidding interfaces; a three-layer cross-binding traceability identifier generation and embedding mechanism based on national cryptographic algorithms, through on-chain dynamic salt value hashing, Merkle tree aggregation, dynamic zero-width character encoding and discrete embedding, has achieved immutability, concealed anti-counterfeiting and full-chain traceability of key contract terms, solving the industry pain points of traditional electronic contracts being easy to tamper with, difficult to trace, and easy to have anti-counterfeiting identifiers removed in batches; through an intelligent closed loop of automatic contract compliance verification and dynamically adaptable smart contract full lifecycle execution, blockchain technology is deeply integrated with engineering bidding and procurement business, improving the credibility and intelligence level of engineering bidding and procurement management.

[0054] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A blockchain-based intelligent bidding and procurement management system, characterized in that: include: The data platform module consists of multiple blockchain nodes, including cost consulting system nodes, design collaboration system nodes, project progress management system nodes, operation and maintenance management system nodes, and bidding and procurement management platform nodes. Each blockchain node maintains the same distributed ledger through a hierarchical PBFT consensus algorithm and executes cross-node business logic through smart contracts. The data on-chain module is used to encapsulate design change data, cost data, progress data, and operation and maintenance requirement data into transactions in a structured form, write them into the distributed ledger after consensus, and trigger smart contract events for updating each data. The intelligent interface segmentation module is used to listen for data update smart contract events, read the latest design data, cost data and operation and maintenance requirements data from the blockchain ledger, call the pre-set interface segmentation rule library, automatically generate a bidding and procurement interface segmentation scheme, and store the segmentation scheme on the blockchain in the form of a transaction. The smart contract management module is used to perform compliance analysis on contract terms based on smart contracts, embed traceability identifiers in the key terms of the generated contract text through a three-layer cross-binding method, publish the contract text to various blockchain nodes, and record the publishing and execution operations on the chain. The dispute identification and processing module, when a contract dispute arises, uses intelligent algorithms to match similar cases and generate dispute resolution suggestions based on contract performance data stored on the blockchain and on-chain / off-chain case libraries. Based on the traceability identifier carried by the disputed clauses, it traces back the generation process, modification history and signatures of the participating parties from the blockchain ledger to form a verifiable traceability evidence chain.

2. The blockchain-based intelligent bidding and procurement management system according to claim 1, characterized in that: The intelligent contract management module includes the following processes: Read the legal and policy database and project data, use the rule engine to analyze the compliance, risk, feasibility and owner needs of the draft contract terms, generate a demonstration report, and put the demonstration process on the blockchain; Based on the approved contract terms, generate deployable smart contract bytecode and corresponding contract text, deploy the smart contract to the underlying blockchain platform and generate a unique contract address, and embed the generated traceability identifier in the key terms of the generated contract text. Key terms are parsed from deployed smart contracts to generate contract disclosure information, which is then pushed to various blockchain nodes through the blockchain's event subscription mechanism. Smart contracts automatically execute contract signing confirmation, payment condition verification, change confirmation, and contract archiving.

3. The blockchain-based intelligent bidding and procurement management system according to claim 2, characterized in that: The contract disclosure information includes: project service content, payment terms, liability for breach of contract, interface division, pricing rules for changes, and warranty period requirements.

4. The blockchain-based intelligent bidding and procurement management system according to claim 2, characterized in that: The traceability identifier includes the block timestamp, the digital signature of the contract writer, the unique address of the deployed smart contract, the unique identifier of the bidding project, and the text hash value of the corresponding key terms.

5. The blockchain-based intelligent bidding and procurement management system according to claim 4, characterized in that: The generation of the traceability identifier includes the following process: Four types of information—block timestamp, digital signature of the contract drafter, unique address of the deployed smart contract, unique identifier of the bidding project, and text hash value of corresponding key terms—are each compressed using the national cryptographic algorithm SM3 with salting, generating four independent fixed-length compressed identifiers. The compression formula is as follows: ； In the formula, Let C1 be the nth compression identifier, where n = 1, 2, 3, 4, corresponding to the block timestamp compression identifier C1, the digital signature compression identifier C2, the smart contract address compression identifier C3, and the text hash compression identifier C4, respectively. For the original text corresponding to the nth type of basic information, K is the unique identifier of the on-chain bidding project, H is the real-time block height, SM3 is the national cryptographic hash algorithm, and the output is a fixed 256-bit compressed result; Four compressed identifiers are used as leaf nodes of the Merkle tree. The root node value of the Merkle tree is generated by SM3 hash iteration and used as the global traceability identifier Root. The unique identifier K of the bidding project is used as the fixed salt value generated by the Merkle tree.

6. The blockchain-based intelligent bidding and procurement management system according to claim 5, characterized in that: The source identifier is embedded in the key clauses of the generated contract text through a three-layer cross-binding method. Includes the following processes: First layer: The traceability identifier Root is split into multiple data blocks of equal length. A digital watermarking algorithm is used to embed the watermark of the blocks into the background layer of the contract text in an invisible form. The watermark blocks carry the position index parameters of the second layer of embedding. The embedded parameters are stored on the blockchain for evidence. The second layer: For timestamp compression identifiers and digital signature compression identifiers, dynamic zero-width character encoding driven by on-chain seeds is adopted. The embedding position is calculated based on on-chain parameters and embedded in key clause paragraphs of the contract text. The encoding mapping table seed and the embedding position sequence are stored on the chain for evidence. The third layer: The smart contract address compression identifier and the text hash compression identifier are concatenated with the verification code embedded in the first two layers and written into the file attribute extension field of the contract text. At the same time, the national cryptographic SM3 encryption algorithm is used to encrypt the field data. The encryption public key is stored on the blockchain for evidence, and the private key is kept offline by the bidding party.

7. The blockchain-based intelligent bidding and procurement management system according to claim 6, characterized in that: The encoding process using on-chain seed-driven dynamic zero-width character encoding is as follows: The 256-bit binary bitstream of the block timestamp compression identifier and digital signature compression identifier is split into 64 4-bit segments, each consisting of 4 bits. Using the unique identifier K of the on-chain project plus the current block height H as a seed, a pseudo-random sequence is generated, and a preset zero-width character set is randomly sorted to generate a dynamic mapping table. According to the dynamic mapping table, each 4-bit segment is converted into the corresponding zero-width character to complete the encoding.

8. The blockchain-based intelligent bidding and procurement management system according to claim 6, characterized in that: The embedding position is calculated based on on-chain parameters. The formula for calculating the embedding position is: ； In the formula, The insertion position of the i-th zero-width character This is the starting offset of the key clause text. Let be the bit segment of the i-th compressed identifier, K be the unique identifier of the current bidding project read from the blockchain ledger, M be the preset total number of candidate positions, and d be the minimum interval number of characters between adjacent candidate positions. This is the dynamic offset factor.

9. The blockchain-based intelligent bidding and procurement management system according to claim 6, characterized in that: When the dispute identification and processing module performs source tracing verification, it extracts and restores the source tracing identifiers from the three embedded positions respectively, cross-verifies the restoration results with the original records stored in the distributed ledger, determines the integrity and authenticity of the disputed clauses based on the consistency of the restoration results at each layer, and automatically locates the specific level and location where the tampering occurred.

10. The blockchain-based intelligent bidding and procurement management system according to claim 1, characterized in that: The specific process by which the intelligent interface partitioning module automatically generates a bidding and procurement interface partitioning scheme is as follows: Step a: Based on the read design BIM data, the project is divided into multiple professional sections, and the corresponding process nodes, construction scope and spatial boundaries of each section are clarified. Step b: Based on the cost data, match the bill of quantities and cost items corresponding to each section, cross-check and eliminate duplicate pricing items, mark the work content corresponding to missing pricing, and form a matching draft of section cost and construction scope. Step c: Based on the operation and maintenance requirements data, supplement the operation and maintenance pre-constraints in the procurement content of the corresponding bid section, call the interface division rule library to complete the intelligent division of the work scope, responsibility boundaries and process connection nodes of each bid section, and generate the initial draft of the interface division. Step d: Based on the rule base, perform multi-disciplinary cross-validation on the initial draft, identify and supplement missing items, and generate the final bidding and procurement interface division scheme.

Images