Intelligent digital monitoring purchasing system based on block chain

By instantiating independent smart contracts on the blockchain and combining them with off-chain microservices, the procurement process is made transparent, trustworthy, and efficient. This solves the problems of process black boxes, data silos, and privacy leaks in existing systems, ensuring the fairness and privacy protection of the procurement process.

CN122066493APending Publication Date: 2026-05-19SHAANXI IRON & STEEL GRP YULONG TECH SERVICE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-02-10
Publication Date
2026-05-19

AI Technical Summary

Technical Problem

Existing electronic procurement systems have shortcomings in terms of process transparency, credibility, and privacy protection. In particular, they are difficult to guarantee the fairness and impartiality of processes in multi-party collaboration and highly sensitive business scenarios, and there is a risk of data leakage. Furthermore, existing blockchain evidence storage solutions have failed to automate the execution of complex business rules.

Method used

The system employs a blockchain-based intelligent digital monitoring and procurement system. By deploying multiple consensus nodes on the blockchain network, instantiating independent smart contracts, encoding the core business logic and state transition rules of procurement projects, and combining them with off-chain business microservice clusters and link coordination services, the system achieves automated execution of business processes and privacy protection.

Benefits of technology

It achieves a transparent, trustworthy, and tamper-proof procurement process, ensuring fairness and privacy. Through multi-round sealed bids and anonymous review mechanisms, it prevents information leakage and human manipulation, supports complex business analysis, and protects data privacy.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122066493A_ABST
    Figure CN122066493A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of supply chain management, in particular to an intelligent digital monitoring purchasing system based on a block chain, which comprises a block chain network, an on-chain process intelligent contract cluster, an off-chain business micro-service cluster and a link coordination service, the link coordination service is configured to monitor a state transition and service event triggered by an on-chain process smart contract, and schedule a corresponding off-chain service micro-service to execute a service operation based on an event type; meanwhile, submitting a service result which needs to reach a consensus after the under-chain service micro-service is executed to a corresponding on-chain process intelligent contract so as to drive the process state to be updated; according to the invention, the core process logic and the state machine of the purchase service are solidified in the block chain smart contract, so that the core process logic and the state machine become a unique credible source and rule execution engine for driving the service flow, thereby realizing the whole process from the purchase demand to the performance completion, endogenous credible monitoring and automatic intelligent execution.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of supply chain management technology, and in particular to a blockchain-based intelligent digital monitoring and procurement system. Background Technology

[0002] As enterprises deepen their digital transformation, traditional e-procurement systems, while improving efficiency, have also exposed some deep-seated problems. Currently, many procurement platforms attempt to introduce blockchain technology to enhance process transparency and credibility, but their application models often have limitations.

[0003] A common solution currently is to use an "on-chain evidence storage" model, which involves storing the hash values ​​or key data summaries of relevant documents on the blockchain at critical nodes in the operation of a traditional centralized procurement system (such as issuing announcements, submitting tenders, publicizing results, and signing contracts). This model provides, to some extent, tamper-proof evidence for post-audit.

[0004] However, in this model, the core logic and state control of the business process still rely entirely on the centralized back-end system. The blockchain acts only as an additional, passive "notary" and does not participate in driving and controlling the business process. The credibility of the business process itself is not fundamentally improved. At the same time, because it only stores fragmented result hashes and lacks complete, context-related business state records, audits still require backtracking and trusting the centralized database to restore the entire process. The traceability capability of the blockchain is greatly reduced, forming "evidence silos." Secondly, the function of smart contracts is greatly limited. They are usually only used for simple evidence verification and fail to automate the execution of complex business rules.

[0005] Furthermore, in scenarios involving multi-party collaboration and highly sensitive business situations (such as multiple rounds of sealed bids and anonymous expert reviews), existing systems struggle to balance ensuring fairness and impartiality in the process with protecting the privacy of participants and maintaining business efficiency. Centralized systems pose risks of data breaches and internal manipulation of processes, while simple on-chain evidence storage cannot solve the "black box" problem inherent in the business processes themselves.

[0006] Therefore, to address the above issues, we propose a blockchain-based intelligent digital monitoring and procurement system. This system embeds the core process logic and state machine of the procurement business into a blockchain smart contract, making it the sole trusted source and rule execution engine driving the business flow. This enables endogenous trusted monitoring and automated intelligent execution of the entire process from procurement demand to contract fulfillment. Summary of the Invention

[0007] In order to overcome the problems of process black box, data silos, privacy leakage and difficulty in ensuring fairness in traditional electronic procurement systems and existing blockchain evidence storage solutions.

[0008] The technical solution of this invention is: a blockchain-based intelligent digital monitoring and procurement system, comprising: A blockchain network, consisting of multiple consensus nodes, is used to provide distributed ledger services. The on-chain process smart contract cluster is deployed on the blockchain network to instantiate an independent smart contract for each created procurement project. The smart contract defines the core business process logic, state transition rules and key operation consensus conditions of the corresponding procurement project. Off-chain business microservice clusters are used to perform non-consensus complex calculations, user interactions, and external system integration in procurement operations; And link coordination service, which communicates and connects with the on-chain process smart contract cluster and the off-chain business microservice cluster respectively; The link coordination service is configured to: listen for state transitions and business events triggered by the on-chain process smart contract, and schedule the corresponding off-chain business microservices to perform business operations based on the event type; at the same time, submit the business results that need to be agreed upon after the off-chain business microservices are executed to the corresponding on-chain process smart contract to drive process state updates.

