Contract data sharing method based on alliance chain and local differential privacy

Abstract

The invention discloses a contract data sharing method based on an alliance chain and local differential privacy. The contract data sharing method comprises five entities and five task execution stages. The five entities are respectively an enterprise data provider, a Group 1 contract data recording chain, a Group 2 task management chain, an under-chain cross-group scheduler CGO and an under-chain computing node; the five task execution stages are respectively a contract data uplink stage, a task triggering and cross-group scheduling stage, an under-chain calculation node execution statistics stage, an under-chain credible aggregation stage, and an uplink and incentive distribution stage. According to the method, a multi-dimensional random response (MDRR) mechanism is designed, and the internal attribute relevance of data records is reserved while privacy is protected; a hybrid computing mechanism of alliance chain and differential privacy fusion is constructed, and on-chain scheduling and off-chain efficient computing are realized, so that the computing overhead is reduced; a data aggregation mechanism TUSO based on trust-utility collaborative optimization is provided, and the reliability and effectiveness of data sharing are improved by integrating trust score and data utility optimization.

Description

Technical Field

[0001] This invention relates to the intersection of data security and blockchain technology, and in particular to a method for sharing contract data based on consortium blockchains and local differential privacy. Background Technology

[0002] In cross-border trade and supply chain services, enterprises need to conduct key business operations such as credit assessment, risk management, and supply chain collaboration, which requires the interoperability of contract data. This leads to contract data sharing. However, contract data, as a core asset of enterprises, carries critical information such as transaction amounts, performance records, and transaction terms. Relying on third-party platforms as data transfer and management carriers is prone to risks such as data tampering and misuse, leading to the leakage of core enterprise privacy information.

[0003] Blockchain technology is well-suited to the "trusted but not fully transparent" collaborative environment between enterprises, making it a preferred technology for contract data sharing. Meanwhile, Local Differential Privacy (LDP) mechanisms can achieve privacy protection at the data source without relying on trusted third parties. Combining LDP with blockchain makes on-chain data statistically usable but unidentifiable at the individual level, providing a feasible path to balance privacy protection and data availability.

[0004] However, existing technologies cannot simultaneously solve the three core problems of high computing costs, insufficient effectiveness, and lack of decentralized trust in the scenario of combining blockchain and LDP, making it difficult to meet the comprehensive needs of enterprise-level contract data sharing for privacy and security, data availability, efficiency, and reliability. Summary of the Invention

[0005] This invention proposes a contract data sharing method based on consortium blockchain and local differential privacy. By constructing a smart contract data aggregation mechanism based on trust-utility collaborative optimization, it comprehensively considers the historical trust score of computing nodes and the current result utility. The smart contract automatically completes the evaluation and aggregation of computing results, aiming to improve the reliability and effectiveness of data sharing.

[0006] This invention proposes a contract data sharing method based on consortium blockchain and local differential privacy, comprising 5 entities and 5 task execution stages; the 5 entities are: enterprise data provider, Group 1 contract data recording chain, Group 2 task management chain, off-chain cross-group scheduler CGO, and off-chain computing nodes; the 5 task execution stages are: contract data on-chain stage, task triggering and cross-group scheduling, off-chain computing node execution statistics, off-chain trusted aggregation, and on-chain and incentive allocation; The enterprise data provider is a basic participant in the system, holding local contract data. It performs local differential privacy perturbation on the contract data through the Multidimensional Random Response (MDRR) mechanism and only uploads the perturbated, noisy data to the blockchain. Group 1 Contract Data Recording Chain: Responsible for on-chain data storage, used to record LDP contract data submitted by enterprises; Group 2 Task Management Chain: Deploys task management smart contracts for issuing statistical tasks and distributing rewards; Off-chain cross-group scheduler (CGO): Responsible for cross-group data scheduling, it is the key off-chain coordination entity connecting Group 1 and Group 2; Off-chain computing nodes: As task executors, they subscribe to task publication events in Group 2, obtain public LDP contract data within a specified range from Group 1, and complete statistical calculations using a multidimensional joint distribution estimation algorithm of their own choice; During the contract data on-chain stage: the enterprise data provider applies the MDRR mechanism to the local contract data to generate noisy LDP data and submits it to Group 1. As the on-chain data accumulates, the block height of Group 1 gradually increases, forming a contract data record structure arranged in chronological order. The CGO listens to the block height of Group 1 through the Python SDK as a trigger condition for task initiation.

