A method, system, and electronic device for secure cross-organizational data exchange based on privacy computing.

Abstract

This application discloses a method, system, and electronic device for secure cross-organizational data exchange based on privacy-preserving computation, belonging to the technical field of electronic data processing. The method includes: a local smart contract extracting the hash value and range proof of a target field, and submitting digital assets to a coordination contract; the coordination contract verifying the range proof by performing set intersection using encrypted Bloom strings and homomorphic logic AND operations; the local smart contract calculating local gradients based on random challenge numbers and generating zero-knowledge proofs; and the coordination contract triggering asset confiscation or executing weighted aggregation, iterating until model convergence. This application achieves data source credibility through the collaboration of range proofs and hash on-chaining, achieves sample alignment under privacy protection through encrypted Bloom strings and homomorphic operations, constructs a verifiable computation framework through random challenge numbers and zero-knowledge proofs, and achieves incentive compatibility by synchronizing asset transfer and verification status, thus solving the problems of privacy leakage and computational distortion in cross-organizational data collaboration.

Description

Technical Field

[0001] This application relates to a method, system, and electronic device for secure cross-organizational data exchange based on privacy computing, belonging to the technical field of electronic data processing. Background Technology

[0002] Secure cross-organizational data exchange has wide applications in scenarios such as joint credit reporting, supply chain finance, and anti-fraud. For example, when banks and third-party payment institutions jointly build credit scoring models, both parties hope to integrate their respective user transaction data and credit records to improve the model's discriminatory power. However, directly exchanging raw data faces compliance obstacles at the legal level. Personal financial information is strictly regulated by laws and regulations such as the Personal Information Protection Law, and data leaving the domain requires individual user authorization, making bulk acquisition difficult in practice.

[0003] In existing technologies, federated learning frameworks are widely used to solve such problems. Each participant retains the original data locally and only uploads the model gradients to the central server. However, practical deployment experience shows that existing solutions have at least three types of engineering flaws: First, the central server can observe the gradient vectors uploaded by each participant in each training round. Through gradient inversion attacks (such as Deep Leakage from Gradients), it can reconstruct the original features at the sample level within dozens of iterations, achieving an accuracy of over 85% for sparse features (such as whether a user has defaulted on payments). Second, the gradients submitted by the participants lack a verifiable mechanism. Malicious nodes may submit random normally distributed noise or constant gradients (such as all-zero vectors), interfering with the convergence direction of the global model. Existing federated aggregation algorithms (such as FedAvg) lack effective robustness against such attacks.

[0004] In another type of existing technology, the solution is based on a trusted execution environment, such as Intel SGX or ARM TrustZone, to aggregate data from multiple parties into an Enclave for joint computation. However, the physical memory limit of an SGX Enclave is typically 128MB, with even lower actual usable heap memory. For example, loading a credit scoring dataset containing 200 features and 5 million samples requires approximately 4GB of memory per party, far exceeding the Enclave's capacity limit. While shard loading or streaming processing can be used in practice, cross-organizational shard alignment introduces additional encrypted communication overhead, and in real-world testing, a single training round can take minutes, increasing the pressure on computing power.

[0005] In summary, existing technical solutions fail to address the issues of economic incentives and behavioral auditing for participating parties. In practice, data holders contribute computing power and bandwidth resources to participate in collaborative computing, but existing frameworks cannot quantify their contributions or provide reasonable compensation, leading to insufficient participation. Furthermore, violations (such as submitting incorrect data or withdrawing midway) cannot be automatically traced, relying solely on post-event manual auditing, which is inefficient. Therefore, existing technologies no longer meet the requirements and urgently need improvement. Summary of the Invention

[0006] The main objective of this application is to provide a method, system, and electronic device for secure cross-organizational data exchange based on privacy computing, in order to solve the technical problems of privacy leakage, computational distortion, and lack of incentives in the prior art.

[0007] The embodiments of this application are implemented using the following technical solutions: According to one aspect of the embodiments of this application, a method for secure cross-organizational data exchange based on privacy computing is provided, comprising: in response to a joint computing task initiated by a coordination contract, a local smart contract extracts a target field from a local database, calculates the hash value of the target field and generates a range proof, and submits the digital asset corresponding to the range proof to the coordination contract; the coordination contract verifies the range proof, and if the verification fails, allocates the corresponding digital asset to other local smart contracts, or if the verification passes, stores the hash value in a blockchain network; the coordination contract initiates a set intersection, each local smart contract constructs a cryptographic Bloom string and returns it, and the coordination contract performs cryptographic... The Bloom string performs a homomorphic AND operation to calculate the corresponding encrypted intersection string and broadcasts it. The local smart contract decrypts the encrypted intersection string to obtain the corresponding public sample identifier set, and the coordination contract generates a random challenge number and broadcasts it. The local smart contract calculates the local gradient based on the public sample identifier, the local feature matrix, and the random challenge number, and generates a zero-knowledge proof for verifying the local gradient. The coordination contract verifies the zero-knowledge proof. If the verification fails, it triggers the scrambling of digital assets. Alternatively, if the verification passes, it performs a weighted aggregation of all local gradients, updates the model weight parameters, and repeats the above gradient submission and aggregation steps until the model converges, completing the secure data exchange.

[0008] According to at least one specific implementation of the embodiments of this application, the generation method of the range proof is as follows: the local smart contract obtains the preset lower limit and upper limit of the normal value range, uses the Bulletproofs protocol to perform range proof calculation on the value of the target field, and generates a zero-knowledge range proof, wherein the zero-knowledge range proof is used to prove that the value of the target field is between the lower limit and the upper limit.