[0009] Preferably, the blockchain network consists of multiple consensus nodes, providing underlying distributed ledger and consensus services. An on-chain process smart contract cluster is deployed on this blockchain network. This system does not simply share a common notarization contract across all procurement projects, but dynamically instantiates an independent, dedicated smart contract for each newly created procurement project. This dedicated contract defines the complete core business process logic of that specific project, all possible states and their transition rules, and the consensus conditions required for any critical operations. An off-chain business microservice cluster handles complex business logic that does not require global consensus, such as: rich user interface interactions, data integration with external ERP / OA systems, storage and management of large files, and complex data analysis and report generation. Its architecture adopts a microservice model, with each service having a single responsibility and collaborating through APIs. The link coordination service continuously listens for on-chain events that represent state transitions or key actions, issued by the on-chain process smart contracts dedicated to each project. After parsing these events, it schedules the corresponding off-chain business microservices to execute specific business operations according to predefined mapping rules. At the same time, it constructs the results generated by the off-chain microservices that require consensus to advance the process into transactions and submits them back to the corresponding on-chain process smart contracts for verification and state updates. Through this system, the "command" (state and rules) of the business process is on-chain, while the "execution" (complex calculations and interactions) is off-chain. The two coordinate in an orderly manner through the link coordination service, ensuring that the entire process runs efficiently under a trustworthy premise.

[0010] Preferably, the on-chain process smart contract includes: The status management module is used to maintain the current status of procurement projects on the blockchain; The event triggering module is used to generate and broadcast on-chain events that drive state transitions or execute business operations when predefined business rules are met. And a data storage module, used to store the hash value or ciphertext of key business data that has been verified by multiple parties.

[0011] Preferably, the link coordination service includes: The event listening and parsing unit is used to subscribe to and parse on-chain event logs from the blockchain network; The rule matching and routing unit is used to match pre-configured business rules based on the parsed event type and generate corresponding microservice call instructions; The service invocation and state synchronization unit is used to execute the microservice invocation instructions and encapsulate the consensus-required results generated in the off-chain business microservice cluster into transactions and submit them back to the blockchain network.

[0012] Preferably, the on-chain process smart contract cluster includes a negotiation procurement contract, which is configured to manage a multi-round sealed offer process, specifically including: The quotation submission interface is used to receive and store ciphertext quotations encrypted by suppliers using the purchaser's public key before the deadline for each round of quotations; The time-locking module is used to allow the bid decryption and reveal operation to be triggered only after the preset deadline for each round of bidding has been reached; It also includes an automatic advancement judgment module, which is used to automatically determine whether to start the next round of bidding or terminate negotiations based on the decrypted bidding results of this round and the advancement rules preset in the contract.

[0013] Preferably, the on-chain process smart contract cluster includes an expert review management contract, which is configured to support anonymous review, specifically including: A verifiable random function unit is used to randomly select a specified number of review experts from the expert pool based on an on-chain random source before the review begins, and generate encrypted review task credentials. An anonymous commitment interface is used to receive review participation commitments generated by selected experts using their private keys without revealing their real identities. And a blind review record unit, used to receive and store review results signed by the anonymous key of the review experts. Before the review results are summarized, the correspondence between the review results and the expert identities is not visible to either the on-chain or off-chain systems.

[0014] Preferably, the automatic advancement judgment module in the negotiated procurement contract includes price convergence judgment rules in its advancement rules. The price convergence determination rule is configured as follows: compare the best bid in the two most recent rounds of bidding, and if the price change is less than a preset convergence threshold, then the price is determined to have converged, and the negotiation termination process is triggered.

[0015] Preferably, the expert review management contract also includes a review result disclosure module; The review result disclosure module is configured to allow selected experts to disclose the relationship between their identity and the review results after a preset review result disclosure time point, for audit verification.

[0016] Preferably, the system also includes a privacy computing module; The privacy computing module is integrated into the off-chain business microservice cluster or serves as an independent trusted execution environment, and is configured to perform calculations on sensitive business data in an encrypted state. The link coordination service is further configured to: schedule services requiring privacy computation to the privacy computation module, and submit the hash value of the computation result to the on-chain process smart contract for notarization.

[0017] Preferably, the on-chain process smart contract cluster also includes procurement project factory contracts; The procurement project factory contract is configured to dynamically deploy new on-chain process smart contract instances corresponding to specific procurement projects based on the procurement creation requests submitted by users through the off-chain business microservice cluster.

[0018] Preferably, the blockchain network is a consortium blockchain network, and the consensus nodes are operated and maintained by the purchaser, regulatory agency and trusted third-party institution respectively.

[0019] The beneficial effects of this invention are: This invention's system deploys an on-chain smart contract encoding complete business logic for each procurement project. This ensures that every state transition, from supplier invitation, sealed bids, anonymous review to contract signing, occurs automatically only after meeting the pre-set consensus conditions of the on-chain contract. The business process itself becomes transparent, trustworthy, and tamper-proof. A link coordination service acts as a glue, ensuring seamless integration between on-chain rules and efficient off-chain execution. For negotiated procurement, multi-round sealed bids and automatic advancement mechanisms prevent information leakage and human manipulation. For expert review, verifiable random selection and anonymous commitment technologies guarantee fairness and the privacy of review experts. Furthermore, the introduction of a privacy computing module makes business analysis possible while keeping data available but invisible. This invention constructs an intrinsically trustworthy, intelligently automated, and deeply privacy-protected digital monitoring and procurement system. It fundamentally solves the problems of process black boxes, data silos, privacy leaks, and fairness issues present in traditional systems and existing blockchain evidence storage solutions, achieving end-to-end, intrinsically trustworthy monitoring and automated intelligent execution from procurement needs to contract fulfillment. Attached Figure Description

[0020] Figure 1 The diagram shown is a schematic representation of the overall architecture of the blockchain-based intelligent digital monitoring and procurement system of the present invention. Figure 2 The diagram illustrates the workflow of the blockchain-based intelligent digital monitoring and procurement system's link coordination service according to the present invention. Figure 3 The diagram shown is a sequence diagram of the multi-round sealed quotation negotiation process of the blockchain-based intelligent digital monitoring and procurement system of the present invention. Detailed Implementation