[0007] Task triggering and cross-group scheduling phase: When the block height of Group 1 reaches the preset threshold N of a certain round of statistical tasks, the CGO initiates the publishTask() call to the Group 2 smart contract to create a new task and write the task parameters. Group 2 generates the TaskPublished event, and all off-chain computing nodes automatically receive the task publishing information through the event subscription mechanism. Off-chain computing nodes perform the statistical phase: The computing nodes access the publicly available LDP data of Group 1 according to the data range specified in the task, complete the multidimensional joint distribution estimation, and each node independently executes the task and submits the calculation results and signature to the CGO; Off-chain trusted aggregation phase: The CGO collects all computation results and uses the TUSO mechanism, a data aggregation mechanism based on trust-utility collaborative optimization, to perform multi-dimensional evaluation of the accuracy and stability of the node results, thereby generating the final trusted aggregation result; in addition, the CGO constructs a Merkle Tree for the original results submitted by all nodes and uses its root hash as an on-chain commitment to the result set; each node The submitted local calculation results are denoted as These results are used as leaf nodes of the Merkle Tree. Adjacent leaf nodes are concatenated pairwise and hashed to generate intermediate nodes for the next level. If the number of nodes is odd, padding is performed by either copying the last node or hashing it separately to ensure the integrity of the tree structure. This process is repeated recursively from bottom to top until a unique Merkle Root is generated. .

[0008] On-chain and incentive distribution phase: The CGO writes the final aggregated calculation result and its corresponding Merkle Root into the Group 1 blockchain. In subsequent dispute resolution or auditing phases, any node can provide its corresponding result. The Merkle Proof from the leaf node to the root node is used to verify whether the result is indeed included in the aggregation result set. Finally, the CGO calls the incentive distribution function in the Group 2 smart contract based on the node trust score and utility value calculated by the TUSO data aggregation mechanism based on trust-utility collaborative optimization. The incentive distribution to the off-chain computing nodes is automatically completed according to the preset reward rules to promote the continuous provision of high-quality computing services by the nodes.

[0009] Preferably, the Multidimensional Random Response (MDRR) mechanism consists of the following four working steps: A-1 constructs the perturbation matrix: assigns a probability to each attribute of the data to retain the true value and replace it with other values, forming the corresponding perturbation matrix; A-2 Local Data Perturbation: Users randomly adjust each attribute of each of their own data entries according to the corresponding perturbation matrix before submitting; A-3 Statistical Perturbation Data: Collect all perturbed data and calculate the frequency of occurrence of each attribute combination. A-4 restores the true distribution: iteratively corrects the data along the attribute dimensions and restores the true distribution of the data through matrix inverse operations.

[0010] Preferably, the data aggregation mechanism TUSO based on trust-utility collaborative optimization consists of the following four working steps: B-1 Initial Weighted Aggregation: Weights are assigned to each node based on its historical trust score, and the initial aggregation result is calculated using weighted averages. B-2 Dynamically Adjust Trust Score: Compare the error between the results of each node and the aggregated result, and adjust the trust score of the adjustment node upward or downward based on the calculation time; B-3 Calculation Node Utility: Calculate the utility value of each node based on its calculation speed and result accuracy; B-4 Reward Allocation: Rewards are allocated from the reward pool according to the proportion of node utility value to incentivize high-performing nodes. The beneficial effects of this invention are: 1. Design a Multi-Dimensional Randomized Response (MDRR) mechanism to preserve the internal attribute correlation of data records while protecting privacy.

[0011] 2. Construct a hybrid computing mechanism that integrates consortium blockchains and differential privacy to achieve on-chain scheduling and efficient off-chain computing, thereby reducing computational overhead.

[0012] 3. A Trust-Utility Synergistic Optimization for Data Aggregation (TUSO) mechanism is proposed to improve the reliability and effectiveness of data sharing by combining trust scoring and data utility optimization.

[0013] In summary, the MDRR mechanism demonstrates superior performance in key metrics such as accuracy, while the TUSO mechanism overcomes the limitations of a single metric, providing computing nodes with a more comprehensive decision-making standard. Furthermore, this invention significantly improves the temporal performance of frequency estimation and reduces errors, proving its superiority in privacy protection and data sharing services. Attached Figure Description

