Efficient data synchronization method and device for privacy computing scenario and storage medium

Abstract

The application provides an efficient data synchronization method and device for a privacy computing scene and a storage medium. The method comprises: negotiating and maintaining a hierarchical version vector between a center node and a plurality of computing nodes; constructing a directed acyclic graph of a synchronization task at the center node and distributing it to each computing node; splitting the local data to be synchronized into a plurality of data blocks according to a preset block division strategy in each computing node; sending the second ciphertext to the target computing node in a sliding window manner, and performing homomorphic hash consistency verification based on secure multi-party computation on the ciphertext blocks in the window at the sending end and the receiving end; deducting the corresponding privacy budget according to the synchronization block size and the noise amplitude and recording the synchronization usage; writing the synchronized data block into the data storage of the target computing node and inputting it into the computing module of the privacy computing platform. The application can improve the synchronization efficiency, ensure the version consistency, realize the instant deduction of the privacy budget, and realize the unified measurement of the usage.

Description

Technical Field

[0001] This application relates to the field of data privacy technology, and in particular to an efficient data synchronization method, apparatus and storage medium for privacy computing scenarios. Background Technology

[0002] With the popularization of information technology and the rise of the data factor market, data has become an important factor of production. In the power industry, power generation, transmission, distribution, and user-side equipment continuously generate large-scale, multi-dimensional operational and business data. To unlock the value of data, improve grid dispatch efficiency, and ensure energy security, power companies are gradually adopting privacy-preserving computation (such as secure multi-party computation, federated learning, homomorphic encryption, and differential privacy) to complete cross-entity collaborative analysis without disclosing the original data. At the national level, compliance requirements such as "original data not leaving the domain and data being usable but not visible" have also been successively introduced, further promoting the implementation of privacy-preserving computation technology in power data sharing.

[0003] In privacy-preserving computing scenarios, each participant needs to maintain data sovereignty locally, driving distributed algorithms only through encrypted or minimal information exchange. This model presents new technical requirements for cross-node data synchronization. Existing privacy-preserving computing platforms mostly employ centralized list comparison or full mirror replication to coordinate data versions. Specifically: Some solutions rely on simple file version numbers or timestamps, and for large files or rapidly growing data, they can only transmit the entire batch, resulting in high network bandwidth consumption and high retransmission costs. Another type of solution introduces the concept of differential synchronization, but does not jointly manage the privacy budget, and still needs to maintain budget consumption in an additional system, causing business process fragmentation. In terms of consistency verification, the common practice is to directly roll back the entire batch of data after comparing the digest value, lacking a fine-grained difference block repair mechanism, so the recovery time is long and the computing nodes are prone to blockage. Usage records are mostly statistically analyzed by the log system after the fact, lacking an atomic billing method that is linked to the synchronization process in real time, making it difficult to guarantee the accuracy and non-repudiation of metering.

[0004] Therefore, existing technologies still suffer from problems such as low synchronization efficiency, inconsistent versions, separation of privacy budgets, and inconsistent usage measurement in the data synchronization stage of privacy computing scenarios. Summary of the Invention

[0005] In view of this, embodiments of this application provide an efficient data synchronization method, apparatus and storage medium for privacy computing scenarios, in order to solve the problems of low synchronization efficiency, inconsistent versions, separation of privacy budgets and inconsistent usage measurement in the data synchronization process of the prior art.

[0006] A first aspect of this application provides an efficient data synchronization method for privacy-preserving computing scenarios, comprising: negotiating and maintaining a hierarchical version vector between a central node and multiple computing nodes; determining a set of data blocks to be synchronized based on the hierarchical version vector, constructing a corresponding directed acyclic graph of synchronization tasks at the central node and distributing it to each computing node; splitting the local data to be synchronized into several data blocks according to a preset block partitioning strategy at each computing node, encrypting each data block to obtain a first ciphertext, injecting differential privacy noise into the first ciphertext to obtain a second ciphertext, and writing the second ciphertext into a sending queue; sending the second ciphertext block by block to the target computing node in a sliding window manner, and performing homomorphic hash consistency verification based on secure multi-party computation on the ciphertext blocks in the window at the sending end and the receiving end, marking the corresponding data block and triggering the retransmission of the differential block when the verification is inconsistent; updating the hierarchical version vector stored at the central node after the consistency verification is passed, calling the data management module to deduct the corresponding privacy budget according to the synchronization block size and noise amplitude and recording the synchronization usage; writing the synchronized data blocks into the data storage of the target computing node and inputting them into the computing module of the privacy computing platform to perform subsequent secure multi-party computation or federated learning tasks.

