Blockchain-based collaborative manufacturing multi-agent data sharing and benefit confirmation method

Abstract

The application discloses a blockchain-based collaborative manufacturing multi-agent data sharing and right confirmation method, and is suitable for a collaborative scene of supplier production and distribution-general unit assembly. The method comprises the following steps: constructing an alliance blockchain system of double-agent nodes and consensus nodes, and guaranteeing interaction safety by combining permission grading and zero-knowledge proof; after production, distribution and assembly data collected by the double agents in the whole process are standardized by XML, encrypted by RSA and processed by SHA-256 hash, the data are stored in a chain for evidence; deploying a smart contract written in Solidity language, and automatically quantifying rights based on a four-dimensional system (contribution degree, value degree, quality degree and use frequency); realizing authorized sharing through smart contract verification, and completing whole life cycle tracing relying on data hash values. The application realizes data credible sharing and clear definition of rights, improves collaborative efficiency and fairness, and protects the core data privacy of the agents.

Description

Technical Field

[0001] This invention relates to the intersection of networked collaborative manufacturing and blockchain technology, specifically to a blockchain-based method for multi-entity data sharing and rights confirmation in collaborative manufacturing. Background Technology

[0002] In the networked collaborative manufacturing model of supplier production and distribution and overall unit final assembly, data has become the core link connecting the two main entities. Suppliers need to dynamically adjust the production and distribution rhythm of parts based on the overall unit's final assembly plan, while the overall unit relies on the supplier's production progress, quality inspection and other data to optimize the final assembly schedule. However, current mainstream data sharing mechanisms still rely on traditional centralized architectures, which are ill-suited to the collaborative needs of this scenario, highlighting three core flaws: First, data interaction suffers from a "trust barrier." Suppliers and the overall unit are independent stakeholders, and the centralized platform's data storage permissions are concentrated in the hands of one party or a third party, leading to doubts about the authenticity of the data. For example, suppliers may question the real-time nature of final assembly progress data, while the overall unit may worry about the tampering of component quality data. Second, the definition of data rights is "undocumented." In the flow of data such as component production parameters, delivery trajectories, and final assembly requirement lists, the contribution boundaries and value weights are blurred. When data generates derivative value or causes quality disputes, it is difficult to clarify the responsible party and the attribution of rights. Third, data collaboration suffers from an "efficiency bottleneck." The data formats of the two parties are not uniform (e.g., suppliers use PDFs to record production data, while the overall unit uses Excel to manage final assembly information), requiring repeated manual verification and conversion. At the same time, it is difficult to balance the privacy protection and sharing needs of core technical data (such as the supplier's precision processing technology and the overall unit's modular final assembly plan). Either excessive encryption affects collaboration efficiency, or open permissions lead to the leakage of trade secrets. These problems directly lead to longer collaboration cycles, increased communication costs, and hinder the optimal allocation of manufacturing resources.

[0003] The distributed ledger, immutability, and automated execution of smart contracts inherent in blockchain technology offer a technological breakthrough for overcoming the aforementioned challenges. In recent years, some research has attempted to apply blockchain to manufacturing data storage, but existing solutions still have significant limitations for the highly interconnected and collaborative scenario of production, distribution, and final assembly: most solutions only achieve data storage on the blockchain, failing to address the standardized access issue of manufacturing data, leading to difficulties in interoperability of heterogeneous data from different entities; they lack a rights quantification model suitable for both supply and demand sides, making it impossible to accurately calculate the contribution value of component production data and final assembly scheduling data; and smart contracts are only used for simple permission verification, failing to form a fully automated closed loop. Therefore, there is an urgent need to build a blockchain solution that aligns with the collaborative needs of suppliers and overall units, achieving the dual goals of trusted data sharing and clear rights definition. Summary of the Invention

[0004] To address the aforementioned technical issues, this invention discloses a blockchain-based method for multi-entity data sharing and rights confirmation in collaborative manufacturing. It leverages blockchain technology to construct a full-process solution, achieving collaborative goals of data trustworthiness, clear rights, efficient sharing, and traceable control.

[0005] Technical solution:

[0006] A blockchain-based collaborative manufacturing method for multi-stakeholder data sharing and rights confirmation includes:

[0007] Step 1: Construct a consortium blockchain system including supplier nodes, overall unit nodes, and consensus nodes. Configure digital identity certificates based on the RSA algorithm for each node and set differentiated data access permission rules based on the RBAC model. The permissions of supplier nodes and overall unit nodes are mutually restricted.

[0008] Step 2: Supplier nodes and overall unit nodes collect heterogeneous data from the production and distribution process and the final assembly process, respectively, and record the collection timestamps synchronously. After standardization of the format, the data is encrypted using RSA with the recipient's public key to generate ciphertext, and the SHA-256 hash value of the ciphertext is calculated. The ciphertext, hash value, timestamp, and node digital signature are packaged and submitted to the consensus node. After verification by the PBFT consensus algorithm, the data is stored on the blockchain.

[0009] Step 3: Deploy a data rights confirmation smart contract on the consortium blockchain. The contract has a built-in four-dimensional rights quantification index system that includes data contribution, data value, data quality, and data usage frequency. When a node calls on-chain data, the smart contract is automatically triggered. The contract executes the following: permission verification, tracing the contributor based on the data hash value, matching the four-dimensional index according to the data attributes and calculating the rights value, and writing the rights record into the blockchain.