[0014] Figure 1 Here is the system architecture diagram of this invention; Detailed Implementation

[0015] The present invention will now be described in further detail with reference to specific embodiments.

[0016] This invention proposes a contract data sharing method based on consortium blockchain and local differential privacy, which includes five types of entities: enterprise data providers, Group 1 contract data recording chain, Group 2 task management chain, off-chain cross-group scheduler CGO, and off-chain computing nodes. Enterprise data providers: As fundamental participants in the system, they hold local contract data. To protect privacy, users use a Multidimensional Random Response (MDRR) mechanism to locally differentiate and privacy-preservingly perturb the contract data, and only upload the perturbated, noisy data to the blockchain. This design ensures that no single piece of on-chain data exposes the original contract content.

[0017] Group 1 is responsible for on-chain data storage, recording LDP contract data submitted by enterprises. Because Group 1 has its own independent block height and transaction sequence, its data writing process has a stable order, which helps to build a traceable time-series contract data structure, providing a complete data source for subsequent statistical tasks.

[0018] Group 2: Deploys task management smart contracts for issuing statistical tasks and distributing rewards. Group 2 is logically isolated from Group 1 to avoid the impact of frequent data writes on task scheduling and to ensure that the state machine of the computation tasks runs in an independent environment.

[0019] CGO: Responsible for cross-group data scheduling, it is the key off-chain coordinating entity connecting Group 1 and Group 2. The CGO uses the FISCO BCOS Python SDK to access multiple groups simultaneously, continuously monitoring the block height of Group 1. When the height reaches a preset threshold, the CGO automatically invokes the smart contract of Group 2 to issue a new task. Furthermore, the CGO collects statistical results submitted by compute nodes, uses the TUSO mechanism for trustworthiness assessment, and constructs a Merkle Tree containing all computation results to generate verifiable result commitments.

[0020] Off-chain compute nodes: These are task executors who subscribe to task publication events in Group 2, obtain publicly available LDP contract data within a specified range from Group 1, and perform statistical calculations using their chosen multidimensional joint distribution estimation algorithm. They submit the calculation results to the CGO and receive on-chain incentives based on the final TUSO evaluation score.

[0021] Through the collaboration among the aforementioned entities, this model achieves decoupled operation of the data recording chain and the computation task chain, ensuring both the privacy protection and writing stability of contract data, as well as the reliable evaluation and auditability of the computation process.

[0022] The operation process of this invention includes five stages: contract data on-chain, task triggering, off-chain statistical calculation, trusted aggregation evaluation, and final on-chain and incentive allocation.

[0023] (1) Contract data on-chain stage: Enterprise users apply the MDRR mechanism to their local contract data to generate noisy LDP data and submit it to Group 1. As on-chain data accumulates, the block height of Group 1 gradually increases, forming a contract data record structure arranged in chronological order. The CGO monitors the block height of Group 1 through the Python SDK as a trigger condition for task initiation.

[0024] (2) Task triggering and cross-group scheduling phase: When the block height of Group 1 reaches the preset threshold N of a certain round of statistical tasks, the CGO initiates a publishTask() call to the Group 2 smart contract to create a new task and write task parameters (such as data range, task identifier, etc.). Group 2 generates a TaskPublished event, and all off-chain computing nodes automatically receive the task publishing information through the event subscription mechanism.

[0025] (3) Off-chain computing nodes perform statistical phase: The computing nodes access the publicly available LDP data in Group 1 according to the data range specified in the task, and complete statistical calculations such as multidimensional joint distribution estimation. Each node executes the task independently and submits the calculation results and signature to the CGO.

[0026] (4) Off-chain Trusted Aggregation Phase: The CGO collects all computation results and uses the TUSO mechanism to evaluate the accuracy, stability, and other dimensions of the node results, thereby generating the final trusted aggregation result. Furthermore, the CGO constructs a Merkle Tree for all the original results submitted by the nodes and uses its root hash as an on-chain commitment to the result set. Each node... The submitted local calculation results are denoted as These results are used as leaf nodes of a Merkle Tree. Adjacent leaf nodes are then concatenated pairwise and hashed to generate intermediate nodes for the next level. For example, a first-level intermediate node can be represented as... If the number of nodes at a certain level is odd, it can be padded by copying the last node or hashing it separately to ensure the integrity of the tree structure. The process is repeated recursively from bottom to top until a unique Merkle Root is generated. .