[0007] A second aspect of this application provides an efficient data synchronization device for privacy-preserving computing scenarios, comprising: a negotiation module for negotiating and maintaining a hierarchical version vector between a central node and multiple computing nodes; a construction module for determining a set of data blocks to be synchronized based on the hierarchical version vector, constructing a corresponding directed acyclic graph of synchronization tasks at the central node, and distributing it to each computing node; and an encryption module for splitting the local data to be synchronized into several data blocks according to a preset block partitioning strategy at each computing node, encrypting each data block to obtain a first ciphertext, injecting differential privacy noise into the first ciphertext to obtain a second ciphertext, and writing the second ciphertext into a sending queue; and a verification module. The verification module is used to send the second ciphertext to the target computing node block by block in a sliding window manner. The sending and receiving ends perform homomorphic hash consistency verification based on secure multi-party computation on the ciphertext blocks in the window. If the verification is inconsistent, the corresponding data block is marked and the difference block is retransmitted. The update module is used to update the hierarchical version vector stored in the central node after the consistency verification is passed. It calls the data management module to deduct the corresponding privacy budget according to the synchronization block size and noise amplitude and record the synchronization usage. The write module is used to write the synchronized data block to the data storage of the target computing node and input it to the computing module of the privacy computing platform to perform subsequent secure multi-party computation or federated learning tasks.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The process involves negotiating and maintaining a hierarchical version vector between a central node and multiple computing nodes. Based on this vector, a set of data blocks to be synchronized is determined. A corresponding directed acyclic graph (DAG) for synchronization tasks is constructed at the central node and distributed to each computing node. At each computing node, the local data to be synchronized is divided into several blocks according to a preset block partitioning strategy. Each data block is encrypted to obtain a first ciphertext. Differential privacy noise is injected into the first ciphertext to obtain a second ciphertext, which is then written into a sending queue. The second ciphertext is sent to the target computing node block by block using a sliding window approach. At both the sending and receiving ends, a homomorphic hash consistency check based on secure multi-party computation is performed on the ciphertext blocks within the window. If the check is inconsistent, the corresponding data block is marked, and a difference block retransmission is triggered. After the consistency check passes, the hierarchical version vector stored at the central node is updated. The data management module is then called to deduct the corresponding privacy budget based on the synchronization block size and noise amplitude, and the synchronization usage is recorded. The synchronized data blocks are written to the data storage of the target computing node and input into the computing module of the privacy computing platform to execute subsequent secure multi-party computation or federated learning tasks. This application can improve synchronization efficiency, ensure version consistency, enable instant deduction of privacy budget, and achieve unified usage measurement. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating an efficient data synchronization method for privacy-preserving computing scenarios provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of the efficient data synchronization device for privacy computing scenarios provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] Existing technologies typically perform full mirroring or coarse-grained incremental synchronization of distributed encrypted data using file version numbers or timestamps, and distribute privacy budget metering, usage billing, and consistency verification across independent modules. This results in high network bandwidth consumption, large synchronization latency, and the need for a complete rollback if verification fails. At the same time, budget consumption and billing information cannot be deducted in real time during the synchronization process, making it difficult to balance version consistency and metering auditing.

[0015] To address the aforementioned shortcomings, this application focuses on the technical problem of how to simultaneously improve the efficiency of encrypted data synchronization, ensure data version consistency across multiple nodes, and achieve real-time deduction of privacy budget and unified measurement of usage during the synchronization process in privacy computing scenarios.

[0016] To address this issue, this application proposes an efficient data synchronization method for privacy-preserving computing scenarios. The core technical solution of this application includes: 1. Negotiate and maintain a hierarchical version vector containing metadata version number, block-level version number, and remaining privacy budget value between the central node and the computing nodes; 2. Generate a version difference mapping table based on hierarchical version vectors, construct a directed acyclic graph of synchronous tasks in the central node in the order of initialization node, data block transmission node, merge node and commit node, and distribute it to the corresponding computing nodes. 3. Each computing node uses a dual-threshold block partitioning strategy to subdivide the local data to be synchronized into hot zones. After encrypting each data block and injecting differential privacy noise, it uses a sliding window pipeline for transmission. 4. The sending and receiving ends perform homomorphic hash consistency checks on the ciphertext blocks within the window based on secure multi-party computation. If there is a discrepancy, only the difference block is retransmitted. 5. After consistency is achieved, the central node atomically deducts the privacy budget from the hierarchical version vector and writes the synchronization usage record to the immutable log chain.

[0017] By implementing the technical solution of this application, the technical effects of improving the synchronization efficiency of encrypted data, ensuring data version consistency across multiple nodes, enabling real-time deduction of privacy budget, and achieving unified measurement and traceable auditing of usage can be achieved.

[0018] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0019] Figure 1 This is a flowchart illustrating an efficient data synchronization method for privacy-preserving computing scenarios provided in an embodiment of this application. Figure 1 As shown, this efficient data synchronization method for privacy-preserving computing scenarios may specifically include: S101 negotiates and maintains a hierarchical version vector between the central node and multiple computing nodes; S102, determine the set of data blocks to be synchronized based on the hierarchical version vector, construct the corresponding directed acyclic graph of synchronization tasks at the central node and distribute it to each computing node; S103, in each computing node, the local data to be synchronized is divided into several data blocks according to the preset block partitioning strategy, each data block is encrypted to obtain the first ciphertext, the first ciphertext is injected with differential privacy noise to obtain the second ciphertext, and the second ciphertext is written into the sending queue. S104, the second ciphertext is sent to the target computing node block by block in a sliding window manner, and the sending end and the receiving end perform homomorphic hash consistency verification based on secure multi-party computation on the ciphertext blocks in the window. If the verification is inconsistent, the corresponding data block is marked and the difference block is retransmitted. S105: After the consistency check passes, update the hierarchical version vector saved by the central node, call the data management module to deduct the corresponding privacy budget according to the synchronization block size and noise amplitude, and record the synchronization usage. S106, the synchronized data block is written to the data storage of the target computing node and input to the computing module of the privacy computing platform to perform subsequent multi-party secure computing or federated learning tasks.

[0020] In some embodiments, negotiating and maintaining a hierarchical version vector between the central node and multiple computing nodes includes: The compute nodes are used to generate a hierarchical version vector containing a metadata version number, a block-level data version number, and a remaining privacy budget value, and then digitally signed with the node's private key. The hierarchical version vector with digital signature is sent to the central node via a secure channel with two-way authentication. The central node verifies the digital signature and uses a hash comparison algorithm to fuse the hierarchical version vectors from each computing node to form a global hierarchical version vector, while generating a version difference mapping table. The central node issues version synchronization instructions to the relevant computing nodes based on the version difference mapping table, and updates the stored global hierarchical version vector after receiving confirmation of synchronization completion.

[0021] Specifically, the metadata version number refers to the hash identifier Hschema obtained by calculating the hash value of the current data table structure (Schema), which is used to identify whether the data structure has changed.

[0022] The block-level data version number refers to the cumulative hash of all local data blocks on the node according to the block sequence number and the block content hash value Hblock, forming a unified block-level version identifier Hblocksum, which is used to reflect changes in data content.

[0023] The remaining privacy budget value refers to the remaining available privacy budget εremain for the record node under the current differential privacy budget system, and the unit is consistent with the platform's global budget.

[0024] By concatenating the above three items in order, a hierarchical version vector of triples consisting of "metadata version number - block-level data version number - remaining privacy budget value" is formed.