[0009] According to at least one specific implementation of the embodiments of this application, the digital asset is specifically: before initiating a joint computing task, the coordination contract calls a pre-deployed asset custody contract. The asset custody contract freezes a preset number of digital assets from the account address corresponding to the local smart contract according to the asset lock request submitted by the local smart contract, and generates an asset lock certificate. The local smart contract attaches the asset lock certificate to the data commitment package for submission.

[0010] According to at least one specific embodiment of the present application, storing the hash value in the blockchain network further includes: the coordination contract uses the hash values ​​submitted by each verified local smart contract as leaf nodes, inserts them sequentially into the global state Merkle tree in the order of receipt, and recalculates the Merkle path from the leaf node to the root node. The coordination contract returns the Merkle path as a storage location index to the corresponding local smart contract, which is used by the local smart contract to prove that its data has been legally recorded by providing the hash value and the Merkle path in the subsequent verification process. The construction method of the encrypted Bloom string is as follows: the local smart contract selects a bit string of a preset length as the underlying array of the Bloom filter, inputs each sample identifier in the local sample identifier set into a plurality of preset independent hash functions in sequence, each hash function outputs a mapping position, and sets the bit corresponding to the mapping position to 1. After all sample identifiers have been processed, the local smart contract uses the homomorphic encryption public key distributed by the coordination contract to encrypt the value of each bit of the bit string to generate the encrypted Bloom string.

[0011] According to at least one specific implementation of the embodiments of this application, the distribution method of the homomorphic encryption public key is as follows: before initiating the joint computing task, the coordination contract calls the trusted execution environment to generate a pair of homomorphic encryption key pairs, including a homomorphic encryption public key and a homomorphic encryption private key, and the coordination contract broadcasts the homomorphic encryption public key to all local smart contracts participating in the joint computing task.

[0012] According to at least one specific embodiment of the present application, the execution method of the homomorphic logical AND operation is as follows: the coordination contract receives the encrypted Bloom string returned by all participants, and performs homomorphic multiplication operation on the ciphertext values ​​at the same bit position in the encrypted Bloom string one by one; in the unencrypted state, a bit position 1 corresponds to an encrypted value 1, and a bit position 0 corresponds to an encrypted value 0. The calculation result of the homomorphic multiplication is equivalent to the logical AND operation of the original bit position in the encrypted state; the generation method of the random challenge number is as follows: when the coordination contract initiates the gradient calculation phase, it obtains the latest block hash value in the current blockchain network, and concatenates the block hash value with the task identifier of the joint calculation task; the coordination contract performs SHA-256 hash operation on the concatenated string, and broadcasts the operation result as a random challenge number to all local smart contracts participating in the joint calculation task, so as to prevent each local smart contract from pre-calculating or reusing historical gradient values.

[0013] According to at least one specific embodiment of the present application, the calculation method of the local gradient further includes: the local smart contract extracts a feature subset corresponding to the public sample identifier set from the local feature matrix based on the public sample identifier set obtained by decryption; the local smart contract obtains the latest weight parameters of the current joint model, uses the random challenge number as the seed of the pseudo-random number generator, randomly samples some samples in the feature subset, and calculates the local gradient using the stochastic gradient descent method.

[0014] According to at least one specific embodiment of the present application, the weighted aggregation further includes: a coordination contract maintaining a historical verification record table, recording the number of times each local smart contract's zero-knowledge proofs passed verification and the total number of verifications in each joint computation task; the coordination contract calculating the historical verification success rate of each local smart contract based on the ratio of the number of successful verifications to the total number of verifications, using the historical verification success rate as a weighting coefficient to perform a weighted summation of the local gradients submitted by the local smart contracts to calculate the global gradient, and using the global gradient to update the weight parameters of the joint model.

[0015] According to another aspect of the embodiments of this application, a cross-organizational data security exchange system based on privacy computing is provided, used to implement the cross-organizational data security exchange method based on privacy computing, including: a range proof digital asset generation module, which, in response to a joint computing task initiated by a coordination contract, extracts a target field from a local database, calculates the hash value of the target field and generates a range proof, and submits the digital asset corresponding to the range proof to the coordination contract; an encrypted intersection string broadcasting module, in which the coordination contract verifies the range proof, and if the verification fails, allocates the corresponding digital asset to other local smart contracts, or if the verification passes, stores the hash value in a blockchain network; the coordination contract initiates a set intersection, and each local smart contract constructs an encrypted intersection string broadcasting module. The Bloom string is returned in parallel. The coordination contract performs a homomorphic AND operation on the encrypted Bloom string to calculate the corresponding encrypted intersection string and broadcasts it. The local gradient zero-knowledge proof module decrypts the encrypted intersection string to obtain the corresponding public sample identifier set. The coordination contract generates a random challenge number and broadcasts it. The local smart contract calculates the local gradient based on the public sample identifier, the local feature matrix, and the random challenge number, and generates a zero-knowledge proof to verify the local gradient. The model weight parameter update module verifies the zero-knowledge proof. If the verification fails, digital asset scrambling is triggered. Alternatively, if the verification passes, all local gradients are weighted and aggregated, and the model weight parameters are updated. The gradient submission and aggregation steps are repeated until the model converges, completing the secure data exchange.

[0016] According to another aspect of the embodiments of this application, an electronic device is provided, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method.