[0010] Step 4: The data requesting node submits a sharing request that includes the intended use. After the smart contract verifies the compliance of the permissions and the intended use, it obtains a one-time temporary decryption key. The authorized node queries the entire lifecycle information from data collection and on-chain to all sharing and rights records based on the data hash value.

[0011] Furthermore, in step 1, nodes interact using an encrypted communication protocol. The digital identity certificate includes node type, permission scope, key, and validity period, and automatically reminds the user to update before the expiration date. A two-level permission system is constructed based on the RBAC model. Supplier nodes can only access the overall unit's assembly progress and acceptance data, while overall unit nodes can only access the supplier's production parameters and delivery trajectory data. The permission rules are written into the blockchain through smart contracts.

[0012] Furthermore, in step 1, the sensitive data of the supplier node and the overall unit node are encrypted using zero-knowledge proof technology; wherein, the sensitive data of the supplier includes production process and raw material procurement channels, and the sensitive data of the overall unit includes final assembly plan and capacity planning.

[0013] Furthermore, step 1 also includes an abnormal node management mechanism: when a consensus node detects that a principal node has a series of consecutive data format errors / invalid signatures / hash mismatches, it marks it as an abnormal node and suspends its data submission permission until the submitted rectification report is jointly reviewed and approved by the consensus node and the supervisory node.

[0014] Furthermore, step 1 provides secure and reliable underlying support for the entire collaborative system, eliminating centralized risks and clarifying the interaction boundaries between the two entities through node architecture design and permission control.

[0015] Furthermore, in step 2, the standardization process includes: establishing a unified specification for manufacturing data based on XML format, clarifying the name, data type, unit, precision, and required fields of each field; removing invalid data with values ​​exceeding a reasonable range or with mismatched formats through a rule engine, and using a machine learning model to identify hidden abnormal data that deviates from historical data trends; and initiating completion requests for missing key data fields to ensure data format uniformity.

[0016] Furthermore, in step 2, the PBFT consensus algorithm verification is as follows: each supplier node and the overall unit node will package the encrypted ciphertext, unique hash value, collection timestamp, and node digital signature and send them to the consortium blockchain. The consensus node will use the PBFT algorithm to perform multiple rounds of verification. The verification content includes the consistency between the signature and the identity certificate, and the matching between the hash value and the data ciphertext. After the verification is passed, the data will be packaged into blocks. The blocks contain the block index, the hash value of the previous block, the data hash set of the current block, and the consensus timestamp, and are linked to the blockchain main chain to complete the notarization.

[0017] Step 2, on a trusted infrastructure, transforms the dispersed data of the two entities into “unified format, tamper-proof, and traceable” on-chain data through standardized processing and on-chain evidence storage, providing a real data source for subsequent equity calculations.

[0018] Furthermore, in step 3, the smart contract is written in Solidity language, and after being jointly reviewed and approved by the supplier node, the overall unit node and the regulatory node, it is uploaded to the consortium blockchain to complete the deployment, and the contract address, interface information and version number are made public to the blockchain ledger; smart contract upgrades require more than 2 / 3 of the entities to initiate an application and be approved by the consensus node, and the old version and upgrade records are retained for traceability.

[0019] Furthermore, in step 3, weights a, b, c, and d are assigned to the four-dimensional equity quantification index system. The formula for calculating the equity value is: Equity value = Contribution score × a + Value score × b + Quality score × c + Frequency of use score × d.

[0020] Furthermore, the criteria for evaluating data contribution include data completeness and data timeliness; the criteria for evaluating data value are: the weight of the data's impact on the core business decisions of suppliers and overall units in collaborative manufacturing is not less than a set threshold; the criteria for evaluating data quality is the accuracy error rate; the frequency of data use is accumulated based on the number of effective calls, and if a problem is found, the function is immediately suspended and repaired and updated according to the process.

[0021] Furthermore, in step 4, a maximum usage period is set, the temporary decryption key is encrypted during transmission and automatically expires; when the sharing request verification fails, the system returns a clear reason and uploads the request record to the blockchain for permanent storage; the full lifecycle information includes data collection nodes and time, standardized processing records, encryption and hash parameters, on-chain block information, all call records, equity calculation details and anomaly handling records.

[0022] Beneficial effects:

[0023] (1) The blockchain-based collaborative manufacturing multi-entity data sharing and rights confirmation method provided by the present invention makes rights clear and quantifiable: by setting up a rights indicator system through smart contracts, the automatic definition and quantification of the data contribution rights of suppliers and overall units are realized, which solves the problem of unclear ownership of rights between the two parties in the traditional model and ensures the fairness of the collaboration between the two parties.

[0024] (2) The blockchain-based collaborative manufacturing multi-entity data sharing and rights confirmation method provided by the present invention enables secure and controllable sharing: by combining permission level and zero-knowledge proof technology, data can be shared on demand and be available but not visible between suppliers and overall units, which not only meets the needs of production distribution and final assembly collaboration, but also protects the data privacy of both parties' core production technologies, final assembly processes and other data. Attached Figure Description

[0025] Figure 1 This is an overall flowchart of the present invention;

[0026] Figure 2 This is a block diagram of the consortium blockchain system architecture in this invention;

[0027] Figure 3 This is an interface for managing supplier menus, developed specifically for projects at the Second Academy of Aerospace Science and Technology.

[0028] Figure 4 This is an interface for managing the overall management unit menu, developed specifically for projects at the Second Academy of Aerospace Science and Technology.

[0029] Figure 5 This is a flowchart of the dual-subject data uplink process in this invention;

[0030] Figure 6 This is a flowchart of the smart contract rights confirmation process in this invention;