[0025] Furthermore, each computing node calls the encryption engine module to load the node's private key SKnode, first performing a secure hash algorithm SHA-256 on the hierarchical version vector of the triplet, and then using the asymmetric encryption algorithm RSA2048 to digitally sign it, obtaining the signature Signode. The hierarchical version vector and Signode are combined to form the version message VersionPacketnode.

[0026] The compute nodes establish a bidirectional authenticated connection with the central node using the Transport Layer Security (TLS) 1.3 protocol through the communication management module. Once established, the compute node pushes the VersionPacketnode along with the current timestamp (TimeStampnode) and a random number (Nonce) to the central node to ensure message confidentiality and prevent replay attacks.

[0027] In some examples, the central node verification and fusion in this embodiment may include the following operations: Signature verification: The central node uses the node's public key PKnode to verify the Signode and confirm that the version message origin is legitimate.

[0028] Hash comparison fusion: The central node uses a hash comparison algorithm to compare the version number of each node's metadata with the global metadata version number to generate a pattern difference marker; it compares the version number of each node's block-level data with the global block-level data version number to generate a difference block bitmap; and it reads and summarizes the remaining privacy budget values ​​of each node to form a global budget list.

[0029] Global hierarchical version vector and difference mapping table: The comparison results are integrated to form a global hierarchical version vector GlobalVector; at the same time, a version difference mapping table VersionDiffMap is output to indicate the data block sequence number and budget difference that each node needs to synchronize.

[0030] Furthermore, the central node issues a version synchronization command, VersionSyncCmd, through the established TLS 1.3 secure channel. This command includes a list of differing blocks, the synchronization window size (WinSize), and the maximum number of retries (RetryMax). After completing synchronization, the compute nodes return a synchronization confirmation message, SyncAck. Based on this, the central node updates the block-level version number and remaining privacy budget value in GlobalVector, achieving closed-loop version maintenance.

[0031] For example, in a specific example, let's illustrate the typical operation of the above process using nodes A and B: The hierarchical version vector generated by node A is: MetaVer=3F4A21B6 BlockVer=9C8D12E3 εremain=2.35 Node A uses its private key SKA to sign SignA using RSA2048 and then sends VersionPacketA to the central node.

[0032] The comparison of the central nodes revealed that node A was missing blocks 37 and 42, and εremain was higher than the average value of 0.05. Therefore, {node A: missing blocks 37 and 42} was recorded in VersionDiffMap.

[0033] The central node sends VersionSyncCmd{37,42,WinSize=16,RetryMax=3} to node A. After node A completes the data block retransmission, it returns SyncAck and decrements εremain to 2.30.

[0034] After receiving SyncAck, the central node updates the block-level version number of node A in GlobalVector and εremain=2.30, and writes the operation log to an immutable log chain to leave traces for subsequent auditing.

[0035] Through the above embodiments, it can be seen that this technical solution achieves fast, reliable and budget-integrated data version negotiation and maintenance among multiple nodes without exposing the original data, providing an accurate and consistent foundation for subsequent encrypted data synchronization and differential privacy budget management.

[0036] In some embodiments, the set of data blocks to be synchronized is determined based on a hierarchical version vector, and a corresponding directed acyclic graph of synchronization tasks is constructed at the central node and distributed to each computing node, including: The central node generates a list of data block indexes to be synchronized for each compute node based on the version difference mapping table. The list of data block indices to be synchronized is mapped to a directed acyclic graph arranged in the order of initialization node, data block transfer node, merge node, and commit node, where each data block transfer node carries a priority label, retry threshold, and window size parameter. The constructed directed acyclic graph is sent to the corresponding computing node via an authenticated communication channel for subsequent synchronization task scheduling and execution.

[0037] Specifically, this embodiment will elaborate on the implementation of the technical solution of "determining the set of data blocks to be synchronized based on hierarchical version vectors, constructing a corresponding directed acyclic graph of synchronization tasks at the central node, and distributing it to each computing node", which may include the following: The central node holds a version difference mapping table, VersionDiffMap, whose entries are in the form of <node identifier, set of difference block numbers>. The central node scheduling module traverses VersionDiffMap, extracts the set of difference block numbers for each compute node, sorts them in ascending order of block number, and encapsulates them into a data block index list, IndexListnode. List elements contain the block number BlockID, the target hash value Htarget, and the estimated block size Size.

[0038] In some examples, the node type mapping of a directed acyclic graph includes the following: Initialize node InitNode: Used for node-side task environment preparation and handshake confirmation.

[0039] TransNode: Corresponds to a single or group of block numbers in the IndexListnode; each TransNode carries three parameters: PriorityTag is calculated based on block size and access frequency. The retry threshold, RetryThresh, is dynamically set by the central node based on network reliability statistics. Window size (WindowSize) is adaptively allocated based on historical round-trip latency and maximum bandwidth.

[0040] MergeNode: Triggered after all TransNodes have successfully completed the process, it is responsible for integrating the verification results and temporary cache.

[0041] CommitNode: Completes the final version writing and synchronization status reporting.

[0042] Mapping rules: The central node constructs a linear topology for each node, consisting of InitNode → several TransNodes → MergeNode → CommitNode, and forms a directed acyclic graph (DAGnode) using pointing relationships.

[0043] Furthermore, the completed DAGnode is used by the central node management module to call the encryption engine module to generate a digital signature, which is then pushed to the corresponding computing node by the communication management module through the established TLS 1.3 two-way authentication tunnel. The DAGnode uses a self-describing JSON format for serialization, with a fixed field order, which facilitates parsing and error recovery on the node side.

[0044] For example, in a specific example, taking node A as an example, the version difference mapping table gives node A missing block 37 and block 42.

[0045] The generated list of data block indexes is as follows: IndexListA: [<BlockID37,Htarget37,Size4MB>,<BlockID42,Htarget42,Size4MB>]. Block 37 is determined to be a high-frequency access block, so its PriorityTag is set to High, and block 42 is set to Normal.

[0046] The directed acyclic graph is constructed as follows: InitNodeA: Priority label Default, RetryThresh3, WindowSize16.