[0017] The beneficial technical effects of the embodiments of this application are: This application embodiment employs a two-layer interaction between a coordination contract and a local smart contract. During the data preparation phase, each participant extracts target fields and generates hash values ​​and interval proofs through the local smart contract, staking the corresponding digital assets to the coordination contract to form an initial constraint of verification-reward / penalty: the coordination contract verifies the interval proofs; failure results in asset confiscation and redistribution, while success ensures the hash value is recorded on the blockchain for evidence storage, guaranteeing data traceability. Subsequently, in the set intersection phase, the local smart contract constructs and returns an encrypted Bloom string, while the coordination contract uses homomorphic logic and AND operations to calculate and broadcast the encrypted intersection string. Each participant decrypts the string to obtain a common set of sample identifiers, completing sample alignment without exposing their original data. During the model training phase, the coordination contract generates random challenge numbers and broadcasts them to each node. The local smart contract calculates local gradients based on the common sample identifiers, local feature matrices, and challenge numbers, generating zero-knowledge proofs. The coordination contract verifies the authenticity of the proofs; failure triggers digital asset confiscation, while success involves weighted aggregation of the local gradients to update model parameters, iterating until convergence.

[0018] This application's embodiments achieve a dual improvement in privacy protection and trusted computing through multi-stage collaboration: the collaboration between interval proof and hash on-chain achieves a unity of data availability and source credibility; the collaboration between encrypted Bloom strings and homomorphic logic AND operations eliminates the need to decrypt the original data during cross-organizational sample intersection, avoiding the exposure of sensitive information and ensuring that all participants obtain consistent public sample identifiers through a broadcast mechanism, laying an alignment foundation for distributed training. The collaboration between random challenge numbers and zero-knowledge proofs constructs a verifiable computing framework, where local gradients are bound to challenge responses the moment they are generated, and any tampering will invalidate the proof; the collaboration between weighted aggregation and iterative convergence achieves global model optimization while protecting the local feature matrices of each participant; the circulation of digital assets is always synchronized with the verification status; and the nested functions of blockchain's notarization, privacy computing encryption, and smart contract automatic execution ensure that the entire data exchange process is in an auditable, verifiable, and data-free secure state, solving multiple technical problems such as privacy leakage, computational distortion, and lack of incentives in cross-organizational data collaboration. Attached Figure Description

[0019] To more clearly illustrate the specific implementation methods of the embodiments of this application or the technical solutions in the prior art, the drawings used in the description of the specific implementation methods or the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of a method for secure cross-organizational data exchange based on privacy-preserving computation.

[0021] Figure 2 This is an architecture diagram of a cross-organizational data security exchange system based on privacy computing.

[0022] Figure 3 This is a schematic diagram of the electronic device. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this application, and not all embodiments. Based on the specific implementation methods in the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the embodiments of this application.

[0024] like Figure 1 The privacy-preserving computation-based method for secure cross-organizational data exchange, as shown, includes: Step S1: In response to the joint computation task initiated by the coordination contract, the local smart contract extracts the target field from the local database, calculates the hash value of the target field and generates a range proof, and submits the digital asset corresponding to the range proof to the coordination contract.

[0025] Step S2: The coordination contract verifies the interval proof. If the verification fails, the corresponding digital asset is allocated to other local smart contracts. Alternatively, if the verification passes, the hash value is stored in the blockchain network. The coordination contract initiates a set intersection calculation. Each local smart contract constructs a cryptographic Bloom string and returns it. The coordination contract performs a homomorphic AND operation on the cryptographic Bloom string, calculates the corresponding cryptographic intersection string, and broadcasts it.

[0026] Step S3: The local smart contract decrypts the encrypted intersection string to obtain the corresponding public sample identifier set, coordinates the contract to generate a random challenge number and broadcasts it, and calculates the local gradient based on the public sample identifier, the local feature matrix and the random challenge number, and generates a zero-knowledge proof for verifying the local gradient.

[0027] Step S4: Coordinate the contract to verify the zero-knowledge proof. If the verification fails, digital asset scrapping is triggered. Alternatively, if the verification passes, all local gradients are weighted and aggregated, the model weight parameters are updated, and the above gradient submission and aggregation steps are repeated until the model converges, thus completing the secure data exchange.

[0028] In the technical solutions provided in steps S1 to S4, the interval proof submitted in step S1 is batch verified by the coordinated contract in step S2. The digital assets of participants whose verification fails are immediately allocated to other participants and excluded from subsequent processes. Only participants whose interval proofs pass verification can enter the set intersection stage. Compared to the passive "participate first, audit later" model of existing technologies, this approach moves the interception of non-compliant participants to the task entry point, avoiding invalid or malicious data contaminating the sample alignment results and saving computational and communication resources in subsequent stages.

[0029] After the encrypted intersection string output in step S2 is decrypted by the local smart contract, a common sample identifier set is obtained. This common sample identifier set serves as the sample space for gradient calculation in step S3. This ensures that when each participant calculates its local gradient, the sample identifiers used are constrained to the multi-party common intersection determined in step S2, rather than their own randomly selected local sample subsets. Step S2, in coordination with step S1, eliminates the problem of inconsistent model update directions caused by participants using different sample sets. Without the coordination between steps S2 and S1, if a participant uses non-intersection samples to calculate the gradient, its update direction may deviate from the global optimization objective, thereby reducing the model's convergence speed.