[0021] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0022] Example 1 Please see Figure 1 , Figure 2 and Figure 3 This invention provides an embodiment: a blockchain-based intelligent digital monitoring and procurement system, comprising: A blockchain network, consisting of multiple consensus nodes, is used to provide distributed ledger services. The on-chain process smart contract cluster is deployed on the blockchain network to instantiate an independent smart contract for each created procurement project. The smart contract defines the core business process logic, state transition rules and key operation consensus conditions of the corresponding procurement project. Off-chain business microservice clusters are used to perform non-consensus complex calculations, user interactions, and external system integration in procurement operations; And link coordination service, which communicates and connects with the on-chain process smart contract cluster and the off-chain business microservice cluster respectively; The link coordination service is configured to: listen for state transitions and business events triggered by on-chain process smart contracts, and schedule corresponding off-chain business microservices to perform business operations based on the event type; at the same time, submit the business results that need to be agreed upon after the off-chain business microservices are executed to the corresponding on-chain process smart contracts to drive process state updates.

[0023] The blockchain network consists of multiple consensus nodes, providing underlying distributed ledger and consensus services. The on-chain process smart contract cluster is deployed on this blockchain network. Its core innovation lies in the fact that the system does not simply share a common notarization contract for all procurement projects, but dynamically instantiates an independent, dedicated smart contract for each newly created procurement project. This dedicated contract defines the complete core business process logic of the specific project (such as the inquiry and comparison process or negotiation process), all possible states (such as "creating," "quoting," "reviewing," "awarded," "fulfilled," "completed") and the rules governing their flow, as well as the consensus conditions (such as reaching the deadline or obtaining sufficient signatures) required for any key operation (such as ending the quotation or submitting the review results). The off-chain business microservice cluster is responsible for handling complex business logic that does not require global consensus, such as: rich user interface interaction, data integration with external ERP / OA systems, storage and management of large files (such as tender documents and design drawings), complex data analysis and report generation, etc. Its architecture adopts a microservice model, with each service having a single responsibility and collaborating through APIs. The Link Coordination Service is configured to perform the following core responsibilities: continuously monitor on-chain events representing state transitions or key actions issued by the on-chain process smart contracts specific to each project; after parsing these events, schedule the corresponding off-chain business microservices to execute specific business operations according to predefined mapping rules (e.g., when a "project created" event is detected, schedule the supplier management service to send an invitation notification); simultaneously, it constructs the results generated by the off-chain microservices that require consensus to advance the process (e.g., a confirmed supplier list, encrypted bid submission credentials) into transactions and submits them back to the corresponding on-chain process smart contracts for verification and state updates; through this design, the "command" (state and rules) of the business process is on-chain, while the "execution" (complex calculations and interactions) is off-chain, and the two coordinate in an orderly manner through the Link Coordination Service, ensuring that the entire process runs efficiently under a trustworthy premise.

[0024] Furthermore, on-chain process smart contracts include: The status management module is used to maintain the current status of procurement projects on the blockchain; The event triggering module is used to generate and broadcast on-chain events that drive state transitions or execute business operations when predefined business rules are met. And a data storage module, used to store the hash value or ciphertext of key business data that has been verified by multiple parties.

[0025] The state management module maintains a state variable that clearly identifies the current stage of the project and defines state transition functions, which are usually accompanied by strict permissions and condition modifiers. The event triggering module broadcasts standardized events to the outside world through the blockchain's event log mechanism when the state changes or key data is added to the chain. This is the only way for the link coordination service to perceive changes on the chain. The data storage module is responsible for storing the fingerprints of key business data that have been confirmed by multiple parties (such as supplier digital signatures) in hash or encryption form, forming an immutable chain of evidence. These modules work together to ensure that each procurement project has a self-contained and independently verifiable lifecycle record on the chain.

[0026] Furthermore, the link coordination service includes: The event listening and parsing unit is used to subscribe to and parse on-chain event logs from the blockchain network; The rule matching and routing unit is used to match pre-configured business rules based on the parsed event type and generate corresponding microservice call instructions; The service invocation and state synchronization unit is used to execute microservice invocation instructions and encapsulate the consensus-required results generated in the off-chain business microservice cluster into transactions and submit them back to the blockchain network.

[0027] The link coordination service consists of multiple units working collaboratively. The event listening and parsing unit subscribes to event logs through the blockchain node's RPC interface or message middleware and converts them into internally processable business event objects. The rule matching and routing unit queries the rule base based on the event type to determine which off-chain microservices(s) need to be woken up next, and generates specific call instructions and parameters. The service call and state synchronization unit executes the call instructions, calls the corresponding microservice API, and receives the processing results. If the result needs to be fed back to the chain, this unit is responsible for constructing a correctly formatted blockchain transaction, calling the corresponding smart contract function, and solidifying the consensus result, thereby completing a closed loop from on-chain to off-chain and back to on-chain.

[0028] Furthermore, the on-chain process smart contract cluster includes a negotiation procurement contract, which is configured to manage a multi-round sealed offer process, specifically including: The quotation submission interface is used to receive and store ciphertext quotations encrypted by suppliers using the purchaser's public key before the deadline for each round of quotations; The time-locking module is used to allow the bid decryption and reveal operation to be triggered only after the preset deadline for each round of bidding has been reached; It also includes an automatic advancement judgment module, which is used to automatically determine whether to start the next round of bidding or terminate negotiations based on the decrypted bidding results of this round and the advancement rules preset in the contract.

[0029] Specifically, the on-chain process smart contract cluster includes a negotiation and procurement contract. This contract is configured to implement a secure and fair multi-round sealed bid process. Before the deadline for each round of bidding, its bid submission interface only accepts and stores ciphertext bids encrypted with the purchaser's public key, ensuring that no one can access the bid content during this period. The time-locking module utilizes the timestamp feature of the blockchain to ensure that the function for unlocking and decrypting bids can only be successfully called after the on-chain time reaches the preset deadline block height or timestamp. The automatic advancement judgment module has built-in business rules (e.g., "if there are at least two qualified bids and the best price drops by more than 5%, then proceed to the next round"). After the bids in the current round are decrypted and verified, the rules are automatically executed to determine whether to update the project status to "entering round N+1" or "negotiation terminated, winning bidder determined". This process is entirely executed automatically by the code, eliminating the risk of human intervention and premature disclosure.