[0031] Figure 7 This is a flowchart illustrating the data authorization, sharing, and traceability process in this invention.

[0032] Figure 8 This is a flowchart of the exception handling process in this invention;

[0033] Figure 9 This is a flowchart of the overall collaborative closed-loop process in this invention. Detailed Implementation

[0034] The present invention will be further described in detail below with reference to specific embodiments. This embodiment takes an equipment manufacturing project as an example and is applicable to a collaborative manufacturing scenario involving two main entities: suppliers and overall units. The suppliers are responsible for the production and distribution of parts, while the overall units are responsible for the final assembly of the products.

[0035] The collaborative entities in the equipment manufacturing project include Supplier A (responsible for the production and distribution of core transmission components) and the overall unit B (responsible for equipment assembly), while also introducing a regulatory node C (the industry quality supervision agency). Addressing the issues of ambiguous data rights, susceptibility to tampering, insecure sharing, and difficulties in traceability in existing models, this invention employs a method to achieve data sharing and rights confirmation, such as... Figures 1-9 As shown, the specific implementation steps of the blockchain-based collaborative manufacturing multi-entity data sharing and rights confirmation method are as follows:

[0036] Step 1: Construction of the Dual-Subject Consortium Blockchain System: A consortium blockchain system consisting of dual-subject nodes and a consensus node is constructed. Each node is configured with an independent identity authentication module and an access control module, employing a dual mechanism that combines hierarchical access control and privacy protection to ensure secure interaction. The consensus node is jointly elected by a third-party authoritative institution and the dual subjects, and is responsible for blockchain consensus verification, ledger maintenance, and monitoring of abnormal nodes, thus resolving the trust barrier issue in dual-subject data interaction.

[0037] Specifically,

[0038] Step 1.1, Node Architecture Setup: Construct a consortium blockchain system consisting of dual-entity nodes (supplier nodes and overall unit nodes), consensus nodes, and regulatory nodes. Supplier nodes integrate production data collection interfaces and delivery information upload modules; overall unit nodes are configured with final assembly requirement release and acceptance data entry functions; consensus nodes are jointly selected by a third-party authoritative institution (such as an industry association) and the two entities; and regulatory nodes are responsible for full-process compliance auditing. The four types of nodes interact with each other through an encrypted communication protocol.

[0039] Step 1.2, Identity and Permission Solidification: A unique digital identity certificate is generated for each node using the RSA asymmetric encryption algorithm. The certificate includes the node type, business permission scope, key information, and a 12-month validity period. The system automatically reminds the node to update 30 days before the expiration date. A two-tier permission system is constructed based on the RBAC model: Supplier nodes can only access the overall unit's assembly progress, component acceptance results, and corresponding requirement data, but cannot obtain assembly process parameters or core equipment operation data. The overall unit can only query the supplier's component production parameters, real-time production progress, and delivery trajectory data, but cannot access the supplier's production process and cost accounting data. These permission rules are written into the blockchain via smart contracts and cannot be modified without authorization.

[0040] Step 1.3, Privacy Protection Mechanism Embedded: Zero-knowledge proof technology is used to encrypt sensitive data of dual subjects (supplier production process, raw material procurement channels; overall unit assembly plan, capacity planning) to achieve data "usable but not visible" - authorized nodes can only obtain the data use value and cannot parse the original sensitive information, thus eliminating the risk of data privacy leakage from the bottom layer.

[0041] Step 1.4, Abnormal Node Management: The consensus node monitors the data submission behavior of each main node in real time. When a node is detected to have three consecutive abnormalities such as data format errors, invalid signatures, or hash value mismatches, it is immediately marked as an "abnormal node" and its data submission privileges are suspended. Simultaneously, a warning is sent to the supervisory node and the corresponding main node. Abnormal nodes must submit a rectification report and supporting documentation. Privileges can only be restored after joint review and approval by the consensus node and supervisory node, ensuring the compliance of blockchain network node behavior.

[0042] A consortium blockchain system is a decentralized distributed ledger collaboration network where ledger data is jointly maintained by pre-selected consortium members (in this example, suppliers, overall units, and third-party authoritative institutions). All member nodes enjoy equal consensus participation rights (or permissions are assigned according to preset rules). Data is only visible to authorized nodes within the consortium; external nodes cannot access or obtain the data. Its core objective is to establish a trusted data interaction channel among multiple entities that do not require complete trust. Through distributed storage, immutability, and consensus verification, it replaces traditional centralized intermediaries to achieve efficient and secure collaboration. Combined with the needs of collaborative manufacturing scenarios, such as... Figure 2 As shown: In this embodiment, the consortium blockchain mainnet adopts a multi-node collaborative architecture. Each component has clearly defined functions and responsibilities. The architecture mainly includes three types of nodes: A) supplier nodes, B) overall unit nodes, and C) regulatory nodes (consensus nodes) and other consensus nodes. A and B are dual-main-entity nodes, and C is one of the consensus nodes. Each node has a clear division of labor and complementary functions.

[0043] Supplier Node A: Its core functions are collecting and uploading production / delivery data, as well as querying data within its authorized scope. It represents the supplier entity in the supply chain and is responsible for uploading data from the production and logistics processes to the blockchain.

[0044] B. Overall Unit Node: Its function is to collect and upload assembly data and query data within authorized limits. It represents the integrator of the final product or system and is responsible for uploading data from assembly, testing, and other stages to the blockchain.