[0030] The zero-knowledge proof generated in step S3 and the digital assets in step S1 are processed in tandem in step S4. The coordination contract verifies the zero-knowledge proof: if verification fails, the confiscation and redistribution of the locked assets in step S1 is triggered; if verification passes, the participant's local gradient is included in the weighted aggregation. It can be seen that through the coordinated efforts of multiple steps, the economic interests of the participants are directly linked to the compliance of their computational behavior, forming an endogenous incentive-compatible mechanism. Any attempt to submit an incorrect gradient, forge the computation process, or withdraw midway will result in the zero-knowledge proof verification failing, thus causing the participant to suffer a deterministic asset loss, thereby preventing malicious behavior at the pre-emptive level.

[0031] It is worth noting that the digital assets in this embodiment are compared with existing federated learning frameworks and offer superior technical effects. In conventional federated learning frameworks, violations are typically only logged, audited by administrators afterward, and nodes are removed, resulting in delayed execution and limited deterrent effect. In this embodiment, however, penalties are automatically executed in real time by smart contracts. Violations generate immediate economic consequences upon detection, without relying on any third-party arbitration body. This allows the solution to ensure the reliability and fairness of the federated computing process even in the absence of centralized trusted nodes.

[0032] Blockchain solves the core technical challenge of virtual assets—double-spending—through distributed ledgers. All transaction records are stored on the chain after consensus verification, ensuring immutability and forgery resistance, guaranteeing the uniqueness and traceability of ownership of each virtual asset. Smart contracts endow virtual assets with programmability; once preset conditions are met, the contract automatically executes asset locking, transfer, or allocation operations without third-party arbitration, reducing trust costs for both parties. The transparency and auditability of blockchain enhance the credibility of virtual assets. On-chain transaction records are publicly verifiable, allowing regulators or auditors to monitor asset flows in real time without relying on post-event reports from asset custodians. Digital asset forfeiture utilizes smart contracts to achieve economic behavioral constraints through virtual assets, embedding economic incentives within the protocol rules. This aligns individual actions aimed at maximizing benefits with the overall collective goal of honesty and compliance, a key innovation of this application's embodiments compared to existing technologies.

[0033] In summary, the overall technical solution provided in steps S1 to S4 completes the data compliance guarantee and asset locking, participant screening and sample alignment, verifiable computational evidence generation, and verification and reward / punishment decision-making, thus achieving secure data exchange across organizations while protecting the data privacy of all parties.

[0034] Preferably, in step S1, the interval proof is generated as follows: the local smart contract obtains a preset lower and upper limit value of the normal value range, uses the Bulletproofs protocol to perform range proof calculations on the value of the target field, and generates a zero-knowledge range proof. The zero-knowledge range proof is used to prove that the value of the target field is between the lower and upper limits. The zero-knowledge range proof can prove the validity of the original value of the target field to the verifier without exposing the original value of the target field. Each local smart contract packages the hash value and the zero-knowledge range proof into a data commitment package and submits them to the coordination contract.

[0035] Preferably, the digital assets are: before initiating the joint computing task, the coordination contract calls a pre-deployed asset custody contract. The asset custody contract freezes a preset number of digital assets from the account address corresponding to the local smart contract according to the asset locking request submitted by the local smart contract, and generates an asset locking certificate. The local smart contract attaches the asset locking certificate to the data commitment package for submission, which is used for asset confiscation and redistribution operations in the event of subsequent verification failure.

[0036] In the preferred technical solution of step S1, the Bulletproofs protocol is used to generate interval proofs. This, combined with the asset custody contract freezing digital assets and generating lock certificates, forms a dual binding mechanism of data validity commitment and economic performance guarantee. The asset lock certificate is attached to the data commitment package for submission, ensuring that the data package submitted in step S1 simultaneously carries both technical compliance proof and economic default costs, providing an executable asset source for the subsequent asset confiscation in step S4.

[0037] Preferably, in step S2, storing the hash value in the blockchain network further includes: the coordination contract using the hash values ​​submitted by each verified local smart contract as leaf nodes, inserting them sequentially into the global state Merkle tree in the order of receipt, and recalculating the Merkle path from the leaf node to the root node. The coordination contract then returns the Merkle path as a storage location index to the corresponding local smart contract, so that the local smart contract can prove that its data has been legally recorded by providing the hash value and the Merkle path during subsequent verification.

[0038] The encrypted Bloom string is constructed as follows: the local smart contract selects a bit string of a preset length as the underlying array of the Bloom filter, inputs each sample identifier in the local sample identifier set into multiple preset independent hash functions in sequence, each hash function outputs a mapping position, and sets the bit corresponding to the mapping position to 1.

[0039] After all sample identifiers have been processed, the local smart contract uses the homomorphic encryption public key distributed by the coordinating contract to encrypt the value of each bit in the bit string, generating an encrypted Bloom string.

[0040] As an example, the distribution method of the homomorphic encryption public key is as follows: Before initiating the joint computation task, the coordinating contract calls the trusted execution environment to generate a homomorphic encryption key pair, including a homomorphic encryption public key and a homomorphic encryption private key. The coordinating contract then broadcasts the homomorphic encryption public key to all local smart contracts participating in the joint computation task. In the example scheme, the homomorphic encryption private key is split and secretly shared with the local smart contracts. The local smart contracts only hold a fragment of the private key and cannot independently decrypt the complete ciphertext.

[0041] Preferably, in step S2, the homomorphic logic AND operation is performed as follows: the coordination contract receives the encrypted Bloom string returned by all participants, and performs homomorphic multiplication operation on the ciphertext values ​​at the same bit position in the encrypted Bloom string one by one. In the unencrypted state, a bit of 1 corresponds to an encrypted value of 1, and a bit of 0 corresponds to an encrypted value of 0. The result of homomorphic multiplication in the encrypted state is equivalent to a logical AND operation on the original bits. After all bits have been processed, the coordination contract obtains the encrypted intersection string and broadcasts the encrypted intersection string to each local smart contract.