[0030] Furthermore, the on-chain process smart contract cluster includes an expert review management contract, which is configured to support anonymous review, specifically including: A verifiable random function unit is used to randomly select a specified number of review experts from the expert pool based on an on-chain random source before the review begins, and generate encrypted review task credentials. An anonymous commitment interface is used to receive review participation commitments generated by selected experts using their private keys without revealing their real identities. And a blind review record unit, used to receive and store review results signed by the anonymous key of the review experts. Before the review results are summarized, the correspondence between the review results and the expert identities is not visible to either the on-chain or off-chain systems.

[0031] Specifically, the on-chain process smart contract cluster also includes an expert review management contract; this contract provides technical protection for anonymous review; when experts need to be selected, the verifiable random function unit uses an on-chain random source (such as the hash of the previous block) as a seed to randomly select a specified number of experts from the registered list of expert public keys; due to the determinism of VRF, the process can be verified by any node afterward, and the result is unpredictable before it is generated; the anonymous commitment interface allows the selected expert to use a temporary key pair (or blind signature technology) decoupled from their real identity to submit a commitment to participate in the review, proving that they are "one of the selected experts" but without revealing "who exactly they are"; the blind review record unit then receives the review results (such as fractional hashes) signed by the experts using their anonymous keys, and before the aggregation stage, the association between all individual review records and anonymous identities is not visible to the system, only leaving immutable signature records on the chain, to be revealed by subsequent optional audits.

[0032] Furthermore, the automatic escalation judgment module in the negotiated procurement contract includes price convergence judgment rules as its escalation rules. The price convergence determination rule is configured as follows: compare the best bid in the two most recent rounds of bidding, and if the price change is less than the preset convergence threshold, then the price is determined to have converged, and the negotiation termination process is triggered.

[0033] Specifically, the automatic advancement judgment module in the aforementioned negotiation procurement contract has a built-in advancement rule: a price convergence judgment rule. This rule can be implemented as follows: Let the optimal bid in round i be P_i, the optimal bid in round i-1 be P_{i-1}, and the preset convergence threshold be δ (e.g., 0.01 represents 1%). This rule is configured to calculate the relative change rate |(P_i - P_{i-1}) / P_{i-1}|. If this value is less than δ, it is determined that the price has sufficiently converged, and the benefits of continuing negotiation are limited, thus triggering the negotiation termination process and declaring the best bidder in round i as the winning candidate. This quantitative rule further reduces subjective judgment and improves the automation and objectivity of the process.

[0034] Furthermore, the expert review management contract also includes a review results disclosure module; The review results disclosure module is configured to allow selected experts to disclose the relationship between their identity and the review results after a preset review results disclosure time point, for audit verification.

[0035] Specifically, the expert review management contract also includes a review result disclosure module; this module has a delayed disclosure mechanism; after the review is completed and the results are summarized (or after a preset period of time), this module allows the experts who participated in the review to use their real identity keys to disclose the correlation between the previous anonymity commitment and the review results, such as presenting a zero-knowledge proof or a specific signature to prove that a certain anonymous review record was written by them; this mechanism, while ensuring the anonymity of the review process, provides technical possibilities for post-event auditing, accountability or dispute resolution, achieving a balance between confidentiality and auditability.

[0036] Furthermore, the system also includes a privacy computing module; The privacy computing module is integrated into the off-chain business microservice cluster or as an independent trusted execution environment, and is configured to perform computations on sensitive business data in an encrypted state. The link coordination service is further configured to: schedule services that require privacy computation to the privacy computation module, and submit the hash value of the computation result to the on-chain process smart contract for notarization.

[0037] Specifically, the system also integrates a privacy computing module. This module can be deployed as a special service in an off-chain business microservice cluster or run in an independent hardware trusted execution environment. It is configured to directly perform calculations on encrypted sensitive data (such as homomorphically encrypted quotes and cost data shared by secure multi-party computation) and output encrypted calculation results. When the link coordination service performs business scheduling, if it identifies a task involving sensitive data calculation (for example, calculating the average of multiple encrypted quotes), it will schedule the encrypted data to the privacy computing module. After the module completes the calculation, the hash value of the output result is submitted to the blockchain for notarization, while the original encrypted data and calculation results do not need to be decrypted throughout the process. This achieves a high degree of privacy protection for the original data while supporting complex business analysis.

[0038] Furthermore, the on-chain process smart contract cluster also includes procurement project factory contracts; The procurement project factory contract is configured to dynamically deploy new on-chain process smart contract instances corresponding to specific procurement projects based on procurement creation requests submitted by users through the off-chain business microservice cluster.

[0039] Specifically, the on-chain process smart contract cluster also includes a procurement project factory contract; this contract, as a "contract of contracts," is key to the system's dynamism; when a user initiates a procurement request through the front end, and it passes the initial verification by the off-chain microservice, the link coordination service calls the "create project" function of this factory contract; this function receives metadata such as procurement type and basic parameters, then dynamically deploys a new project-specific smart contract instance on the blockchain and returns its address; this approach allows the system to flexibly support an unlimited number of parallel procurement projects, each project being an independent, autonomous on-chain entity.

[0040] Furthermore, the blockchain network is a consortium blockchain network, with consensus nodes operated and maintained by the purchaser, regulatory agency, and trusted third-party institution, respectively.

[0041] Specifically, the blockchain network adopts a consortium blockchain architecture; consensus nodes are jointly operated and maintained by the purchaser, relevant regulatory agencies, and trusted third-party institutions recognized by both parties. This node configuration not only ensures the privacy of procurement business data (not fully open to the public), but also forms multi-centralized supervision by introducing regulatory agencies and third-party nodes, enhancing the credibility of the entire system and meeting the requirements of enterprise-level compliance supervision.