[0047] TransNodeA-1 (Block 37): PriorityTagHigh, RetryThresh3, WindowSize16.

[0048] TransNodeA-2 (Block 42): PriorityTagNormal, RetryThresh3, WindowSize16.

[0049] MergeNodeA: No additional parameters.

[0050] CommitNodeA: No additional parameters.

[0051] Topological relationship: InitNodeA→TransNodeA-1→TransNodeA-2→MergeNodeA→CommitNodeA.

[0052] Furthermore, after the central node signs the DAGA, it sends it to node A via a TLS 1.3 tunnel. Upon receiving it, node A first executes InitNodeA to complete the handshake, and then initiates block transmission of TransNodeA-1 and TransNodeA-2 in priority order. When both nodes return success status codes, MergeNodeA integrates the verification results, and finally CommitNodeA writes the new block and reports SyncAck. The central node updates the global hierarchical version vector accordingly.

[0053] As can be seen from the above embodiments, this technical solution can automatically generate a directed acyclic graph of synchronization tasks carrying priority, retry threshold and window size at the central node, and securely distribute it to the computing nodes, thereby achieving efficient and controllable transmission of difference blocks and version consistency maintenance.

[0054] In some embodiments, the local data to be synchronized is divided into several data blocks in each computing node according to a preset block partitioning strategy, including: Set a first block size threshold for the local data to be synchronized, and perform initial equal-length division according to the first block size threshold; The hot zone identification algorithm based on access frequency metric is executed on the data blocks obtained by the initial equal-length division. If a hot zone segment is detected, the second block size threshold is applied to the hot zone segment for adaptive subdivision. Generate a block number, starting offset, length, and hash check value for the final data block, and write the block number and hash check value into the index list of data blocks to be synchronized.

[0055] Specifically, in this embodiment, the computing node performs multi-level block partitioning on the local data to be synchronized, so as to facilitate subsequent differentiated transmission and fine-grained consistency verification. The specific implementation of this embodiment is as follows: First, the first block size threshold is set: the computing node presets the first block size threshold Size1 based on the network bandwidth and average round-trip latency, for example, 4MB; then, the local data to be synchronized is continuously divided into equal-length blocks according to Size1 starting from the file's starting offset to form an initial sequence of equal-length data blocks.

[0056] Furthermore, the hotspot identification algorithm includes: during runtime, the computing node continuously counts the access frequency (Counter) of each data block, and calculates the block's heat score (HotScore = Counter / WindowSize) using a sliding time window. When the HotScore exceeds a set threshold (HotThresh), the data block is marked as a hotspot segment. Consecutive hotspot segments are merged by interval to obtain a hotspot interval table.

[0057] Furthermore, the second block size threshold adaptive subdivision includes: for each hot zone segment, the computing node selects a second block size threshold Size2 smaller than Size1, for example, 1MB, and further subdivides the hot zone segment according to Size2 to refine the block granularity, thereby reducing the retransmission cost in high-frequency areas. The non-hot zone portion retains the original Size1 granularity.

[0058] Furthermore, the generation of data block metadata includes: for all final data blocks obtained from the initial equal-length partitioning and hot zone subdivision, the following are generated sequentially: Block ID (incrementing in file offset order), starting offset, length, and hash checksum Hblock (calculating the hash value H). Then, the Block ID and Hblock are written to the IndexListnode of the data blocks to be synchronized, for the central node to generate a synchronization plan.

[0059] In a specific example, taking compute node A holding 1GB of local data to be synchronized as an example, the above block partitioning process is demonstrated: Node A is set to Size1 = 4MB, and the 1GB file is divided into 256 data blocks of equal length, with the block number ranging from 0 to 255.

[0060] After running for one hour, access statistics showed that the read and write frequency of the 120MB-180MB offset region was significantly higher than that of other regions. Node A calculated the HotScore within this time window and found that data blocks 30-44 (corresponding to offsets of 120MB-176MB) all exceeded the HotThresh threshold, and were therefore identified as continuous hot segments.

[0061] Node A subdivides the hot zone segments using Size2 = 1MB. The original equal-length blocks 30-44 are split into 120 fine-grained blocks, with the new block number range from 256 to 375. Non-hot zone data blocks retain their 4MB granularity.

[0062] For all 376 final data blocks, node A calculates the hash value Hblock, for example, the hash value of block number 256 is H256=8d15f2e3…; then it writes it to IndexListA in the format “BlockID,Hblock”. IndexListA is sent to the central node in the next version negotiation to generate the difference mapping table and synchronization tasks.

[0063] Through the above embodiments, the computing nodes maintain overall consistency while performing fine-grained partitioning of high-frequency access areas, which improves the efficiency of subsequent differential block retransmission and consistency verification, laying a data granular foundation for efficient data synchronization.

[0064] In some embodiments, each data block is encrypted to obtain a first ciphertext, differential privacy noise is injected into the first ciphertext to obtain a second ciphertext, and the second ciphertext is written into a sending queue, including: Obtain the public key and encryption parameters assigned by the encryption engine module on the computing node; Lightweight homomorphic encryption is performed on the data block using the public key to obtain the first ciphertext; The secure random number generator is invoked to sample noise values ​​from a Laplace or Gaussian distribution according to a preset privacy budget, and the noise values ​​are homomorphically encrypted using a public key to obtain encrypted noise. Perform homomorphic addition on the first ciphertext and the encryption noise to generate the second ciphertext, and write the second ciphertext and the corresponding data block sequence number into the sending queue.

[0065] Specifically, in this embodiment, taking the synchronization process of processing block number 256 of computing node A as an example, the technical details of "encryption - injection of differential privacy noise - writing to the transmission queue" are further fully disclosed. The entire process is divided into six stages in sequence: key acquisition, plaintext encoding and homomorphic encryption, noise sampling and encryption, homomorphic fusion, transmission queuing and budget deduction. Each stage is completed locally on node A without the participation of a central node.