[0042] The random challenge number is generated as follows: when the coordination contract initiates the gradient calculation phase, it obtains the latest block hash value in the current blockchain network and concatenates the block hash value with the task identifier of the joint calculation task; the coordination contract performs SHA-256 hash operation on the concatenated string and broadcasts the result as the random challenge number to all local smart contracts participating in the joint calculation task, in order to prevent each local smart contract from pre-calculating or reusing historical gradient values.

[0043] In the preferred technical solution of step S2, the coordination contract inserts the hash value into the global state Merkle tree and returns the Merkle path as an index. This allows each local smart contract to prove that the data has been legally recorded simply by providing the hash value and path during subsequent audits, without needing to traverse the entire chain. This design reduces the verification complexity from O(n) to O(log n), lowering the computational overhead of on-chain verification. Furthermore, the homomorphic encryption private key is split and secretly shared with each participant, ensuring that no single local smart contract holds only a fragment of the private key and cannot independently decrypt the complete ciphertext. This prevents a single node from prematurely decrypting all intersection information after obtaining the encrypted intersection string, protecting the sample identifier privacy of other participants.

[0044] Preferably, in step S3, the calculation method of the local gradient further includes: the local smart contract extracts a subset of features corresponding to the public sample identifier set from the local feature matrix based on the public sample identifier set obtained by decryption; The local smart contract obtains the latest weight parameters of the current joint model, uses the random challenge number as the seed for the pseudo-random number generator, randomly samples a subset of samples from the feature set, and calculates the local gradient using stochastic gradient descent. Zero-knowledge proof is a cryptographic protocol that allows one party to prove a statement to another without revealing any information other than the truth of the statement. For example, a prover proves to a verifier that they know a secret (such as a password or the prime factors of a composite number), but the verifier cannot obtain the secret itself held by the prover throughout the process.

[0045] Zero-knowledge proofs must satisfy three core properties: completeness (true statements can always be proven), reliability (false statements cannot be proven), and zero knowledge (verifiers learn no additional information beyond the truthfulness of the statements). They have wide applications in fields such as identity authentication, digital currency, privacy computing, and blockchain. Currently, the mainstream implementation methods include interactive zero-knowledge proofs (requiring multiple rounds of interaction) and non-interactive zero-knowledge proofs (which can compress the interaction into a single round through the Fiat-Shamir transformation).

[0046] The role of zero-knowledge proofs includes, but is not limited to: coordinating contracts to generate unpredictable random challenge numbers based on block hashes. These random challenge numbers serve as the public input to the zero-knowledge proof circuit. The local smart contract must use these challenge numbers as seeds to sample a subset of features and calculate gradients. Simultaneously proving the circuit, it must also verify that gradient calculations depend on the random challenge numbers. Binding zero-knowledge proofs and random challenge numbers prevents replay attacks by pre-compiling gradients, ensuring the uniqueness of each round of proof.

[0047] The coordination contract verifies zero-knowledge proofs. If the verification fails, asset confiscation is triggered and distributed to other nodes. Zero-knowledge proofs ensure the verifiability of computational correctness from a technical perspective, while asset confiscation provides a strong economic incentive for honest participation. Technical trustworthiness and economic constraints form a dual guarantee: cheating nodes cannot pass verification technically and suffer asset losses economically.

[0048] Preferably, in step S4, the weighted aggregation further includes: The coordination contract maintains a historical verification record table, which records the number of times each local smart contract's zero-knowledge proofs have passed verification and the total number of verifications in each joint computation task; The coordination contract calculates the historical verification success rate of each local smart contract based on the ratio of the number of successful verifications to the total number of verifications. Using the historical verification success rate as a weighting coefficient, the local gradients submitted by the local smart contracts are weighted and summed to calculate the global gradient. The weight parameters of the joint model are then updated using the global gradient.

[0049] like Figure 2 The privacy-preserving computation-based cross-organizational data security exchange system shown is used to implement the privacy-preserving computation-based cross-organizational data security exchange method described in any specific embodiment of the present application, including: The interval proof digital asset generation module responds to the joint computing task initiated by the coordination contract. The local smart contract extracts the target field from the local database, calculates the hash value of the target field and generates an interval proof, and submits the digital asset corresponding to the interval proof to the coordination contract. The encrypted intersection string broadcast module coordinates the contract to verify the interval proof. If the verification fails, the corresponding digital asset is allocated to other local smart contracts. Alternatively, if the verification passes, the hash value is stored in the blockchain network. The coordination contract initiates a set intersection calculation. Each local smart contract constructs an encrypted Bloom string and returns it. The coordination contract performs a homomorphic logical AND operation on the encrypted Bloom string to calculate the corresponding encrypted intersection string and broadcasts it. The local gradient zero-knowledge proof module involves a local smart contract that decrypts the encrypted intersection string to obtain the corresponding public sample identifier set, coordinates the contract to generate a random challenge number and broadcasts it, and calculates the local gradient based on the public sample identifier, the local feature matrix and the random challenge number, and generates a zero-knowledge proof for verifying the local gradient. The model weight parameter update module coordinates the contract to verify the zero-knowledge proof. If the verification fails, it triggers the scrambling of digital assets. Alternatively, if the verification passes, it performs weighted aggregation on all local gradients, updates the model weight parameters, and repeats the above gradient submission and aggregation steps until the model converges, thus completing the secure data exchange.