[0045] C-level Supervisory Node - Consensus Node: This is a special node that combines both supervisory and consensus functions. Its C-level node functions include full data supervision, abnormal node monitoring, and participation in PBFT consensus. As the supervisor, it has higher-level data access permissions and is responsible for overseeing the compliance and stability of the entire network.

[0046] In the mainnet, besides the regulatory nodes, there are several other consensus nodes that participate in the consensus verification / ledger maintenance process, forming a distributed consensus network. All transactions and data that have passed consensus verification are recorded on the blockchain, thus realizing the core capabilities of blockchain: distributed storage, immutability, and smart contract deployment. Smart contracts are deployed on this mainnet to automatically execute data rights confirmation and sharing rules.

[0047] like Figure 3 As shown in Figure 4, the platform interface is controlled through a super administrator. RSA digital certificates are assigned to each node, and permission rules are set: A can access B's transmission component assembly progress and assembly compatibility testing data; B can access A's transmission component material parameters, production progress, and delivery trajectory data; C can access all data for quality supervision.

[0048] Step 2, Dual-Subject Data Standardization and On-Chain Processing: Suppliers and the overall unit collect data from the entire production, distribution, and final assembly process using edge computing devices. First, they complete the standardization process according to unified specifications to obtain standardized data. Then, they use the other party's node public key to encrypt the standardized data using RSA to generate encrypted ciphertext. Simultaneously, they calculate the unique hash value of the encrypted ciphertext using the SHA-256 algorithm. The collection timestamp is recorded synchronously when collecting the original data. Finally, they use their own private key to sign the combined data, including the encrypted ciphertext, unique hash value, and collection timestamp, to generate a node digital signature. The encrypted ciphertext, unique hash value, collection timestamp, and node digital signature are packaged and uploaded to the consortium blockchain. Consensus nodes use the PBFT algorithm to verify the data validity. After successful verification, the data is uploaded to the blockchain for notarization, solving the problems of chaotic manufacturing data formats and susceptibility to tampering.

[0049] Specifically,

[0050] Step 2.1, Precise Data Collection Across the Entire Chain: Both parties collect collaborative data in real time through edge computing devices (supplier workshop IoT terminals, overall unit assembly line data collectors), covering the entire chain of production, distribution, and final assembly, including:

[0051] Supplier side: Component production parameters (material composition, specifications, dimensions, hardness and other performance indicators), production progress data (process completion rate, equipment utilization rate, quality inspection results and defect analysis reports), and delivery data (transportation vehicle information, real-time location, temperature and humidity during transit, and estimated delivery time).

[0052] Overall unit side: final assembly requirements data (parts model, quantity, delivery time nodes), final assembly progress data (parts input ratio, process completion status, equipment operating parameters), and quality acceptance data (parts pass rate, assembly compatibility results, and non-conforming product handling records).

[0053] The data collection frequency is dynamically adjusted based on the importance of the data. Core production / final assembly data is collected every 10 seconds, while general logistics / demand data is collected every minute to ensure data real-time performance.

[0054] Step 2.2, Data Standardization Processing: A unified specification for manufacturing data is established based on XML format, clearly defining the field names, data types, units, precision, and required fields (e.g., component parameters must include a "material-specification-performance" three-part field). Data is then processed using a hybrid cleaning strategy combining rule-based filtering and machine learning.

[0055] The hybrid data cleaning strategy is as follows: the rule engine removes invalid data with values ​​exceeding reasonable ranges or mismatched formats; the machine learning model, trained on historical data, identifies and issues warnings for hidden anomalies that deviate significantly from the general trend, and decides whether to retain them after manual review. For missing key fields (such as "performance indicators" for components), the system automatically sends a completion request to the data acquisition node. If no response is received within 30 minutes, the data is marked as "partially complete" and the missing field is noted, ensuring consistent data format and controllable quality.

[0056] Step 2.3, Encryption and Hash Solidification: Based on the standardized data obtained in Step 2.2, the standardized data is encrypted using RSA with the public key of the other node to generate ciphertext. The private key is stored by each node in a hardware encryption module and is automatically updated every 90 days to prevent the risk of private key leakage. The hash value of the ciphertext is calculated using the SHA-256 algorithm. This hash value is used as the unique "digital fingerprint" of the data, corresponding one-to-one with the data content. Any minor modification will cause a significant change in the hash value, providing a basis for subsequent integrity verification.

[0057] Step 2.4, Consensus On-Chain Notification: Each principal node packages the encrypted ciphertext, unique hash value, collection timestamp, and node digital signature and sends it to the consortium blockchain. The consensus nodes use the PBFT algorithm for multiple rounds of verification, verifying the consistency between the signature and the identity certificate, and the matching between the hash value and the encrypted data. After verification is passed (more than 2 / 3 of the consensus nodes confirm its validity), the data is packaged into a block. The block contains the block index, the hash value of the previous block, the hash set of the data in this block, and the consensus timestamp, and is linked to the main blockchain to complete the notification, realizing that the data "cannot be tampered with once it is on the chain".