[0066] First, during the synchronization task initialization, node A retrieves the public key PK_A and a set of lightweight homomorphic encryption parameters through the encryption engine module's "key distribution interface": Modulus: A prime number of 256 bits used to limit the range of values ​​that can be taken in the ciphertext; Plaintext modulus: The value ranges from 2 to the power of 32, and is used to carry the encoded integer plaintext; Polynomial order: 4096, used to control the number of slots for the plaintext vector.

[0067] The key and parameters are transmitted to node A in binary file form via a TLS secure channel and stored in read-only memory to prevent them from being overwritten at runtime. Node A simultaneously loads the homomorphic encryption library and completes context initialization based on the aforementioned parameters.

[0068] Furthermore, the original data block 256 is 4MB in size and consists of binary log fragments. Node A first calls the "segment encoder" to divide the data block into several four-byte integer elements and fill them into slots in the polynomial vector; any insufficient parts are padded with zeros to ensure that the vector length is consistent with the polynomial order. After encoding, the plaintext vector PlainData_256 is obtained.

[0069] Node A then calls the Encrypt(PK_A, PlainData_256) interface to perform a single homomorphic encryption operation, obtaining the first ciphertext C1_256 and temporarily storing it in the "ciphertext buffer". The ciphertext buffer retains only the depth required for two rounds of encryption by default to reduce memory usage.

[0070] Furthermore, node A maintains a "budget register" that records the real value of the remaining privacy budget ε_remain. Before this synchronization, ε_remain was read as 2.30.

[0071] According to the platform policy document, node A uses the Laplace mechanism: The "budget calculation unit" is invoked to perform a ratio calculation between the data sensitivity and ε_remain, thereby obtaining the noise amplitude λ; The SecureRNG random number generator is invoked to sample floating-point noise Noise_256 from the Laplace distribution with an amplitude λ. Using the same vector encoder as the data block, Noise_256 is filled into the polynomial slot to generate the plaintext vector PlainNoise_256; Calling Encrypt(PK_A, PlainNoise_256) yields the encrypted noise Cnoise_256.

[0072] SecureRNG uses hardware random entropy as a seed and writes a security audit log for each sample, recording the timestamp and noise distribution type for subsequent compliance checks.

[0073] Furthermore, node A calls Add(C1_256, Cnoise_256) to perform homomorphic addition within the ciphertext field, obtaining the second ciphertext C2_256. The addition operation does not increase the ciphertext multiplication depth, therefore C2_256 can be securely decoded within the current parameter range. After completing the addition, node A immediately deducts the noise consumption of 0.05 from the budget register and appends the remaining budget value ε_remain=2.25 to the operation log.

[0074] Furthermore, node A creates a send entry for the data block: Block number: 256 Ciphertext: C2_256 (binary) Ciphertext length: approximately 5 MB, containing necessary homomorphic metadata. Timestamp: Current system time The entry is written to the circular buffer SendQueue via the local "Send Queue Manager". SendQueue is read by a separate network thread and sent in batches of 16, according to the sliding window size. After each batch is sent, the network thread waits for the receiver to return a window confirmation before requesting the next batch from the queue, ensuring that the block sequence number order is consistent with the receiving order.

[0075] Furthermore, to ensure the concurrency safety of the computation thread (generating ciphertext) and the network thread (sending ciphertext), the sending queue adopts a lock-free circular buffer + single producer single consumer model, and uses memory barriers to ensure the visibility of the write order. When the network thread experiences backpressure due to bandwidth limitations, the queue manager will create a temporary file on the local disk and serialize and write the ciphertext that has not yet been sent to prevent memory overflow. Once the bandwidth is restored, it will be read back.

[0076] Through the above six stages, node A completed homomorphic encryption, differential privacy noise injection, budget deduction, and secure transmission queuing for data block 256. The entire process fully utilizes hardware random sources, lightweight homomorphic encryption algorithms, and concurrently secure transmission queues, providing a feasible and auditable implementation method for the platform to achieve high throughput and low latency data synchronization under the premise of "original data not leaving the domain".

[0077] In some embodiments, the sending and receiving ends perform homomorphic hash consistency checks on the ciphertext blocks within the window, based on secure multi-party computation. If the checks are inconsistent, the corresponding data block is marked and a retransmission of the difference block is triggered, including: At both the sending and receiving ends, the same homomorphic hash function is invoked for the second ciphertext within the current sliding window, and a shared hash random salt is introduced to generate the corresponding window hash digest. Each generated window hash digest is divided into multiple hash shares through a secret sharing method. The sender and receiver jointly participate in a secure multi-party computation protocol to compare the hash shares to obtain a consistency identifier. If the consistency flag indicates that the hashes are inconsistent, the corresponding data block sequence number is recorded at the sending end and added to the difference block retransmission queue. At the receiving end, the corresponding data block is discarded and a retransmission request is sent. After the difference block is retransmitted, the homomorphic hash consistency check is re-executed until all ciphertext blocks in the window pass the check.

[0078] Specifically, this embodiment describes the entire process of performing homomorphic hash consistency verification based on secure multi-party computation and retransmission of differential blocks on ciphertext blocks within a sliding window between node A (sender) and node B (receiver). Assume the current window size is 16 blocks, corresponding to block numbers from BlockID256 to BlockID271, and the second ciphertext has arrived in the receive buffer of node B in sequence.

[0079] Node A and Node B pre-agree on the same homomorphic hash function H_hom and share the same random salt Salt20250526.

[0080] Sending node A reads the second ciphertext C2_256…C2_271 in the window sequentially, concatenates each ciphertext with Salt20250526, calls H_hom to calculate the single-block hash value, then concatenates all single-block hash values ​​in ascending order of block number and calls H_hom again to generate the window total hash digest WindowDigestA.

[0081] The receiving node B generates the WindowDigestB using the exact same steps and order, ensuring that the input, salt, and order are completely consistent.

[0082] Furthermore, node A and node B perform (5,3) threshold secret sharing on their respective WindowDigestA and WindowDigestB, dividing each digest into 5 hash shares.

[0083] Both parties send their respective three different hash shares to the third-party MPC executor through the established TLS tunnel, and keep two copies locally.