[0050] like Figure 3 As shown, this application embodiment, in addition to providing a method and system for secure cross-organizational data exchange based on privacy computing, also provides a corresponding electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, communication interface, and memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method for secure cross-organizational data exchange based on privacy computing.

[0051] Explanation of reference numerals in the attached drawings: processor 710, memory 720, input device 730, output device 740.

[0052] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device provided in this embodiment includes: one or more processors 710 and a memory 720; the processor 710 in the electronic device may be one or more. Figure 3 Taking a processor 710 as an example; memory 720 is used to store one or more programs; the one or more programs are executed by the one or more processors 710, causing the one or more processors 710 to implement the cross-organizational data security exchange method based on privacy computing as described in any one of the embodiments of this application.

[0053] The electronic device may also include an input device 730 and an output device 740.

[0054] The processor 710, memory 720, input device 730, and output device 740 in this electronic device can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0055] The memory 720 in this electronic device serves as a computer-readable storage medium, capable of storing one or more programs. These programs can be software programs, computer-executable programs, or modules, such as the program instructions / modules corresponding to the privacy-based computation-based cross-organizational data security exchange method provided in this embodiment. The processor 710 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 720, thereby implementing the privacy-based computation-based cross-organizational data security exchange method described in the above embodiment.

[0056] The memory 720 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 720 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 720 may further include memory remotely located relative to the processor 710, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0057] Input device 730 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the electronic device. Output device 740 may include display devices such as a display screen.

[0058] The following explanation uses examples of embodiments of this application in specific application scenarios to further illustrate the embodiments of this application: An internet consumer finance company (Party A) and a commercial bank (Party B) jointly build a personal credit scoring model. Each institution holds customer application behavior data and historical repayment records. The two parties hope to jointly train a logistic regression model to assess the probability of default for new applicants without exchanging original customer information.

[0059] Step S1: Assume that Participant A's local database stores a field for "Number of Applications in the Last 6 Months" for customers, with a reasonable value range of 0 to 50. Participant A's local smart contract reads a customer's application count value from the database, assuming the actual value is 8. The contract first calls the SHA-256 function to hash the value, obtaining a fixed-length hash output. Next, the contract uses the value 8, the lower limit 0, and the upper limit 50 as input parameters to execute the Bulletproofs range proof generation algorithm. This algorithm first performs binary decomposition on the value 8 and the range boundaries 0 and 50, then constructs a series of Pedersen commitments to hide the true value, and finally generates a proof data packet through a series of inner product arguments. Throughout the proof generation process, the original value 8 only exists briefly in the contract's memory and is released immediately after completion, without being written to any logs or persistent storage. Simultaneously, the asset custody contract, pre-called by the coordinating contract, temporarily freezes a certain amount of platform points from Participant A's designated on-chain account and returns a lock certificate containing the frozen amount, timestamp, and contract address. Participant A's local smart contract merges the hash output, range proof data packet, and lock credential into a single data commitment body, which is then sent to the coordination contract. Participant B performs the exact same processing flow on its local data, generating its own data commitment body and submitting it.

[0060] Step S2: After receiving the data commitments submitted by all participants, the coordination contract verifies the range proof of each participant in turn. The verification process requires verifying the proof data packet provided by the verifier against the publicly available interval boundary values, and confirming through a verification algorithm that the original value does indeed fall within the specified interval. Assuming that participant A's range proof verification passes, the coordination contract inserts its submitted hash value as a new leaf node into the global state Merkle tree, calculates the complete path hash sequence from that leaf node upwards to the root of the tree, and returns this path as an index to participant A. If participant B's range proof verification fails, the coordination contract directly calls the fund transfer interface of the asset custody contract to transfer all platform points locked by participant B to participant A's account, and simultaneously excludes participant B from this calculation task.

[0061] Assuming both parties pass verification, the coordination contract initiates a sample alignment process. Participant A fills its set of customer IDs, for example, 360 customer IDs, into a 1024-bit Bloom filter. During filling, each customer ID is mapped using three different hash functions, locating three positions on the bit string and setting them to 1. After all IDs have been processed, Participant A obtains a Bloom string containing several bits set to 1. This Bloom string is then encrypted bit-by-bit using the homomorphic encryption public key pre-distributed by the coordination contract to generate an encrypted Bloom string. Under the Paillier encryption scheme, the ciphertext form corresponding to bit value 0 is the random number raised to the power of n modulo n, and the ciphertext form corresponding to bit value 1 is the generator multiplied by the random number raised to the power of n modulo n. Participant B performs the same Bloom string construction and encryption operations.

[0062] After the coordination contract collects the encrypted blobs from both parties, it performs a homomorphic multiplication operation on the two ciphertext values ​​at the same bit position in the two ciphertext strings. In Paillier encryption, the product of two ciphertexts corresponds to the sum of the original text values. However, here, a logical AND function needs to be implemented. Therefore, bit values ​​0 and 1 are pre-mapped to encrypted 0 and 1, so that the product corresponds to the product rather than the sum. This mapping is achieved by keeping bit values ​​0 and 1 unchanged before encryption. After repeating this operation for all bit positions, the coordination contract obtains an encrypted intersection string and broadcasts it back to all participants.