[0042] Through the above steps, the system of this invention deploys an on-chain process smart contract with complete business logic encoded for each procurement project. This ensures that every state transition from supplier invitation, sealed bids, anonymous review to contract signing occurs automatically after meeting the consensus conditions preset by the on-chain contract. The business process itself becomes transparent, trustworthy, and tamper-proof. The link coordination service acts as a glue, ensuring seamless integration between on-chain rules and efficient off-chain execution. For negotiated procurement, multi-round sealed bids and automatic advancement mechanisms prevent information leakage and human manipulation. For expert review, verifiable random selection and anonymous commitment technologies guarantee the fairness of the review and the privacy of the review experts. In addition, the introduction of a privacy computing module makes it possible to conduct business analysis under the premise that the data is available but not visible. This invention constructs an intrinsically trustworthy, intelligently automated, and deeply privacy-protected digital monitoring and procurement system, fundamentally solving the problems of process black boxes, data silos, privacy leaks, and difficulty in ensuring fairness in traditional systems and existing blockchain evidence storage solutions. It achieves endogenous trustworthy monitoring and automated intelligent execution of the entire process from procurement demand to contract fulfillment.

[0043] Example 2 Optionally, this embodiment details the infrastructure and core workflow of a blockchain-based intelligent digital monitoring and procurement system.

[0044] The system specifically includes the following parts: Blockchain Network: This implementation adopts a Fabric consortium blockchain network consisting of four consensus nodes (11, 12, 13, 14). Node 11 is operated and maintained by the purchasing group, node 12 is operated and maintained by the group's internal audit department, and nodes 13 and 14 are operated and maintained by two different cloud service providers recognized by both parties as trusted third parties. The network uses Kafka consensus ordering service to ensure the consistency of transaction order. The network provides a distributed ledger to record the state and transaction logs of all smart contracts.

[0045] On-chain process smart contract cluster: This cluster is deployed on the blockchain network and contains a series of smart contract codes. In this embodiment, the cluster contains at least one "procurement project factory contract" and multiple types of "business logic contract templates". The factory contract is responsible for dynamically creating instances according to the procurement type. The business logic contract templates include "price inquiry and comparison procurement contract template" and "negotiation procurement contract template". When a new procurement project is created, the system will deploy an independent smart contract instance dedicated to the project on the chain based on the corresponding template, such as "procurement project X contract (address: 0x123...)". The instantiated contract internally maintains the project's state variables, business rule functions, and key data storage.

[0046] Off-chain business microservice cluster: This cluster is deployed on the purchaser's private cloud Kubernetes container platform and contains multiple loosely coupled microservices; mainly including: Procurement project management services: handling procurement requests, planning, etc.; Supplier Management Services: Manage the supplier database, process invitations and registrations; File storage service: Uses MinIO object storage to save large unstructured data such as tender documents and bid documents, and returns the file hash; Notification service: Send process notifications via SMS, email, or in-site message; External system adaptation service: Data synchronization with the group's ERP and OA systems via WebService interface.

[0047] Link coordination service: This service is deployed as a standalone Spring Boot application and is the "central nervous system" of the system; it includes: Event Listening and Parsing Unit: Subscribes to the event logs of all contracts on the blockchain network via a gRPC long connection; it uses the web3j library to listen for events and parses the raw blockchain logs into internally defined standardized business event objects, such as ProjectCreatedEvent and BidSubmissionDeadlineEvent.

[0048] Rule matching and routing unit: Maintains a rule configuration database (such as Redis) that stores the mapping relationship between event types and target microservice APIs; for example, rules {"eventType": "PROJECT_CREATED", "action": "CALL", "service": "supplier-service", "api": " / api / invite"}; Upon receiving an event, this unit queries the rules and generates a specific HTTP call request.

[0049] Service Invocation and State Synchronization Unit: Using RestTemplate or OpenFeign client, execute the HTTP request generated by the rule matching and routing unit to invoke the corresponding microservice; upon receiving the microservice response, if the response contains data that needs to be uploaded to the chain (such as the hash of the confirmed supplier list), this unit will construct a blockchain transaction, call the corresponding function of the corresponding project contract instance (such as addSupplier), write the data to the chain, and complete the state synchronization.

[0050] The specific workflow is as follows: Let's take a simplified "procurement project creation and supplier invitation" process as an example to illustrate the collaborative working principle of the various components of the system: Step S101: The purchasing agent submits a purchase request through the front-end page; the front-end calls the procurement project management service in the chain; Step S102: After the procurement project management service performs business logic verification (such as budget check), it generates basic project data and then calls the "Project Creation" interface of the link coordination service. Step S103: The link coordination service's service call and state synchronization unit sends a transaction to the blockchain network, calls the createNegotiationProject function of the procurement project factory contract, and passes in the project parameters; Step S104: The procurement project factory contract deploys a new negotiated procurement contract instance on the chain and initializes its state to "CREATED" (creating), while triggering a ProjectInitialized on-chain event; Step S105: The event listening and parsing unit listens to the event, parses it into an internal event object of ProjectCreatedEvent, and passes it to the rule matching and routing unit; Step S106: The rule matching and routing unit matches a rule and indicates that the invitation interface of the supplier management service needs to be called; the service call and status synchronization unit then calls the interface and passes the project ID. Step S107: The supplier management service executes the invitation logic, selects suppliers from the database, generates an invitation list, and returns the Merkle tree root hash of the list to the link coordination service; Step S108: The service call and state synchronization unit uses the root hash as a parameter to construct a transaction call to the confirmSuppliers function of the project contract instance and puts the hash value on the chain; if the contract function executes successfully, the state may change to "SUPPLIER_INVITING" and trigger a new event; Subsequent processes (such as supplier confirmation of participation) will repeat the "event listening - rule matching - service call - state synchronization" loop of S105-S108, driving the process until it ends.

[0051] Through the above implementation methods, the system achieves the separation and collaboration of the "command center" (on-chain contract) and the "execution unit" (off-chain microservice) of the business process, ensuring the immutability of the process rules and the high efficiency of execution.

[0052] Example 3 Optionally, this embodiment, based on embodiment 2, further details the specific implementation of the functions of multi-round sealed bids, automatic advancement judgment, and privacy calculation in negotiated procurement.