[0084] The MPC executor calls the "equal value comparison protocol" to perform a bit-level comparison of the corresponding shares from node A and node B, and outputs the consistency flag Flag_Compare: if all shares are equal, output 1, otherwise output 0.

[0085] Flag_Compare is returned to nodes A and B immediately after generation, and the third-party executor does not expose any intermediate data.

[0086] Furthermore, if Flag_Compare=0, node A considers the window digests inconsistent. To locate the erroneous block, node A recalculates the hash value of each block and compares it quickly with node B via point-to-point MPC, revealing a difference in BlockID263.

[0087] Node A immediately adds BlockID263 to its local DiffResendQueue and writes the retransmission flag to the send control block; Node B simultaneously discards C2_263 and generates a ResendRequest263 receipt.

[0088] After receiving ResendRequest263, the network thread schedules C2_263 to be resent from DiffResendQueue, increases the transmission priority of this block, and sets RetryCounter1 to track whether it fails again.

[0089] Furthermore, once BlockID263 arrives at node B again and completes its entry into the cache, both nodes re-execute the previous steps. At this point, Flag_Compare=1, indicating that all blocks are consistent. Node B immediately sends a window confirmation ACK_271 back to the central node, and both nodes A and B simultaneously slide their windows forward, with the new window covering BlockID272 to BlockID287.

[0090] If inconsistencies reappear in subsequent windows, repeat the above process until all windows pass the consistency check.

[0091] Furthermore, during the retransmission of differential blocks, the sending thread of node A pauses the forward sliding window, but can still send new blocks in other queues in parallel to avoid bandwidth idleness. If RetryCounter fails to pass the verification even after reaching the preset threshold of 3, node A will trigger task degradation logic, temporarily reduce the window size to 8 rows, and report event IDHashFail263 to the monitoring module to facilitate troubleshooting by operations and maintenance personnel.

[0092] Through the above process, node A and node B achieve window-level consistency verification based on homomorphic hashing and secure multi-party computation without exposing plaintext content. Once a difference is detected, it can be located precisely down to a single block and quickly retransmitted, ensuring the integrity and reliability of the entire data synchronization link.

[0093] In some embodiments, after the consistency check passes, the hierarchical version vector stored by the central node is updated, and the data management module is invoked to deduct the corresponding privacy budget based on the synchronization block size and noise amplitude, and the synchronization usage is recorded, including: The central node receives the synchronization confirmation message returned by the target computing node. The synchronization confirmation message includes the data block sequence number, block size and corresponding noise amplitude. The privacy budget consumption is calculated based on the block size and noise amplitude, and the privacy budget consumption is atomically deducted from the privacy budget value field of the hierarchical version vector. Generate a synchronization usage record that carries the node identifier, data block sequence number, block size, noise amplitude, and the remaining privacy budget value after deduction. Call the data management module to write the synchronization usage record to an immutable log chain.

[0094] Specifically, the synchronization confirmation message parsing process begins with the central node receiving the SyncAck message from the compute nodes via a communication listening thread. The SyncAck message contains four fields: NodeID, BlockID, Size, and Noise. The digital signature is verified before parsing to ensure the message's integrity and reliability.

[0095] The privacy budget reduction model includes: the central node maintaining a remaining privacy budget field εremain for each node in the hierarchical version vector GlobalVector. The budget reduction strategy calculates the cost BudgetCost based on "block size × noise amplitude". The reduction operation uses Compare-and-Swap (CAS) instructions to achieve atomic writes, avoiding concurrent modification conflicts.

[0096] The usage record structure includes: The synchronized usage record UsageRecord contains six items: NodeID, BlockID, Size, Noise, BudgetLeft, and Timestamp. Before writing a record, a single log hash EntryHash is calculated for subsequent chained integrity verification.

[0097] The immutable log chain writing process includes: the data management module maintaining a time-incrementing log chain. The writing process is as follows: ① serialize the UsageRecord; ② calculate the EntryHash; ③ concatenate it with the PrevHash and calculate the new MerkleRoot; ④ atomically update the tail pointer. The entire chain only retains the hash digest, which saves storage and ensures tamper-proof protection.

[0098] The event push and billing interface includes: after the budget is successfully deducted, the central node asynchronously pushes the event to the monitoring module and delivers the UsageRecord to the billing subsystem to provide raw data for subsequent bill generation.

[0099] For example, in a specific example, let's take the case where node A sends block sequence number 256, block size 4MB, and noise amplitude 0.12 to illustrate the processing procedure of the central node.

[0100] The central node receives a SyncAck message: NodeID:A, BlockID:256, Size:4MB, Noise:0.12. After successful signature verification, the fields are written to the inbound cache, triggering the budget deduction task.

[0101] Based on the strategy function BudgetCost=Size×Noise, BudgetCost is calculated to be 4×0.12=0.48. This function is specified in the central node configuration file and can be adjusted according to business needs.

[0102] In the GlobalVector, the current εremain value of node A is recorded as 2.25. The central node performs a CAS operation: if εremain is still 2.25, a new value of 1.77 is written; if it has been modified by other threads, the operation is retried until the deduction is successful.

[0103] After successful deduction, construct a UsageRecord: NodeID:A;BlockID:256;Size:4MB;Noise:0.12;BudgetLeft:1.77;Timestamp:20250526T112530Z.

[0104] Call the hash function to calculate EntryHash, and generate a new MerkleRoot by combining it with the hash PrevHash of the previous log entry.

[0105] The data management module writes the UsageRecord and EntryHash to the disk persistent area and updates the tail pointer. After successful writing, the central node pushes the event ID BudgetOK256 to the monitoring module and asynchronously sends the UsageRecord to the billing system.

[0106] Through the detailed steps described above, the central node completed the closed-loop operation of privacy budget deduction and synchronization usage recording while ensuring thread safety and data integrity, laying a reliable foundation for the platform's compliance audit and accurate billing.