[0063] Step S3: After receiving the encrypted intersection string, participant A decrypts it bit by bit using its locally stored homomorphic encryption private key to obtain the plaintext Bloom intersection string. From this Bloom intersection string, participant A can reverse-engineer the set of customer IDs shared by both parties, for example, obtaining 153 shared IDs. Simultaneously, the coordination contract collects the latest block header information from the current blockchain network, extracts its hash value, concatenates this hash value with the unique identifier of this computation task to form a long string, and finally performs SHA-256 calculation on this string to obtain a 256-bit random challenge number, which is then broadcast to all participants.

[0064] Participant A extracts the corresponding feature matrix rows from its local database based on the 153 shared customer IDs. Assume the current model's weight vector has 8 dimensions, with values ​​representing the weight coefficients of features such as the number of applications in the past 6 months and the number of overdue days in the past 12 months. At the start of this training round, the values ​​of each component of the weight vector are 0.05, 0.12, etc. Participant A uses a random challenge number as a seed to drive a linear congruent random number generator, selecting 30 samples from the 153 samples as the training subset for this round. Subsequently, prediction values ​​are calculated sequentially for these 30 samples: the feature vector of each sample is multiplied by the current weight vector, the result is substituted into the sigmoid function to obtain a probability output between 0 and 1, the probability output is subtracted from the true label of the sample to obtain the error, the error is multiplied by the feature value and accumulated, and finally divided by the number of samples to obtain the local gradient vector for this round. Assume the values ​​of each component of the calculated local gradient vector are 0.003, -0.001, etc. Meanwhile, participant A constructs a proof parameter based on a zero-knowledge proof circuit. This circuit encodes the random challenge number, the hash value of the shared customer ID set, the hash value of the local feature matrix, and the gradient calculation process into an arithmetic circuit, which generates a proof after being trusted. Participant B performs a similar calculation to obtain its own local gradient and the corresponding zero-knowledge proof.

[0065] Step S4: The coordination contract first verifies the zero-knowledge proof submitted by participant A. It performs paired operations on the elliptic curve group using a Fast Fourier Transform (FFT) to confirm the proof's validity, marking its local gradient as valid. If verification fails, the coordination contract immediately triggers the asset custody contract's confiscation interface, transferring all locked points from participant A to the other party. The same verification process is then performed on participant B. After both parties' proofs pass verification, the coordination contract queries the historical verification record table, which records the total number of proofs submitted and passed by each participant in all past rounds. Assuming participant A's historical pass rate is 97% and participant B's is 95%, the coordination contract uses these two ratios as weights to calculate a weighted average of the local gradient vectors of both parties: multiplying each component of participant A's gradient by 0.97 and each component of participant B's gradient by 0.95, summing the two, and then dividing by the sum of the weights (1.92), yields global gradient values ​​of 0.0025, -0.0008, etc. Finally, subtract the product of the learning rate (0.01) and the global gradient from the current weight vector to obtain the updated weight vector, completing the update of the model parameters for this round. The process from step S3 to step S4 is repeated until the model's loss value on the validation set no longer decreases after several consecutive rounds. At this point, the model is considered to have converged, and the joint credit scoring model training is complete.

[0066] In the description of the embodiments of this application, the reference to terms such as "an embodiment," "example," "specific example," etc., means that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the embodiments of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0067] Furthermore, the technical solutions of the various implementation methods in this application can be combined with each other, but only if they are based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the embodiments of this application.

[0068] All features disclosed in the embodiments of this application, or all steps in the disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps. Any feature disclosed in the specification of the embodiments of this application, unless specifically stated otherwise, may be replaced by other equivalent or similar alternative features. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features. Throughout the specification, the same reference numerals indicate the same elements.