[0027] (5) On-chain verification of results and proof, and on-chain incentive phase: The CGO writes the final aggregated calculation result and its corresponding Merkle Root into the Group 1 blockchain. In subsequent dispute resolution or auditing phases, any node can provide its corresponding result. The Merkle Proof from the leaf node to the root node is used to verify whether the result is indeed included in the aggregation result set. Finally, the CGO calls the incentive distribution function in the Group 2 smart contract based on the node trust score and utility value calculated by the TUSO mechanism. Incentives are automatically distributed to off-chain computing nodes according to preset reward rules, encouraging nodes to continuously provide high-quality computing services.

[0028] Through the above five-stage collaboration, this model achieves a complete closed loop of trusted sharing of privacy-protected contract data, cross-group task scheduling, off-chain statistical calculation, and on-chain verifiable incentive mechanisms.

[0029] Among them, the Multi-Dimensional Randomized Response (MDRR) mechanism Includes: (1) Construction of randomized matrix set up The total number of data records. For crowdsourced datasets, Indicates from the Data records for each user. We assume the dataset... There is Attributes Each data record It can be represented as ,in Indicates the first The first user record Element. For each attribute ,we will Represented as The attribute domain, where yes The There are 10 possible attribute values, and yes The cardinality. If a user has attributes The actual value on (Right now If the value remains unchanged, then keep the original value. The probability is , and set to any other value The probability is 1 / 2. Based on this, we obtain a perturbation matrix : Among them, matrix elements Indicates when the actual value is At that time, the reported value was The conditional probability, i.e. , When the randomization mechanism is applied independently to each attribute, the overall randomization scheme satisfies properties of Theorem 1 and Theorem 2.

[0030] Theorem 1 (Multi-attribute Local Differential Privacy) If each attribute Independently adopted to meet -LDP randomization matrix Then the joint randomization mechanism satisfies -Local differential privacy.

[0031] prove: To prove that the multi-attribute mechanism of independent randomization satisfies Local differential privacy requires starting from the privacy-preserving properties of single-attribute randomization and providing a rigorous derivation based on the sequence combination principle of differential privacy. First, for any attribute... Its randomization mechanism is determined by the perturbation matrix. Determine the diagonal elements in the matrix. This represents the probability that the true value is retained, while all off-diagonal elements; This represents the probability that the input is randomly mapped to other values. Under this structure, for any real input... And for any possible output y, the corresponding probability ratio is: Therefore, the single-attribute mechanism strictly satisfies -Local differential privacy.

[0032] In processing multi-attribute input records At that time, the RR mechanism performs randomization independently for each attribute. Therefore, the perturbed joint output vector The probability distribution can be represented as the product of the output probabilities of each attribute, i.e.: To verify the privacy protection nature, select any two possible input records. and And considering the RR mechanism, the same perturbation vector is output. The likelihood ratio at time t. Based on the independent perturbation structure, this likelihood ratio can be written as: Since for each attribute randomization matrix The privacy loss ratio has an upper bound: Furthermore, there are d independent randomization steps, therefore the privacy loss of the joint mechanism is greater than the overall upper bound. According to the definition of local differential privacy, this indicates that the RR multi-attribute randomization mechanism satisfies... -Local differential privacy, thus proving the theorem.

[0033] Theorem 2 (Nonsingularity of randomized matrices) If the randomization matrix of each attribute satisfy (Right now ), then all All are non-singular matrices. Furthermore, multi-attribute joint randomization matrices... It is not strange, and there is This property ensures that the joint distribution of multiple attributes can be uniquely recovered through a linear inverse transformation without accessing the user's actual data.

[0034] prove: This theorem aims to prove that a single-attribute perturbation matrix in... Under the given conditions, it must be a non-singular matrix, and further, it is proved that the multi-attribute joint perturbation matrix formed by its Kronecker product must also be a non-singular matrix. First, consider arbitrary attributes. randomized matrix in exist This always holds true under the given condition. The matrix can be written in fractional form. ,in For the whole Vector. For vectors. Its corresponding characteristic value is ; and for any and orthogonal There are eigenvectors, each with eigenvalues ​​of 1. .because Both types of eigenvalues ​​mentioned above are positive, therefore It is a strictly positive definite matrix, and therefore necessarily non-singular. Meanwhile, when When the matrix degenerates into a uniform matrix with identical elements, its rank is . Therefore, the only possible singular condition is ;if only The matrix is ​​always invertible. Further considering the multi-attribute joint perturbation matrix, it is constructed as the Kronecker product of all single-attribute matrices: According to the classical property of the Kronecker product in linear algebra, if matrices A and B are both nonsingular matrices, then their Kronecker product is... It is neither strange nor strange, and it is satisfactory: Because each of these studies Both have been proven to be nonsingular matrices, therefore their Kronecker product must also be nonsingular. Furthermore, for each row of the joint perturbation matrix, since the Kronecker product preserves the structure of a row random matrix, it is easy to see that its row sum remains constant. Thus, the joint perturbation matrix still satisfies the definition of a randomized matrix. Therefore, the joint perturbation matrix is ​​both a valid randomized matrix and an invertible matrix, thereby ensuring the mathematical feasibility and uniqueness of the subsequent joint distribution recovery step based on matrix inversion.

[0035] (2) Frequency estimation Within the LDP framework, each attribute undergoes an independent RR perturbation. Let the set of all attributes be... Select any subset The goal is to recover the true joint distribution of the attribute set based on the perturbed observation data. For each attribute Its range is ,remember The probability transition matrix after perturbation is denoted as . After collecting sufficient samples, the perturbed empirical joint frequency vector can be calculated. ,in This vector is derived from the empirical joint frequency tensor. It is obtained by vectorization in row-major order, that is Since the RR mechanism has a linear structure, the expectation of the perturbation vector satisfies: Therefore, if the global Kronecker matrix is ​​invertible, the unbiased linear estimate of the true joint distribution is: However, directly inverting the large-dimensional perturbation matrix globally incurs computational costs that increase exponentially with dimensionality. To decompose... Given the structure, first consider the binary case. Let... and Attributes and Let the perturbation transition matrix be the perturbation matrix. Let the perturbation empirical vector be... ,in The direct inverse mapping of the joint distribution is: Using the properties of the Kronecker inverse matrix It can be transformed into: To demonstrate this structure, Written as ,but: Will Multiplying them together, we get: Note: Therefore, it can ultimately be written in matrix form: The joint recovery can be decomposed into two low-dimensional linear processes, with inverse perturbation performed along the direction of attribute B. Perform inverse perturbation along the direction of attribute A This avoids construction and inversion. A large matrix of dimension S. Generalizing to a set of arbitrary dimension S, using the property of the Kronecker inverse matrix, the joint distribution can be written as: According to the classical identity This can transform high-dimensional Kronecker operations into multimodal multiplication of tensors. Let ,but: in The first tensor represents the tensor. Modular multiplication (along property) (Direction execution reverse perturbation). To avoid constructing dimensions. For large matrices, recursive calculation is performed using modular successive inverse perturbation. Put the tensor along the first Expand the dimension into a matrix. Rearrange the matrix back into a tensor structure. Inverse perturbation Rearranged to the 1st Modular form and inverse perturbation , Repeat the above steps until the... The model, ultimately obtained and output: Algorithm 1 describes the pseudocode for MDRR, and the above recursive process is strictly equivalent to the following hierarchical expansion form: Each of them This indicates that the tensor expansion and rearrangement are of the th order. The required matrix shape for the modulus. The frequency recovery method constructed in this section has completely unbiased properties, and when the perturbation matrix is ​​invertible (sufficient condition see Theorem 2), the estimate satisfies... The overall Kronecker matrix dimension increases exponentially, while the recursive inverse mapping only requires... Low-dimensional matrix multiplication. Only the empirical tensor needs to be stored. No need to store large matrices.

[0036] Algorithm 1: Multidimensional Random Response Mechanism (MDRR) Input: , , ,

[0037] Output:

[0038] Initialize perturbation matrices

[0039] Collect perturbed reports

[0040] Compute empirical joint frequency tensor from perturbed observations

[0041] Vectorize empirical tensor

[0042] Initialize tensor for inverse perturbation

[0043] for do Unfold tensor

[0044] Apply inverse perturbation matrix

[0045] Fold back to tensor form

[0046] end for Return

[0047] Among them, the Trust-Utility Synergistic Optimization for Data Aggregation (TUSO) mechanism is a key component. In decentralized service systems, when different off-chain nodes process and statistically analyze the same data, inconsistencies in frequency statistics arise due to the different algorithms or methods employed by each node. To address this, we propose a Trust-Utility Collaborative Optimization (TUSO) data aggregation mechanism. This mechanism ensures the accuracy of data aggregation through dynamic trust scoring and weighting, while preventing the influence of malicious nodes. Furthermore, it incorporates a utility function for short-term incentives, balancing the robustness of the service system with computational efficiency.

[0048] (1) Trust evolution method based on dynamic feedback The prior-posterior dynamic trust assessment method optimizes trust scoring. The calculation makes it dependent on error assessment and time threshold adjustment. During the prior hypothesis phase, each node... Statistical results The nodes will be weighted according to their historical trust scores, and the final weighted aggregation result of all nodes will be obtained. .

[0049] Among them, nodes weight The trust score is normalized to ensure that the results of trusted nodes have a greater weight in the final aggregation. As data evidence, nodes The estimated frequency statistical error is defined as And combined with the computation time of the nodes Post-hoc adjustments were made to improve the trust score. Dynamic optimization is used to balance calculation accuracy and submission timeliness.

[0050] Specifically, when the error is small, the node trust score increases; conversely, it decreases, with the adjustment rules as follows: in, The excitation coefficient for correct aggregation, This is the penalty coefficient for error aggregation. An adaptive error threshold. Error threshold Dynamically calculate based on the error statistics of all computing nodes: To encourage nodes to submit computation results promptly, we set a computation time threshold. Node computation time When the threshold is exceeded, the trust score will decrease. The specific adjustment rules are as follows: in, This is the penalty coefficient for exceeding the time limit. Dynamic calculation of computation time statistics for nodes: in, To calculate the time mean, To calculate the standard deviation over time: Node's final trust score It is a combined result of calculation time and data bias: To ensure trust rating Within a reasonable range, let: in and Minimum and maximum thresholds for trust rating. Trust rating. Node reliability is measured over a long period, and their weights are dynamically adjusted. This is in contrast to computation time. Its error Sensitive. Only in When a threshold is exceeded, the score is reduced, thus prioritizing computational accuracy. This mechanism enhances robustness, preventing a single computational error from causing a complete loss of trust, while allowing nodes to gradually recover their scores through sustained stable performance.

[0051] (2) Incentive mechanism based on node utility To encourage nodes to complete computation tasks promptly and accurately, a utility function for computation nodes is designed: in, To calculate the time reward coefficient, For calculation accuracy, To incentivize nodes to provide more accurate calculation results, a precision reward coefficient is applied. Primarily used for short-term decision-making and incentives, it measures the immediate benefits of nodes in the current task, reflecting their contribution. A reward pool is set up. ,node Rewards Distributed based on its relative contribution across all nodes: The smart contract automatically distributes rewards based on the contributions of computing nodes, quickly and fairly incentivizing high-quality and fast-computing nodes. The specific algorithm implementation is shown in Algorithm 2.

[0052] Algorithm 2: Data aggregation rules based on trust score weighting Required: Statistical results trust scores computationtimes reward pool

[0053] Ensure: Updated trust scores and rewards

[0054] Initialize aggregated result

[0055] for to

[0056]

[0057]

[0058] end for for to

[0059]

[0060]

[0061] end for for to

[0062]

[0063] end for for to

[0064]

[0065] Send to node

[0066] end for The above description is only a part of the specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A contract data sharing method based on consortium blockchain and local differential privacy, characterized in that: The method comprises 5 entities and 5 task execution phases; the 5 entities are: enterprise data provider, Group 1 contract data record chain, Group 2 task management chain, off-chain cross-group scheduler CGO, and off-chain computing node; The five task execution phases are: contract data on-chain phase, task triggering and cross-group scheduling, off-chain computing node execution statistics, off-chain trusted aggregation, on-chain and incentive allocation; The enterprise data provider is a basic participant in the system, holding local contract data. It performs local differential privacy perturbation on the contract data through the Multidimensional Random Response (MDRR) mechanism and only uploads the perturbated, noisy data to the blockchain. Group 1 Contract Data Recording Chain: Responsible for on-chain data storage, used to record LDP contract data submitted by enterprises; Group 2 Task Management Chain: Deploys task management smart contracts for issuing statistical tasks and distributing rewards; Off-chain cross-group scheduler (CGO): Responsible for cross-group data scheduling, it is the key off-chain coordination entity connecting Group 1 and Group 2; Off-chain computing nodes: As task executors, they subscribe to task publication events in Group 2, obtain public LDP contract data within a specified range from Group 1, and complete statistical calculations using a multidimensional joint distribution estimation algorithm of their own choice; During the contract data on-chain stage: the enterprise data provider applies the MDRR mechanism to the local contract data to generate noisy LDP data and submits it to Group 1. As the on-chain data accumulates, the block height of Group 1 gradually increases, forming a contract data record structure arranged in chronological order. The CGO listens to the block height of Group 1 through the Python SDK as a trigger condition for task startup. Task triggering and cross-group scheduling phase: When the block height of Group 1 reaches the preset threshold N of a certain round of statistical tasks, the CGO initiates a publishTask() call to the Group 2 smart contract to create a new task and write the task parameters. Group 2 generates a TaskPublished event, and all off-chain computing nodes automatically receive the task publishing information through the event subscription mechanism. Off-chain computing nodes perform the statistical phase: The computing nodes access the publicly available LDP data of Group 1 according to the data range specified in the task, complete the multidimensional joint distribution estimation, and each node independently executes the task and submits the calculation results and signature to the CGO; Off-chain trusted aggregation phase: The CGO collects all computation results and uses the TUSO mechanism, a data aggregation mechanism based on trust-utility collaborative optimization, to perform multi-dimensional evaluation of the accuracy and stability of the node results, thereby generating the final trusted aggregation result. Furthermore, the CGO constructs a Merkle Tree for all the original results submitted by nodes and uses its root hash as an on-chain commitment to the result set. The local computation result submitted by each node i is denoted as... These results are used as leaf nodes of the Merkle Tree. Adjacent leaf nodes are concatenated pairwise and hashed to generate intermediate nodes for the next level. If the number of nodes is odd, padding is performed by either copying the last node or hashing it separately to ensure the integrity of the tree structure. This process is repeated recursively from bottom to top until a unique Merkle Root is generated. ; On-chain and incentive distribution phase: The CGO writes the final aggregated calculation result and its corresponding Merkle Root into the Group 1 blockchain. In subsequent dispute resolution or auditing phases, any node can provide its corresponding result. The Merkle Proof from the leaf node to the root node is used to verify whether the result is indeed included in the aggregation result set. Finally, the CGO calls the incentive distribution function in the Group 2 smart contract based on the node trust score and utility value calculated by the TUSO data aggregation mechanism based on trust-utility collaborative optimization. The incentive distribution to the off-chain computing nodes is automatically completed according to the preset reward rules to promote the continuous provision of high-quality computing services by the nodes.

2. The contract data sharing method based on consortium blockchain and local differential privacy according to claim 1, characterized in that, The Multidimensional Random Response (MDRR) mechanism consists of the following four working steps: A-1 constructs the perturbation matrix: assigns a probability to each attribute of the data to retain the true value and replace it with other values, forming the corresponding perturbation matrix; A-2 Local Data Perturbation: Users randomly adjust each attribute of each of their own data entries according to the corresponding perturbation matrix before submitting; A-3 Statistical Perturbation Data: Collect all perturbed data and calculate the frequency of occurrence of each attribute combination. A-4 restores the true distribution: iteratively corrects the data along the attribute dimensions and restores the true distribution of the data through matrix inverse operations.

3. The contract data sharing method based on consortium blockchain and local differential privacy according to claim 1, characterized in that, The trust-utility collaborative optimization-based data aggregation mechanism TUSO consists of the following four working steps: B-1 Initial Weighted Aggregation: Weights are assigned to each node based on its historical trust score, and the initial aggregation result is calculated using weighted averages. B-2 Dynamically Adjust Trust Score: Compare the error between the results of each node and the aggregated result, and adjust the trust score of the adjustment node upward or downward based on the calculation time; B-3 Calculation Node Utility: Calculate the utility value of each node based on its calculation speed and result accuracy; B-4 Reward Allocation: Rewards are allocated from the reward pool according to the proportion of node utility value to incentivize high-quality nodes.

Images