[0053] The enhanced implementation of on-chain negotiated procurement contracts specifically includes: The negotiated procurement contract example in this embodiment includes the following key functions and data structures: contract NegotiationContract { enum RoundState { Pending, Sealed, Revealed, Calculated} struct NegotiationRound { uint256 roundNumber; uint256 sealedDeadline; / / Deadline for sealed quotes uint256 revealDeadline; / / Reveal the start timestamp RoundState state; mapping(address => bytes) sealedBids; / / Supplier address -> encrypted quote ciphertext mapping(address =>uint256) revealedBids; / / Supplier address -> decrypted quote address bestBidder; uint256 bestBidPrice; } NegotiationRound[] public rounds; uint256 public currentRoundIndex; uint256 public priceConvergenceThreshold; / / Price convergence threshold δ, e.g., 100 represents 1%. / / Supplier submits encrypted quote function submitSealedBid(uint256 _roundIndex, bytes calldata _encryptedBid) external onlyInvitedSupplier onlyDuringSealingPeriod(_roundIndex) { rounds[_roundIndex].sealedBids[msg.sender]= _encryptedBid; emit BidSealed(msg.sender, _roundIndex, keccak256(_encryptedBid)); } / / After the (off-chain) purchaser decrypts the data, they submit a plaintext quote for disclosure (disclosure period only). function revealBid(uint256 _roundIndex, address _supplier, uint256 _bidPrice, bytes calldata _proof) external onlyBuyer onlyDuringRevealPeriod(_roundIndex) { / / Verify the correspondence between the submitted price and the previously sealed Bids (this can be achieved through zero-knowledge proofs or signatures). require(verifyRevealProof(_supplier, rounds[_roundIndex].sealedBids[_supplier], _bidPrice, _proof), "Invalid proof"); rounds[_roundIndex].revealedBids[_supplier]= _bidPrice; / / Update the best offer for this round if (_bidPrice <rounds[_roundIndex].bestBidPrice || rounds[_roundIndex].bestBidder == address(0)) { rounds[_roundIndex].bestBidPrice = _bidPrice; rounds[_roundIndex].bestBidder = _supplier; } } / / Automatically determine whether to advance to the next round function finalizeRoundAndCheckProgression(uint256 _roundIndex) external onlyBuyer afterRevealDeadline(_roundIndex) { require(rounds[_roundIndex].state == RoundState.Revealed, "Round notready"); uint256 currentBestPrice = rounds[_roundIndex].bestBidPrice; address currentBestBidder = rounds[_roundIndex].bestBidder; if (_roundIndex == 0) { / / In the first round, if a valid bid is received, the second round will begin. _setupNewRound(_roundIndex + 1, currentBestPrice);} else { uint256 previousBestPrice = rounds[_roundIndex - 1].bestBidPrice; / / Calculate the rate of price change and determine if it converges. / / Formula: changeRate = abs(currentBestPrice - previousBestPrice) 10000 / previous Best Price uint256 changeRate = _absDiff(currentBestPrice, previousBestPrice) 10000 / previous Best Price; / / If the rate of change is less than the threshold δ, then convergence is determined, and the negotiation ends. if (changeRate <priceConvergenceThreshold) { _finalizeNegotiation(currentBestBidder, currentBestPrice); } else { / / If the convergence fails, advance to the next round. _setupNewRound(_roundIndex + 1, currentBestPrice); } } rounds[_roundIndex].state = RoundState.Calculated; } / / Internal function: Sets the parameters for the new round (e.g., the new target price is 95% of the previous optimal price). function _setupNewRound(uint256 _newRoundIndex, uint256 _referencePrice) internal { rounds.push(NegotiationRound({ roundNumber: _newRoundIndex, sealedDeadline: block.timestamp + 2 days, revealDeadline: block.timestamp + 3 days, state: RoundState.Pending, bestBidder: address(0), bestBidPrice: type(uint256).max })); currentRoundIndex = _newRoundIndex; emit NewRoundStarted(_newRoundIndex, _referencePrice 95 / 100); / / Announce a new round of target prices } } Here, changeRate represents the price change rate, in ten-thousandths (e.g., 50 represents 0.5%); priceConvergenceThreshold(δ) is a preset threshold; _absDiff is an internal function for calculating the absolute difference; by comparing changeRate and δ, the contract automatically decides whether to advance or terminate.

[0054] The privacy computing module is implemented as follows: A privacy computing service has been added to the off-chain business microservice cluster; this service is deployed in a trusted execution environment equipped with Intel SGXenclave; its main function is to perform homomorphic cryptographic computation.

[0055] Step S201 (Quote Encryption): At the beginning of each round, the Link Coordination Service calls the Privacy Computation Service to generate a pair of Paillier homomorphic encryption keys (pk_public key, sk_private key); the pk_public key is distributed to all invited suppliers through the notification service; Step S202 (Submitting Encrypted Quote): The supplier uses the pk public key to encrypt its own quote m, obtaining ciphertext c = Enc(pk, m), and then submits c through the front end; the ciphertext c is transmitted to the off-chain microservice and submitted by the link coordination service to the sealedBids mapping of the on-chain contract for storage; Step S203 (Off-chain privacy computation): When it is necessary to calculate the "average bid" for this round (for internal analysis, not to determine the winning bid), the link coordination service schedules the encrypted c1, c2, ..., cn submitted by all suppliers to the privacy computation service; Step S204 (Homomorphic Computation): The privacy-preserving computation service performs computation directly on the ciphertext within the enclave; Paillier encryption has the homomorphic addition property: Enc(pk, m1). Enc(pk, m2) = Enc(pk, m1+m2); Service computation c_avg =(c1 c2 ... cn)^(1 / n) mod n^2 (scalar multiplication needs to be performed in the ciphertext field to simulate division) to obtain the encrypted average ciphertext c_avg; Step S205 (Result Storage): The privacy computation service outputs the hash value H(c_avg) of c_avg; the link coordination service submits the hash value to the chain for storage; the purchaser can use the private key sk_ to decrypt c_avg to obtain the plaintext average price, but the price m_i of a single supplier is never decrypted during the entire calculation process, effectively protecting commercial privacy.