[0107] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0108] Figure 2 This is a schematic diagram of the structure of an efficient data synchronization device for privacy computing scenarios provided in an embodiment of this application. Figure 2 As shown, this efficient data synchronization device for privacy computing scenarios includes: Negotiation module 201 is used to negotiate and maintain hierarchical version vectors between the central node and multiple computing nodes; Module 202 is used to determine the set of data blocks to be synchronized based on the hierarchical version vector, construct the corresponding directed acyclic graph of synchronization tasks at the central node and distribute it to each computing node; The encryption module 203 is used to split the local data to be synchronized into several data blocks in each computing node according to a preset block partitioning strategy, encrypt each data block to obtain the first ciphertext, inject differential privacy noise into the first ciphertext to obtain the second ciphertext, and write the second ciphertext into the sending queue. The verification module 204 is used to send the second ciphertext to the target computing node block by block in a sliding window manner, and to perform homomorphic hash consistency verification based on secure multi-party computation on the ciphertext blocks in the window at the sending end and the receiving end. If the verification is inconsistent, the corresponding data block is marked and the difference block is retransmitted. Update module 205 is used to update the hierarchical version vector saved by the central node after the consistency check passes, and call the data management module to deduct the corresponding privacy budget according to the synchronization block size and noise amplitude and record the synchronization usage. The writing module 206 is used to write the synchronized data block to the data storage of the target computing node and input it to the computing module of the privacy computing platform to perform subsequent multi-party secure computing or federated learning tasks.

[0109] In some embodiments, Figure 2 The negotiation module 201 uses computing nodes to generate a hierarchical version vector containing a triplet containing a metadata version number, a block-level data version number, and a remaining privacy budget value, and digitally signs it with the node's private key; the digitally signed hierarchical version vector is sent to the central node through a secure channel with two-way authentication; the central node verifies the digital signature and uses a hash comparison algorithm to fuse the hierarchical version vectors from each computing node to form a global hierarchical version vector, and at the same time generates a version difference mapping table; the central node issues version synchronization instructions to relevant computing nodes according to the version difference mapping table, and updates the stored global hierarchical version vector after receiving confirmation of synchronization completion.

[0110] In some embodiments, Figure 2 The construction module 202 uses the central node to generate a list of data block indexes to be synchronized for each computing node based on the version difference mapping table; the list of data block indexes to be synchronized is mapped into a directed acyclic graph arranged in the order of initialization node, data block transmission node, merging node and commit node, where each data block transmission node carries a priority label, retry threshold and window size parameters; the constructed directed acyclic graph is sent to the corresponding computing node through the authentication communication channel for subsequent synchronization task scheduling and execution.

[0111] In some embodiments, Figure 2 The encryption module 203 sets a first block size threshold for the local data to be synchronized and performs initial equal-length division according to the first block size threshold; it executes a hot zone identification algorithm based on access frequency metric on the data blocks obtained by the initial equal-length division; if a hot zone segment is detected, it applies a second block size threshold for adaptive subdivision within the hot zone segment; it generates a block number, starting offset, length and hash check value for the final data block, and writes the block number and hash check value into the data block index list to be synchronized.

[0112] In some embodiments, Figure 2 The encryption module 203 obtains the public key and encryption parameters allocated by the encryption engine module at the computing node; performs a lightweight homomorphic encryption operation on the data block based on the public key to obtain the first ciphertext; calls the secure random number generator to sample noise values ​​from the Laplace distribution or Gaussian distribution according to the preset privacy budget, and uses the public key to homomorphically encrypt the noise values ​​to obtain encrypted noise; performs homomorphic addition on the first ciphertext and the encrypted noise to generate the second ciphertext, and writes the second ciphertext and the corresponding data block sequence number into the sending queue.

[0113] In some embodiments, Figure 2 The verification module 204, at both the sending and receiving ends, calls the same homomorphic hash function and introduces a shared hash random salt for the second ciphertext within the current sliding window to generate corresponding window hash digests. The generated window hash digests are then divided into multiple hash shares through a secret sharing method. The sending and receiving ends jointly participate in a secure multi-party computation protocol to perform an equal-value comparison of the hash shares to obtain a consistency indicator. If the consistency indicator indicates a hash inconsistency, the sending end records the corresponding data block sequence number and adds it to the difference block retransmission queue, while the receiving end discards the corresponding data block and sends a retransmission request. After the difference block retransmission is completed, the homomorphic hash consistency verification is re-executed until all ciphertext blocks within the window pass the verification.

[0114] In some embodiments, Figure 2 The update module 205 uses the central node to receive the synchronization confirmation message returned by the target computing node. The synchronization confirmation message includes the data block sequence number, block size, and corresponding noise amplitude. It calculates the privacy budget consumption based on the block size and noise amplitude, and atomically deducts the privacy budget consumption from the privacy budget value field of the hierarchical version vector. It generates a synchronization usage record carrying the node identifier, data block sequence number, block size, noise amplitude, and the remaining privacy budget value after deduction, and calls the data management module to write the synchronization usage record into the immutable log chain.

[0115] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0116] Figure 3 This is a schematic diagram of the structure of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0117] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 303 in electronic device 3.

[0118] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0119] Processor 301 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0120] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 302 can include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0121] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0122] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0123] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0124] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0126] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0127] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0128] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application are described in detail with reference to the foregoing 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An efficient data synchronization method for privacy-preserving computing scenarios, characterized in that, include: Negotiate and maintain a hierarchical version vector between the central node and multiple computing nodes; Based on the hierarchical version vector, the set of data blocks to be synchronized is determined, and the corresponding synchronization task directed acyclic graph is constructed at the central node and sent to each computing node. In each computing node, the local data to be synchronized is divided into several data blocks according to a preset block partitioning strategy. Each data block is encrypted to obtain the first ciphertext. Differential privacy noise is injected into the first ciphertext to obtain the second ciphertext. The second ciphertext is then written into the sending queue. The second ciphertext is sent to the target computing node block by block in a sliding window manner. At the sending end and the receiving end, a homomorphic hash consistency check based on secure multi-party computation is performed on the ciphertext blocks in the window. If the check is inconsistent, the corresponding data block is marked and the difference block is retransmitted. After the consistency check passes, the hierarchical version vector saved by the central node is updated, and the data management module is called to deduct the corresponding privacy budget based on the synchronization block size and noise amplitude and record the synchronization usage. The synchronized data blocks are written to the target computing node's data storage and input into the privacy computing platform's computing module to perform subsequent multi-party secure computation or federated learning tasks.