[0058] The complete process of data uploading to the blockchain is as follows: Figure 5As shown, firstly, in the data processing and encapsulation phase, the two main nodes work independently, following the same technical path. Supplier A node collects specific production data for its transmission components, including material (e.g., high-strength alloy steel), hardness (HB280), and current production progress (80% complete). Simultaneously, the overall unit B node collects corresponding demand data for its final assembly stage, including the required quantity (100 sets) and delivery time requirement (before October 10, 2025). Both parties standardize the collected heterogeneous data using XML format to ensure data structure uniformity. Subsequently, each party uses its own RSA private key to encrypt the standardized data, generating corresponding ciphertext and calculating its SHA-256 hash value (e.g., the hash value generated by Supplier A is "0x123..."). Finally, each party appends a precise timestamp (e.g., "2025-10-01 08:30:00") and a digital signature to the data packet, completing the full encapsulation before data submission. Secondly, in the submission and consensus verification phase, the encapsulated data is submitted to the consortium blockchain network. The submission is received by a consensus node group, including the C oversight node. All consensus nodes initiate the PBFT algorithm to collaboratively verify the validity of the submitted data, including the authenticity of the digital signature, the matching of hash values, and the logical consistency of the timestamp. Finally, in the result processing and notarization phase, the system executes different branch processes based on the consensus verification result. If the verification result is successful, all nodes unanimously agree to package the data into a block (in this embodiment, the block index number is 1001) and connect the new blockchain to the main chain, completing the final on-chain notarization. If the verification result is unsuccessful, the system will return the reason for the exception and record the complete information of the exception in the log for subsequent auditing and troubleshooting.

[0059] Step 3, Smart Contract Deployment and Rights Confirmation: Deploy a data rights confirmation smart contract on the consortium blockchain. The contract has a built-in rights quantification indicator system, calculation rules and triggering mechanism for both parties. When either party calls the shared data, the contract will automatically trigger and complete the data source tracing, the contribution party's rights quantification and the rights information recording on the chain, solving the problem of data rights definition having no basis and being difficult to quantify.

[0060] Specifically,

[0061] Step 3.1, Smart Contract Rule Customization: A data rights confirmation smart contract is written using the Solidity language, with a built-in four-dimensional quantitative indicator system, weighted calculation rules, and multi-scenario triggering mechanism. The rule content is written into the contract after being jointly negotiated and confirmed by both parties. The four-dimensional indicators include: data contribution (30%, including completeness ≥95% and timeliness ≤2 hours), data value (40%, core decision data weight ≥0.6), data quality (20%, accuracy error rate ≤1%), and data usage frequency (10%, accumulated based on the number of effective calls). Completeness ≥ 95% means that the completeness rate of the preset mandatory key fields in the submitted data is no less than 95%; Timeliness ≤ 2 hours means that the time interval from data generation (such as the completion of part production or the end of the final assembly process) to uploading to the consortium blockchain does not exceed 2 hours; Core decision data weight ≥ 0.6 means that the system will preset decision influence weights for different types of data (0-1 points, 1 point is the greatest influence), and the weight of core decision data is set to no less than 0.6 (that is, the system will preset decision influence weights for different types of data. When the decision influence weight is ≥ 0.6, it is core data with a high value score, and when the decision influence weight is < 0.6, it is auxiliary data with a low value score); Accuracy error rate ≤ 1% means that the deviation ratio between the recorded value and the actual value of index-based data does not exceed 1%. For non-numerical data such as "delivery status", it is necessary to ensure that the record is consistent with the actual value and without error.

[0062] The scoring criteria are as follows: for contribution, "completeness 95%-100% earns 90-100 points, 90%-95% earns 70-89 points"; for value, "core data earns 90-100 points, auxiliary data earns 70-89 points." These specific criteria are deeply tied to the dual-entity business scenario. Triggering mechanisms include three scenarios: immediate data access triggering, monthly end-of-month periodic summary triggering, and data dispute tracing triggering.

[0063] Step 3.2, Contract Review and Deployment: Submit the contract code to the dual-entity node and the regulatory node for joint review, focusing on verifying the fairness of the rights and interests rules and the absence of loopholes in the code logic. After the review is passed, upload it to the consortium blockchain to complete the deployment. The contract address, interface information and version number are made public to the blockchain ledger for all nodes to query and call, ensuring that the contract is transparent and supervised.

[0064] Step 3.3, Automatic Calculation and Recording of Rights: When a supplier or overall unit calls on-chain shared data, the system automatically triggers the smart contract and executes four steps: verification, tracing, calculation, and recording. ① Verify whether the calling node's permissions comply with the contract's preset RBAC rules to prevent unauthorized calls; ② Trace the data's on-chain record through the data's unique hash value to accurately locate the data contributor (supplier or overall unit); ③ Match four-dimensional indicators based on data attributes, automatically determine the score of each indicator, and calculate the rights value according to "Rights Value = Contribution × 30% + Value × 40% + Quality × 20% + Usage Frequency × 10%"; ④ Write the contributor identifier, caller identifier, data hash value, scores of each indicator, rights value, trigger type, timestamp, and other information into the blockchain to form an immutable rights ledger, providing a reliable basis for subsequent rights realization. The four-dimensional rights quantification indicator system and its automatic triggering calculation mechanism disclosed in this embodiment realize a qualitative change from data sharing to rights confirmation, which is different from existing blockchain solutions that only focus on data storage or simple sharing.

[0065] The process of confirming rights and interests is as follows Figure 6 As shown, unit B calls the transmission component production parameter data of unit A to formulate the final assembly process plan, triggering the execution of the smart contract. Step 1: The contract verifies the legality of node B's permissions. If the verification is successful, the process continues; if the permissions are invalid, the smart contract will reject the call request and record it accordingly. Step 2: The data contributor is traced back to A through hash value. The smart contract uses the unique hash identifier of the target data stored on the blockchain to query its historical records, accurately trace and determine that its original contributor is node A. Step 3: Quantitative index scoring. The smart contract scores the called data in multiple dimensions based on a preset equity quantification model. In this embodiment, the data contribution score is determined to be 92 (data is complete and updated in a timely manner), the data value score is 90 (directly determines the final assembly process parameter design), and the usage frequency is 1. Step 4: The equity value is calculated according to the formula = 92 × 30% + 90 × 50% + 1 × 20% = 87.8; "Contributor A, Caller B, Equity Value 87.8, Timestamp 2025-10-01 09:15:00" is written into the blockchain. When supplier A accesses supplier B's final assembly requirements data, the smart contract similarly confirms and records supplier B's rights and interests.