[0056] The complete multi-round negotiation process is integrated as follows: Based on the collaborative mechanism of Example 2, a complete negotiation process is as follows: Project creation and the first round (S101-S108); The supplier uses the public key to encrypt the quote and calls the contract submitSealedBid (triggered by an on-chain event). The link coordination service detects the BidSealed event, but no off-chain action is required in this round; it only records the event. When the sealing deadline arrives, the link coordination service detects a status event, and the scheduling notification service reminds the purchaser to reveal the results. The purchaser uses a private key to decrypt all sealedBids in the system and calls the contract's revealBid function one by one to submit the plaintext and proof. After all the quotes are revealed, the buyer triggers the finalizeRoundAndCheckProgression function; The contract automatically executes the price convergence determination formula; if convergence is determined, the NegotiationFinalized event is triggered, and the process enters the scaling phase; if advancement is determined, the NewRoundStarted event is triggered. The link coordination service listens for the NewRoundStarted event, and the scheduling notification service sends a new round of invitations and new target prices to the remaining suppliers, and the process enters the next round of the loop.

[0057] Example 4 Optionally, this embodiment, based on embodiment 2, details the specific implementation of the anonymous expert review function.

[0058] The implementation of the on-chain expert review management contract is as follows: The system deploys a global expert review management contract in the on-chain process smart contract cluster, and each project that needs to be reviewed is associated with a project review sub-contract.

[0059] The expert review management contract is responsible for managing the expert pool and verifying random selection. Part of the code is shown below: contract ExpertPoolManager { struct Expert { bytes32 identityCommitment; / / Identity commitment (such as a blinded public key hash) address registeredBy; / / Registration Authority bool isActive; } bytes32[] public expertCommitmentList; / / List of active expert commitments mapping(bytes32 =>Expert) public experts; / / Random selection based on VRF function selectExperts(uint256 _seed, uint8 _count) public viewreturns (bytes32[] memory selectedCommitments, bytes32 proof) { require(_count<= expertCommitmentList.length, "Not enough experts"); / / Use an on-chain verifiable random function (requires a pre-compiled contract or oracle) / / Simplified representation here: Generating random indices using block hashes and seeds bytes32 randomness = keccak256(abi.encodePacked(blockhash(block.number - 1), _seed)); selectedCommitments = new bytes32[](_count); / / ... Using randomness as the entropy source, extract _count commitments without replacement from expertCommitmentList. / / proof = Generate VRF proof for external verification that the selection process was correct. return (selectedCommitments, proof); } } The following is a portion of the code for the anonymous review process of a specific project managed by the project review subcontract: contract ProjectReviewContract { struct AnonymousReview { bytes32 reviewerIdCommitment; / / Anonymous ID commitment submitted by the reviewer bytes32 reviewDataHash; / / Hash of review results (scores / comments) bytes signature; / / Sign reviewDataHash using an anonymous private key bool isRevealed; `address realIdentity;` / / Initially empty, filled after revealing. } mapping(bytes32 =>AnonymousReview) public reviews; / / key is reviewerIdCommitment uint256 public reviewSubmissionDeadline; uint256 public revelationDeadline; / / Deadline for revelation / / Submit anonymous review function submitAnonymousReview( bytes32 _reviewerIdCommitment, bytes32 _reviewDataHash, bytes calldata _signature ) external onlyBefore(reviewSubmissionDeadline) { / / Verify that _signature is the signature of _reviewDataHash based on the private key corresponding to _reviewerIdCommitment. require(verifySignature(_reviewerIdCommitment, _reviewDataHash, _signature), "Invalid sig"); reviews[_reviewerIdCommitment] = AnonymousReview({ reviewerIdCommitment: _reviewerIdCommitment, reviewDataHash: _reviewDataHash, signature: _signature, isRevealed: false, realIdentity: address(0) }); emit ReviewSubmitted(_reviewerIdCommitment, _reviewDataHash); } / / Reveal the identity of the reviewer function revealReviewerIdentity( bytes32 _reviewerIdCommitment, address _realIdentity, bytes calldata _revealProof ) external onlyAfter(reviewSubmissionDeadline) onlyBefore(revelationDeadline) { / / Verify that _revealProof can prove the correspondence between _realIdentity and _reviewerIdCommitment. / / For example, prove that the public key hash of _realIdentity is equal to _reviewerIdCommitment after blinding. require(verifyRevealProof(_reviewerIdCommitment, _realIdentity, _revealProof), "Invalid reveal"); AnonymousReview storage r = reviews[_reviewerIdCommitment]; require(!r.isRevealed, "Already revealed"); r.realIdentity = _realIdentity; r.isRevealed = true; emit ReviewerRevealed(_reviewerIdCommitment, _realIdentity,r.reviewDataHash); } } The anonymous review process is implemented as follows: Step S301 (Random selection of experts): When a project needs to be reviewed, the link coordination service calls the selectExperts function of the expert review management contract, passes in a random seed (such as project ID), and requests the selection of 3 experts; the contract returns the selected experts' commitments selectedCommitments and VRF proof. Step S302 (Anonymous Task Distribution): The link coordination service listens for the selection completion event and schedules the notification service. The notification service does not contact the experts directly, but submits the selectedCommitments and the review task description to a secure anonymous task transfer station (such as an HTTPS interface, which requires credentials to access). At the same time, the system generates a one-time anonymous access token for each selected expert, which is associated with one of the selectedCommitments. Step S303 (Anonymous Expert Submission): The selected expert obtains their own anonymous token through a specific channel (such as an internal security portal); the expert logs into the review system using a temporarily generated key pair (anonymous key pair) unrelated to their real identity; the system displays the materials to be reviewed to the expert; after completing the review, the expert generates review result data, calculates its hash reviewDataHash, and signs it with their anonymous private key to obtain a signature; the expert submits reviewerIdCommitment (the hash of their anonymous public key), reviewDataHash, and signature through the front end; the front end calls the chain coordination service, which submits it to the submitAnonymousReview function of the project review subcontract; at this point, only the anonymous commitment, hash, and signature are recorded on the chain, and cannot be linked to the real expert; Step S304 (Summary of Review Results): After the review deadline, the link coordination service can obtain all reviewDataHash and signature from the chain, and summarize and calculate the scores off-chain (assuming that the scoring data is in the original text corresponding to reviewDataHash); the hash of the summary result (such as the average score) can be submitted back to the chain for evidence storage. Step S305 (Selective Identity Disclosure): Before the revelationDeadline set by the project review subcontract (e.g., 6 months after project completion), experts can selectively disclose their identity. Experts submit proof of their real identity (e.g., the digital identity _realIdentity corresponding to a company employee ID) and a _revealProof (e.g., a zero-knowledge proof proving "I know a private key whose corresponding public key hash is equal to reviewerIdCommitment after blinding, and this private key is the same as the certificate signing key of my real identity _realIdentity") through a secure interface. The chain coordination service assists in submitting this disclosure transaction to the contract's revealReviewerIdentity function. Upon success, an anonymous review record is linked to the real identity on the chain for auditing purposes. Experts can also choose never to disclose their identity.