2. The method according to claim 1, characterized in that, The process of negotiating and maintaining a hierarchical version vector between the central node and multiple computing nodes includes: The compute nodes are used to generate a hierarchical version vector containing a metadata version number, a block-level data version number, and a remaining privacy budget value, and then digitally signed with the node's private key. The hierarchical version vector with digital signature is sent to the central node via a secure channel with two-way authentication. The central node verifies the digital signature and uses a hash comparison algorithm to fuse the hierarchical version vectors from each computing node to form a global hierarchical version vector, while generating a version difference mapping table. The central node issues version synchronization instructions to relevant computing nodes based on the version difference mapping table, and updates the stored global hierarchical version vector after receiving confirmation of synchronization completion.

3. The method according to claim 2, characterized in that, The process of determining the set of data blocks to be synchronized based on the hierarchical version vector, constructing a corresponding directed acyclic graph of synchronization tasks at the central node, and distributing it to each computing node includes: The central node generates a list of data block indexes to be synchronized for each computing node based on the version difference mapping table. The list of data blocks to be synchronized is mapped as a directed acyclic graph arranged in the order of initialization node, data block transmission node, merge node and commit node, wherein each data block transmission node carries a priority label, retry threshold and window size parameter. The constructed directed acyclic graph is sent to the corresponding computing node via an authenticated communication channel for subsequent synchronization task scheduling and execution.

4. The method according to claim 1, characterized in that, The step of splitting the local data to be synchronized into several data blocks in each computing node according to a preset block partitioning strategy includes: Set a first block size threshold for the local data to be synchronized, and perform initial equal-length division according to the first block size threshold; A hot zone identification algorithm based on access frequency metric is executed on the data blocks obtained by the initial equal-length division. If a hot zone segment is detected, an adaptive subdivision is performed within the hot zone segment using a second block size threshold. Generate a block number, starting offset, length, and hash check value for the final data block, and write the block number and hash check value into the data block index list to be synchronized.

5. The method according to claim 1, characterized in that, The process of encrypting each data block to obtain a first ciphertext, injecting differential privacy noise into the first ciphertext to obtain a second ciphertext, and writing the second ciphertext into the sending queue includes: Obtain the public key and encryption parameters assigned by the encryption engine module on the computing node; A lightweight homomorphic encryption operation is performed on the data block based on the public key to obtain the first ciphertext; A secure random number generator is invoked to sample noise values ​​from a Laplace distribution or a Gaussian distribution according to a preset privacy budget, and the noise values ​​are homomorphically encrypted using the public key to obtain encrypted noise; Perform homomorphic addition on the first ciphertext and the encrypted noise to generate the second ciphertext, and write the second ciphertext and the corresponding data block sequence number into the sending queue.

6. The method according to claim 1, characterized in that, The step of performing homomorphic hash consistency verification based on secure multi-party computation on the ciphertext blocks within the window at the sending and receiving ends, and marking the corresponding data block and triggering the retransmission of the difference block when the verification is inconsistent, includes: At both the sending and receiving ends, the same homomorphic hash function is invoked for the second ciphertext within the current sliding window, and a shared hash random salt is introduced to generate the corresponding window hash digest. Each generated window hash digest is divided into multiple hash shares through a secret sharing method. The sending end and the receiving end jointly participate in a secure multi-party computation protocol to compare the hash shares to obtain a consistency identifier. If the consistency flag indicates that the hashes are inconsistent, the corresponding data block sequence number is recorded at the sending end and added to the difference block retransmission queue, while the corresponding data block is discarded at the receiving end and a retransmission request is sent back. After the difference block is retransmitted, the homomorphic hash consistency check is re-executed until all ciphertext blocks in the window pass the check.

7. The method according to claim 1, characterized in that, After the consistency check passes, the hierarchical version vector stored in the central node is updated. The data management module is then invoked to deduct the corresponding privacy budget based on the synchronization block size and noise amplitude, and the synchronization usage is recorded. This includes: The central node receives the synchronization confirmation message returned by the target computing node. The synchronization confirmation message includes the data block sequence number, block size and corresponding noise amplitude. The privacy budget consumption is calculated based on the block size and noise amplitude, and the privacy budget consumption is atomically deducted from the privacy budget value field of the hierarchical version vector. Generate a synchronization usage record carrying node identifier, data block sequence number, block size, noise amplitude, and the remaining privacy budget value after deduction. Call the data management module to write the synchronization usage record into an immutable log chain.

8. A high-efficiency data synchronization device for privacy-preserving computing scenarios, characterized in that, include: The negotiation module is used to negotiate and maintain hierarchical version vectors between the central node and multiple computing nodes; The construction module is used to determine the set of data blocks to be synchronized based on the hierarchical version vector, construct the corresponding directed acyclic graph of synchronization tasks at the central node, and distribute it to each computing node. The encryption module is used to split the local data to be synchronized into several data blocks in each computing node according to a preset block partitioning strategy, encrypt each data block to obtain a first ciphertext, inject differential privacy noise into the first ciphertext to obtain a second ciphertext, and write the second ciphertext into the sending queue. The verification module is used to send the second ciphertext to the target computing node block by block in a sliding window manner, and to perform homomorphic hash consistency verification based on secure multi-party computation on the ciphertext blocks in the window at the sending end and the receiving end. If the verification is inconsistent, the corresponding data block is marked and the difference block is retransmitted. The update module is used to update the hierarchical version vector stored in the central node after the consistency check passes, and calls the data management module to deduct the corresponding privacy budget based on the synchronization block size and noise amplitude and record the synchronization usage. The write module is used to write the synchronized data blocks to the data storage of the target computing node and input them into the computing module of the privacy computing platform to perform subsequent multi-party secure computation or federated learning tasks.

9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images