[0066] Step 4, Data Sharing and Traceability: The two main nodes submit data sharing requests through the blockchain system. After verification by the smart contract in terms of identity, permissions, and purpose, they obtain data access permissions and decryption keys. At the same time, they can query the entire lifecycle information based on the unique identifier of the data, realizing secure data sharing and full traceability, and solving the problems of imbalance between sharing efficiency and privacy protection, and difficulty in tracing responsibility for problems.

[0067] Specifically,

[0068] Step 4.1, Tiered Authorization Data Sharing: When a primary node needs to access data, it submits a sharing request containing the node identifier, target data hash value, intended use (e.g., "adjust delivery plan," "formulate final assembly schedule"), usage period (maximum 30 days), and confidentiality commitment. The smart contract verifies the data from three dimensions: ① Identity legitimacy: verifying the consistency between the requesting node's digital signature and its on-chain identity certificate; ② Permission matching: ensuring the target data's access permission identifier matches the requesting node's permission scope; ③ Usage compliance: ensuring the usage falls within the pre-defined compliance list of "production collaboration, quality traceability, and schedule matching." Upon successful verification, the system generates a one-time temporary decryption key bound to the usage period and sends it to the requesting node via an encrypted channel. The key automatically expires. If verification fails, a clear reason such as "invalid identity / insufficient permissions / non-compliant usage" is returned, and the request record is uploaded to the blockchain to ensure the sharing process is controllable.

[0069] Step 4.2, Full Lifecycle Data Traceability: Any authorized node can query the entire data process information through a combination of multiple conditions such as "data hash value / node identifier / time range". The traceability content covers the entire process of collection, processing, on-chain, sharing, and rights, including: data collection node and time, standardized processing records (cleaning / completion status), encryption and hash parameters, on-chain block information (index, previous block hash), all call records (caller, time, purpose), rights calculation details, and anomaly handling records.

[0070] Step 4.3, Anomaly Tracing and Accountability: When the hash value of the queried data is found to be inconsistent with the hash value stored on the chain during the tracing process, the system immediately triggers an anomaly alarm, synchronizes it to the supervisory node and the dual-principal nodes, and automatically locks the disputed data and the operation logs of the relevant nodes (including data submission, call, and modification records). The consensus node verifies the tampering node by combining the logs and on-chain records, and the supervisory node handles the matter according to the contract rules to ensure that data issues are traceable, responsibilities are clear, and a collaborative closed loop is completed.

[0071] Data traceability and sharing, such as Figure 7 As shown, the process begins with supplier A initiating a sharing request. This request is a structured data packet, and its content includes at least: supplier A's own node identifier, the hash of the final assembly progress data to be queried, and the specific purpose of this query (in this embodiment, supplier A queries supplier B's final assembly progress data to confirm subsequent delivery arrangements). After the request is submitted, it enters the smart contract verification stage. The smart contract automatically verifies the compliance of this request from multiple verification dimensions according to preset rules. Figure 7All verification dimensions in the system focus on identity legitimacy, specifically verifying whether the requester's digital signature matches the certificate registered on the blockchain. This repetition emphasizes the system's use of multiple security verification mechanisms to ensure the authenticity of the requester's identity. If verification fails, the process terminates and the request is rejected; if all verification dimensions pass, encrypted data and the decryption key are returned. The system decrypts the overall assembly progress data of unit B and authorizes supplier A with the decrypted data along with a one-time decryption key, enabling A to access the decrypted assembly progress data. After obtaining the necessary information, supplier A can arrange subsequent logistics activities accordingly. Supervisory node C queries the entire data flow of the transmission component using the data hash value "0x123...", clearly obtaining A's production acquisition information, on-chain time, B's call records, and the rights and interests of both parties, ensuring transparent and traceable production-assembly data flow.

[0072] like Figure 8 As shown in the flowchart, the anomaly handling process is a core security element of the blockchain collaborative manufacturing data sharing system. The process begins with the system monitoring data flow in real time, continuously monitoring all on-chain and shared data activities. Monitoring relies on SHA-256 hash value verification to check data integrity. If the detection result is consistent, the data flows normally; if the detection result is inconsistent (suspected tampering), the system refuses to access the data and records the error, including the consensus nodes at the data level refusing to write data, fundamentally preventing potentially tampered data from entering the blockchain. The system then synchronizes the anomaly information to nodes A / B / C, ensuring that all nodes, including supplier node A, overall unit node B, and supervisory node C, are simultaneously aware of the anomaly and lock the disputed data and operation logs, preserving original evidence for subsequent audits. Supervisory node C leads the verification process. If a node is confirmed to have tampered, its permissions are immediately suspended, access is refused, and the node applies for restoration after rectification, then re-verification is performed. If no tampering is found, the data verification parameters are corrected. The anomaly handling system operates on a closed-loop logic of real-time monitoring, anomaly identification, rapid response, and accountability. Relying on hash value verification and monitoring, it locks disputed data and operation logs, and the consensus group verifies and holds individuals accountable. This enables rapid blocking of abnormal data and clarification of responsibility. Its design relies on the PBFT consensus algorithm and the immutability of blockchain, which not only connects the data on-chain process to form full-cycle protection, but also ensures the trustworthiness of collaborative data by clarifying the responsibilities of nodes. It can effectively prevent problems such as production data tampering and misoperation, and maintain collaborative order.