[0060] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A blockchain-based intelligent digital monitoring and procurement system, characterized in that: include: A blockchain network, consisting of multiple consensus nodes, is used to provide distributed ledger services. The on-chain process smart contract cluster is deployed on the blockchain network to instantiate an independent smart contract for each created procurement project. The smart contract defines the core business process logic, state transition rules and key operation consensus conditions of the corresponding procurement project. Off-chain business microservice clusters are used to perform non-consensus complex calculations, user interactions, and external system integration in procurement operations; And link coordination service, which communicates and connects with the on-chain process smart contract cluster and the off-chain business microservice cluster respectively; The link coordination service is configured to: listen for state transitions and business events triggered by the on-chain process smart contract, and schedule the corresponding off-chain business microservices to perform business operations based on the event type; at the same time, submit the business results that need to be agreed upon after the off-chain business microservices are executed to the corresponding on-chain process smart contract to drive process state updates.

2. The blockchain-based intelligent digital monitoring and procurement system according to claim 1, characterized in that: The on-chain process smart contract includes: The status management module is used to maintain the current status of procurement projects on the blockchain; The event triggering module is used to generate and broadcast on-chain events that drive state transitions or execute business operations when predefined business rules are met. And a data storage module, used to store the hash value or ciphertext of key business data that has been verified by multiple parties.

3. The blockchain-based intelligent digital monitoring and procurement system according to claim 1, characterized in that: The link coordination service includes: The event listening and parsing unit is used to subscribe to and parse on-chain event logs from the blockchain network; The rule matching and routing unit is used to match pre-configured business rules based on the parsed event type and generate corresponding microservice call instructions; The service invocation and state synchronization unit is used to execute the microservice invocation instructions and encapsulate the consensus-required results generated in the off-chain business microservice cluster into transactions and submit them back to the blockchain network.

4. The blockchain-based intelligent digital monitoring and procurement system according to claim 1, characterized in that: The on-chain process smart contract cluster includes a negotiation procurement contract, which is configured to manage a multi-round sealed bid process, specifically including: The quotation submission interface is used to receive and store ciphertext quotations encrypted by suppliers using the purchaser's public key before the deadline for each round of quotations; The time-locking module is used to allow the bid decryption and reveal operation to be triggered only after the preset deadline for each round of bidding has been reached; It also includes an automatic advancement judgment module, which is used to automatically determine whether to start the next round of bidding or terminate negotiations based on the decrypted bidding results of this round and the advancement rules preset in the contract.

5. The blockchain-based intelligent digital monitoring and procurement system according to claim 1, characterized in that: The on-chain process smart contract cluster includes an expert review management contract, which is configured to support anonymous review, specifically including: A verifiable random function unit is used to randomly select a specified number of review experts from the expert pool based on an on-chain random source before the review begins, and generate encrypted review task credentials. An anonymous commitment interface is used to receive review participation commitments generated by selected experts using their private keys without revealing their real identities. And a blind review record unit, used to receive and store review results signed by the anonymous key of the review experts. Before the review results are summarized, the correspondence between the review results and the expert identities is not visible to either the on-chain or off-chain systems.

6. The blockchain-based intelligent digital monitoring and procurement system according to claim 4, characterized in that: The automatic advancement judgment module in the negotiated procurement contract includes price convergence judgment rules in its advancement rules. The price convergence determination rule is configured as follows: compare the best bid in the two most recent rounds of bidding, and if the price change is less than a preset convergence threshold, then the price is determined to have converged, and the negotiation termination process is triggered.

7. The blockchain-based intelligent digital monitoring and procurement system according to claim 5, characterized in that: The expert review management contract also includes a review result disclosure module; The review result disclosure module is configured to allow selected experts to disclose the relationship between their identity and the review results after a preset review result disclosure time point, for audit verification.

8. The blockchain-based intelligent digital monitoring and procurement system according to claim 1, characterized in that: The system also includes a privacy computing module; The privacy computing module is integrated into the off-chain business microservice cluster or serves as an independent trusted execution environment, and is configured to perform calculations on sensitive business data in an encrypted state. The link coordination service is further configured to: schedule services requiring privacy computation to the privacy computation module, and submit the hash value of the computation result to the on-chain process smart contract for notarization.

9. The blockchain-based intelligent digital monitoring and procurement system according to claim 1, characterized in that: The on-chain process smart contract cluster also includes procurement project factory contracts; The procurement project factory contract is configured to dynamically deploy new on-chain process smart contract instances corresponding to specific procurement projects based on the procurement creation requests submitted by users through the off-chain business microservice cluster.

10. The blockchain-based intelligent digital monitoring and procurement system according to claim 1, characterized in that: The blockchain network is a consortium blockchain network, and the consensus nodes are operated and maintained by the purchaser, regulatory agency, and trusted third-party institution, respectively.