[0069] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification of embodiments (including the corresponding claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification of embodiments (including the corresponding claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0070] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of this application, and are not intended to limit them. Although the embodiments of this application have been described in detail with reference to the foregoing specific embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein, and such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the specific embodiments of this application.

Claims

1. A method for secure cross-organizational data exchange based on privacy-preserving computation, characterized in that, include: In response to the joint computation task initiated by the coordination contract, the local smart contract extracts the target field from the local database, calculates the hash value of the target field and generates a range proof, and submits the digital asset corresponding to the range proof to the coordination contract. The coordination contract verifies the interval proof. If the verification fails, the corresponding digital asset is allocated to other local smart contracts. Alternatively, if the verification passes, the hash value is stored in the blockchain network. The coordination contract initiates a set intersection calculation. Each local smart contract constructs a cryptographic Bloom string and returns it. The coordination contract performs a homomorphic logical AND operation on the cryptographic Bloom string, calculates the corresponding cryptographic intersection string, and broadcasts it. The local smart contract decrypts the encrypted intersection string to obtain the corresponding public sample identifier set, coordinates the contract to generate a random challenge number and broadcasts it, and calculates the local gradient based on the public sample identifier, the local feature matrix and the random challenge number, and generates a zero-knowledge proof to verify the local gradient. The coordination contract verifies the zero-knowledge proof. If the verification fails, the digital asset is forfeited. Alternatively, if the verification passes, all local gradients are weighted and aggregated, the model weight parameters are updated, and the gradient submission and aggregation steps are repeated until the model converges, thus completing the secure data exchange.

2. The method for secure cross-organizational data exchange based on privacy computing according to claim 1, characterized in that, The specific method for generating the range proof is as follows: the local smart contract obtains the preset lower limit and upper limit of the normal value range, uses the Bulletproofs protocol to perform range proof calculation on the value of the target field, and generates a zero-knowledge range proof. The zero-knowledge range proof is used to prove that the value of the target field is between the lower limit and the upper limit.

3. The method for secure cross-organizational data exchange based on privacy computing according to claim 1, characterized in that, Specifically, the digital assets are: before initiating the joint computing task, the coordination contract calls a pre-deployed asset custody contract. The asset custody contract freezes a preset number of digital assets from the account address corresponding to the local smart contract according to the asset locking request submitted by the local smart contract, and generates an asset locking certificate. The local smart contract attaches the asset locking certificate to the data commitment package and submits it.

4. The method for secure cross-organizational data exchange based on privacy computing according to claim 1, characterized in that, The storage of the hash value in the blockchain network further includes: the coordination contract uses the hash values ​​submitted by each verified local smart contract as leaf nodes, inserts them into the global state Merkle tree in the order of receipt, and recalculates the Merkle path from the leaf node to the root node. The coordination contract returns the Merkle path as a storage location index to the corresponding local smart contract, so that the local smart contract can prove that its data has been legally recorded by providing the hash value and the Merkle path in the subsequent verification process. The encrypted Bloom string is constructed as follows: the local smart contract selects a bit string of a preset length as the underlying array of the Bloom filter, inputs each sample identifier in the local sample identifier set into multiple preset independent hash functions in sequence, each hash function outputs a mapping position, and sets the bit corresponding to the mapping position to 1; After all sample identifiers have been processed, the local smart contract uses the homomorphic encryption public key distributed by the coordinating contract to encrypt the value of each bit in the bit string, generating an encrypted Bloom string.

5. The method for secure cross-organizational data exchange based on privacy computing according to claim 4, characterized in that, The specific method for distributing the homomorphic encryption public key is as follows: before initiating the joint computing task, the coordination contract calls the trusted execution environment to generate a pair of homomorphic encryption key pairs, including a homomorphic encryption public key and a homomorphic encryption private key. The coordination contract then broadcasts the homomorphic encryption public key to all local smart contracts participating in the joint computing task.

6. The method for secure cross-organizational data exchange based on privacy computing according to claim 1, characterized in that, The execution method of the homomorphic logic AND operation is as follows: the coordination contract receives the encrypted Bloom string returned by all participants, and performs homomorphic multiplication operation on the ciphertext values ​​at the same bit position in the encrypted Bloom string one by one. In the unencrypted state, a bit of 1 corresponds to an encrypted value of 1, and a bit of 0 corresponds to an encrypted value of 0. The result of homomorphic multiplication in the encrypted state is equivalent to the logical AND operation of the original bits. The random challenge number is generated as follows: when the coordination contract initiates the gradient calculation phase, it obtains the latest block hash value in the current blockchain network and concatenates the block hash value with the task identifier of the joint calculation task; the coordination contract performs SHA-256 hash operation on the concatenated string and broadcasts the result as the random challenge number to all local smart contracts participating in the joint calculation task, in order to prevent each local smart contract from pre-calculating or reusing historical gradient values.

7. The method for secure cross-organizational data exchange based on privacy computing according to claim 1, characterized in that, The calculation method of the local gradient further includes: the local smart contract extracts a feature subset corresponding to the public sample identifier set from the local feature matrix based on the public sample identifier set obtained by decryption; The local smart contract obtains the latest weight parameters of the current joint model, uses the random challenge number as the seed of the pseudo-random number generator, randomly samples a portion of the samples in the feature subset, and calculates the local gradient using the stochastic gradient descent method.

8. The method for secure cross-organizational data exchange based on privacy computing according to claim 1, characterized in that, The weighted aggregation further includes: The coordination contract maintains a historical verification record table, which records the number of times each local smart contract's zero-knowledge proofs have passed verification and the total number of verifications in each joint computation task; The coordination contract calculates the historical verification success rate of each local smart contract based on the ratio of the number of successful verifications to the total number of verifications. Using the historical verification success rate as a weighting coefficient, the local gradients submitted by the local smart contracts are weighted and summed to calculate the global gradient. The weight parameters of the joint model are then updated using the global gradient.

9. A cross-organizational data secure exchange system based on privacy computing, used to implement the cross-organizational data secure exchange method based on privacy computing as described in any one of claims 1 to 8, characterized in that, include: The interval proof digital asset generation module responds to the joint computing task initiated by the coordination contract. The local smart contract extracts the target field from the local database, calculates the hash value of the target field and generates an interval proof, and submits the digital asset corresponding to the interval proof to the coordination contract. The encrypted intersection string broadcast module coordinates the contract to verify the interval proof. If the verification fails, the corresponding digital asset is allocated to other local smart contracts. Alternatively, if the verification passes, the hash value is stored in the blockchain network. The coordination contract initiates a set intersection calculation. Each local smart contract constructs an encrypted Bloom string and returns it. The coordination contract performs a homomorphic logical AND operation on the encrypted Bloom string to calculate the corresponding encrypted intersection string and broadcasts it. The local gradient zero-knowledge proof module involves a local smart contract that decrypts the encrypted intersection string to obtain the corresponding public sample identifier set, coordinates the contract to generate a random challenge number and broadcasts it, and calculates the local gradient based on the public sample identifier, the local feature matrix and the random challenge number, and generates a zero-knowledge proof for verifying the local gradient. The model weight parameter update module coordinates the contract to verify the zero-knowledge proof. If the verification fails, it triggers the scrambling of digital assets. Alternatively, if the verification passes, it performs weighted aggregation on all local gradients, updates the model weight parameters, and repeats the above gradient submission and aggregation steps until the model converges, thus completing the secure data exchange.

10. An electronic device, characterized in that, include: The system includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus; the memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1 to 8.

Images