[0073] like Figure 9The table shown illustrates the breakdown of the entire process and the completion score of key tasks for an example of this invention. It displays the four core stages from system construction to collaborative optimization, the key tasks of each stage, and the completion status of each task. The implementation of the technical solution is divided into four progressive stages: system construction, data interaction, shared traceability, and collaborative optimization. Each stage proceeds sequentially and completes its corresponding core tasks. The system construction stage is the foundational preparation for the implementation of the solution, requiring the completion of consortium blockchain construction, permission rule configuration, and smart contract deployment: a consortium blockchain system consisting of a supplier (A), an overall unit (B), and consensus / supervisory nodes (C) is built, and node deployment is completed (score 5); a two-level permission system is configured based on the RBAC model to achieve permission isolation between the supplier and the overall unit, and the permission rules take effect (score 4); at the same time, a smart contract for equity calculation is deployed, and its built-in equity rules pass the review (score 5). After entering the data interaction phase, the core data flow and rights mechanism are activated: the supplier processes the production data of the transmission components and stores it on the blockchain (score 5), and the overall unit processes the final assembly requirement data and stores it on the blockchain (score 5); when the overall unit calls the supplier's on-chain data, the smart contract automatically triggers the rights calculation (score 4), and at the same time confirms that the rights rules of the smart contract have been approved (score 5). The shared traceability phase focuses on data value and security, realizing data sharing, supervision and anomaly prevention: the supplier can query the overall unit's final assembly progress data (score 4), the regulatory node conducts compliance verification of the entire process data on the blockchain (score 5), and the system detects that the on-chain data has not been tampered with, and the data security meets the standards (score 5). Finally, the collaborative optimization phase is entered, realizing business value through data collaboration: the supplier adjusts its own delivery plan based on the obtained final assembly progress data (score 4), and the overall unit optimizes the final assembly schedule based on the supplier's component production progress (score 4). The numbers following each task represent the degree of task completion or the level of achievement of the target. 5 points is the maximum score, and 4 points represents a high degree of completion with some room for optimization. Overall, the solution of this invention has a good implementation effect in each stage, and the core tasks have reached or are close to the maximum score standard.

[0074] It should be noted that this application is not a simple application of blockchain, but rather the construction of a fully automated, closed-loop system for data rights confirmation and secure sharing in a collaborative manufacturing scenario involving suppliers and final assembly units. This application addresses four core technical issues in the collaborative scenario of supplier production and distribution with final assembly unit assembly:

[0075] Firstly, there is the lack of a reliable data interaction mechanism. In traditional centralized architectures, the production and assembly data of suppliers and overall units are stored in independent systems. Data transmission is easily tampered with and lacks cross-verification methods, leading to a trust gap between the two parties regarding data authenticity and affecting the accuracy of collaborative decision-making. Step 1 of this application constructs a consortium blockchain system including dual subjects, consensus, and supervisory nodes. It adopts dual protection of permission hierarchical (RBAC model) and zero-knowledge proof, combined with RSA encryption and SHA-256 hash solidification technology, to achieve distributed data storage and immutability. This achieves refined management of data that is "usable but not visible" in an untrusted environment, satisfying collaborative needs while protecting core data privacy. Furthermore, through multiple rounds of verification using the PBFT algorithm of the consensus nodes, a cross-verification mechanism has been technically established.

[0076] Secondly, there is the issue of quantifying and defining data rights. The existing model lacks a data value assessment system. The interaction between supplier component production parameters and delivery dynamics data and overall unit assembly requirements and acceptance standards data leads to blurred contribution boundaries, making it impossible to scientifically quantify the rights of both parties and causing disputes. Step 3 of this application deploys a smart contract written in Solidity to construct a four-dimensional quantification system (contribution, value, quality, and usage frequency) and weighted calculation rules. This transforms abstract data rights into an automatically calculable four-dimensional indicator system, which is then automatically executed through the smart contract. When data is accessed, the source is automatically traced, rights are calculated, and recorded on the blockchain, providing a clear basis for rights ownership and resolving the problem of lacking a legal basis for rights definition.

[0077] Thirdly, there is the issue of standardization and efficient sharing of heterogeneous data. Inconsistent data formats and collection dimensions between the two parties necessitate significant manual intervention for data integration. Furthermore, conflicts exist between the privacy protection and collaborative needs of core technical data, making it difficult to balance sharing efficiency and data security. Step 2 of this application establishes a unified data specification based on XML. Through a combination of rule filtering and machine learning, heterogeneous data cleaning and format conversion are completed. Simultaneously, zero-knowledge proofs are used to encrypt sensitive data, and smart contracts provide three-dimensional verification and authorization to generate temporary decryption keys, achieving efficient and secure sharing that is "usable but not visible."

[0078] Fourth, the issue of full-process data traceability and accountability—the entire lifecycle of data, from collection and transmission to use, lacks a traceable link. When problems arise such as substandard component quality or delays in final assembly, it is impossible to quickly identify the responsible party, resulting in low traceability efficiency. This invention addresses the above-mentioned technical problems by building a full-process solution based on blockchain technology, achieving the collaborative goals of "trustworthy data, clear rights and interests, efficient sharing, and controllable traceability." Step 2 of this application uploads key information such as unique data hash values, collection timestamps, and node signatures to the blockchain, supporting multi-condition combined queries and covering all stages including collection, processing, uploading to the blockchain, sharing, and rights and interests. In abnormal situations, disputed data and operation logs can be locked, enabling rapid identification of responsibility.

[0079] Finally, it is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present invention, and the present invention is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the principles and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A blockchain-based method for multi-entity data sharing and rights confirmation in collaborative manufacturing, characterized in that: include: Step 1: Construct a consortium blockchain system including supplier nodes, overall unit nodes, and consensus nodes. Configure digital identity certificates based on the RSA algorithm for each node and set differentiated data access permission rules based on the RBAC model. The permissions of supplier nodes and overall unit nodes are mutually restricted. Step 2: Supplier nodes and overall unit nodes collect heterogeneous data from the production and distribution process and the final assembly process, respectively, and record the collection timestamps synchronously. After standardization of the format, the data is encrypted using RSA with the recipient's public key to generate ciphertext, and the SHA-256 hash value of the ciphertext is calculated. The ciphertext, hash value, timestamp, and node digital signature are packaged and submitted to the consensus node. After verification by the PBFT consensus algorithm, the data is stored on the blockchain. Step 3: Deploy a data rights confirmation smart contract on the consortium blockchain. The contract has a built-in four-dimensional rights quantification index system that includes data contribution, data value, data quality, and data usage frequency. When a node calls on-chain data, the smart contract is automatically triggered. The contract executes the following: permission verification, tracing the contributor based on the data hash value, matching the four-dimensional rights quantification index according to the data attributes and calculating the rights value, and writing the rights record into the blockchain. Step 4: The data requesting node submits a sharing request that includes the intended use. After the smart contract verifies the compliance of the permissions and the intended use, it obtains a one-time temporary decryption key. The authorized node queries the entire lifecycle information from data collection and on-chain to all sharing and rights records based on the data hash value.

2. The method according to claim 1, characterized in that, In step 1, nodes interact using an encrypted communication protocol. The digital identity certificate includes node type, permission scope, key, and validity period, and automatically reminds the user to update before the expiration date. A two-tier permission system is constructed based on the RBAC model. Supplier nodes can only access the overall unit's assembly progress and acceptance data, while overall unit nodes can only access the supplier's production parameters and delivery trajectory data. The permission rules are written into the blockchain through smart contracts.

3. The method according to claim 1, characterized in that, In step 1, the sensitive data of the supplier node and the overall unit node are encrypted using zero-knowledge proof technology; the sensitive data of the supplier includes production process and raw material procurement channels, and the sensitive data of the overall unit includes final assembly plan and capacity planning.

4. The method according to claim 1, characterized in that, Step 1 also includes an abnormal node management mechanism: when a consensus node detects that a principal node has a series of consecutive data format errors / invalid signatures / hash mismatches, it marks it as an abnormal node and suspends its data submission permission until the submitted rectification report is jointly reviewed and approved by the consensus node and the supervisory node.

5. The method according to claim 1, characterized in that, In step 2, the standardization process includes: establishing a unified specification for manufacturing data based on XML format, specifying the name, data type, unit, precision, and required fields for each field; using a rule engine to remove invalid data whose values ​​exceed a reasonable range or whose formats do not match, and using a machine learning model to identify hidden abnormal data that deviates from historical data trends; and initiating completion requests for missing key data fields to ensure data format uniformity.

6. The method according to claim 1, characterized in that, In step 2, the PBFT consensus algorithm verification is as follows: Each supplier node and the overall unit node will package the encrypted ciphertext, unique hash value, collection timestamp, and node digital signature and send them to the consortium blockchain. The consensus node will use the PBFT algorithm to perform multiple rounds of verification. The verification content includes the consistency between the signature and the identity certificate, and the matching between the hash value and the data ciphertext. After the verification is passed, the data will be packaged into blocks. The blocks contain the block index, the hash value of the previous block, the data hash set of the current block, and the consensus timestamp, and are linked to the blockchain main chain to complete the notarization.

7. The method according to claim 1, characterized in that, In step 3, the smart contract is written in Solidity language. After being jointly reviewed and approved by the supplier node, the overall unit node and the regulatory node, it is uploaded to the consortium blockchain to complete the deployment. The contract address, interface information and version number are made public to the blockchain ledger. The upgrade of the smart contract requires more than 2 / 3 of the subjects to initiate an application and be approved by the consensus node. The old version and upgrade records are retained for traceability.

8. The method according to any one of claims 1-7, characterized in that, In step 3, weights a, b, c, and d are assigned to the four-dimensional equity quantification index system. The formula for calculating the equity value is: Equity value = Contribution score × a + Value score × b + Quality score × c + Frequency of use score × d.

9. The method according to claim 8, characterized in that, The criteria for evaluating data contribution include data completeness and data timeliness; the criteria for evaluating data value are: the weight of the data's impact on the core business decisions of suppliers and overall units in collaborative manufacturing is not less than a set threshold; the criteria for evaluating data quality are accuracy error rate; the frequency of data use is accumulated based on the number of effective calls, and if a problem is found, the function will be immediately suspended and repaired and updated.

10. The method according to claim 1, characterized in that, In step 4, a maximum usage period is set, the temporary decryption key is encrypted during transmission and automatically expires; when the sharing request verification fails, the system returns a clear reason and uploads the request record to the blockchain for permanent storage; the full lifecycle information includes data collection nodes and time, standardized processing records, encryption and hash parameters, on-chain block information, all call records, equity calculation details and anomaly handling records.

Images