Data synchronization method, intelligent wearable device and system

Abstract

The invention discloses a data synchronization method, an intelligent wearable device and a system, relates to the technical field of data transmission, and mainly aims to solve the problem of how to give consideration to protection of user privacy and data accuracy in a data synchronization process. The method mainly comprises the steps that to-be-synchronized data is obtained, a use scene type corresponding to the to-be-synchronized data is determined, and the to-be-synchronized data is data collected in the use process of the intelligent wearable device; under the condition that the use scene type is matched with any sensitive scene, generating proof information of the to-be-synchronized data based on a target arithmetic circuit matched with the sensitive scene; and sending the certification information to a verification execution end, so that the verification execution end verifies the certification information, submits a transaction containing a verification result to a block chain end, stores the verification result based on an intelligent contract pre-configured by the block chain end, and provides an interface for querying the verification result. The method is mainly used for protecting privacy and synchronizing data at the same time.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data transmission, and in particular to a data synchronization method, smart wearable device and system. BACKGROUND

[0002] With the rapid development of smart wearable device technology, smart wearable devices, as a typical representative, have penetrated into all aspects of people's daily life. Smart wearable devices not only can monitor the user's health status in real time, such as heart rate, blood pressure, sleep quality, etc., but also can provide communication, navigation, payment and other convenient services. The implementation of these functions often depends on the data synchronization between the smart wearable device and the cloud server or other devices. In the data synchronization process, the user's sensitive information, such as health data, location information, etc., will be frequently transmitted and stored. Although the traditional encryption method can prevent data from being stolen or tampered with during transmission and storage, it cannot completely avoid the risk of data leakage during verification.

[0003] Especially in the data synchronization scenario involving multiple parties, such as data sharing between smart wearable devices and medical institutions, insurance companies, etc., the user often needs to prove the authenticity and validity of the data without revealing the original data. This requires a more efficient and secure data synchronization method that can protect user privacy while ensuring data accuracy and reliability. SUMMARY

[0004] Therefore, the present application provides a data synchronization method, smart wearable device and system, which mainly aims to solve the problem of not being able to protect user privacy and data accuracy during data synchronization.

[0005] According to one aspect of the present application, a data synchronization method is provided, comprising:

[0006] obtaining to-be-synchronized data and determining the use scenario type corresponding to the to-be-synchronized data, wherein the to-be-synchronized data is data collected during the use of a smart wearable device;

[0007] in the case that the use scenario type matches any sensitive scenario, generating proof information of the to-be-synchronized data based on a target arithmetic circuit matching the sensitive scenario;

[0008] sending the proof information to a verification execution end to make the verification execution end verify the proof information, and submitting a transaction containing the verification result to a block chain end to store the verification result based on a smart contract pre-configured by the block chain end and provide an interface for querying the verification result.

[0009] Further, the method further comprises:

[0010] In a case where the use scenario type does not match the sensitive scenario, the to-be-synchronized data is preprocessed, wherein the preprocessing includes at least one of data cleaning, data formatting, and data standardization;

[0011] The preprocessed to-be-synchronized data is uploaded to a blockchain end to store the to-be-synchronized data based on the blockchain end.

[0012] Further, the generating of the proof information of the to-be-synchronized data based on the target arithmetic circuit matching the sensitive scenario includes:

[0013] The target arithmetic circuit matching the sensitive scenario is called from pre-constructed arithmetic circuits, wherein the target arithmetic circuit includes a plurality of operation gates;

[0014] The to-be-synchronized data is encoded, and the encoded to-be-synchronized data is taken as an input of the target arithmetic circuit, and an operation of the target arithmetic circuit is simulated to obtain input values and output values of each operation gate;

[0015] An execution track of the simulation execution of the to-be-synchronized data in the target arithmetic circuit is constructed according to the input values and the output values;

[0016] The proof information of the to-be-synchronized data is generated according to the execution track.

[0017] Further, before the calling of the target arithmetic circuit matching the sensitive scenario from the pre-constructed arithmetic circuits, the method further includes:

[0018] All sensitive scenarios covered by expected synchronization data are determined;

[0019] For each sensitive scenario, a to-be-proved logical rule under the sensitive scenario is called, and the to-be-proved logical rule is converted into an operation gate to obtain an arithmetic circuit corresponding to each protection scenario;

[0020] The arithmetic circuit and the respective corresponding protection scenario are associated and stored to be called in a generation process of the proof information.

[0021] Further, the generating of the proof information of the to-be-synchronized data according to the execution track includes:

[0022] The execution track is converted by a hash function to obtain a hash value of the execution track;

[0023] construct a polynomial through an interpolation algorithm with the values in the execution track as sampling points, and commit the polynomial based on a commitment algorithm to obtain a commitment value and a verification path, wherein the polynomial has the same value as the value of the corresponding sampling point in the execution track at the sampling point;

[0024] generate a proof based on the hash value, the commitment value and the verification path, and generate proof information based on the proof and auxiliary information of the to-be-synchronized data.

[0025] Further, the verification execution end includes an intermediate device or an off-chain server, and the sending of the proof information to the verification execution end for verification of the proof information by the verification execution end includes:

[0026] sending the proof information to the intermediate device for verification of the proof information by the intermediate device to obtain a verification result; or,

[0027] sending the proof information to a forwarding device and forwarding the proof information to an off-chain server through the forwarding device for verification of the proof information by the off-chain server to obtain a verification result.

[0028] The verification includes parameter verification, consistency verification of the polynomial commitment and the proof information, and polynomial commitment verification.

[0029] Further, the transaction further includes a key signature, and the sending of the transaction containing the verification result to the blockchain end includes:

[0030] performing private key signature on the verification result through the intermediate device or the off-chain server, and encapsulating the private key signature information and the verification result into a transaction;

[0031] The method further includes:

[0032] verifying the private key signature information based on a smart contract of the blockchain end to verify whether the intermediate device or the off-chain server is a trusted server.

[0033] Further, the sensitive scenario includes a scenario in which the to-be-synchronized data contains user health monitoring data and / or user behavior monitoring data.

[0034] As an implementation of the above method, an embodiment of the present application provides a smart wearable device for performing operations corresponding to the above data synchronization method.

[0035] As an implementation of the above method, an embodiment of the present application provides a system including a smart wearable device, a verification execution end and a blockchain end.

[0036] The smart wearable device is configured to perform the operation corresponding to the data synchronization method.

[0037] The verification execution end is configured to verify the proof information sent by the smart wearable device and upload the verification result to the blockchain end.

[0038] The blockchain end is configured to store the verification result based on a pre-configured smart contract and provide an interface for querying the verification result.

[0039] The technical scheme provided by the embodiment of the application has at least the following advantages:

[0040] The application provides a data synchronization method, a smart wearable device and a system. The embodiment of the application acquires to-be-synchronized data and determines a use scenario type of a watch corresponding to the to-be-synchronized data. In a case where the use scenario type matches a sensitive scenario, proof information of the to-be-synchronized data is generated based on a target arithmetic circuit matched with the sensitive scenario. The proof information is sent to a verification execution end, so that the verification execution end verifies the proof information, and a transaction containing a verification result is submitted to a blockchain end, so that the verification result is stored based on a pre-configured smart contract of the blockchain end, and an interface for querying the verification result is provided. By accurately identifying the use scenario type of the watch, the proof information of the to-be-synchronized data is generated by using the target arithmetic circuit in the case where the sensitive scenario is matched, the privacy protection is effectively strengthened, the sensitive data of the user is ensured not to be leaked and misused in the processing process, and meanwhile, in the case where a complex and diverse application scenario is faced, the system can flexibly adjust the data processing strategy according to the scenario type, the processing mode of "one size fits all" is avoided, the data processing process is ensured to be more in line with the actual demand, and the efficiency and accuracy of the data processing are improved.

[0041] The above description is only a summary of the technical scheme of the application. In order to more clearly understand the technical means of the application, the application can be implemented according to the content of the specification, and in order to make the above and other purposes, characteristics and advantages of the application more obvious and easy to understand, the following specific embodiments of the application are described. BRIEF DESCRIPTION OF DRAWINGS

[0042] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of the preferred embodiments and are not meant to limit the present application. Furthermore, the same reference numerals are used throughout the several drawings to refer to the same or like parts. In the drawings:

[0043] Figure 1 A data synchronization method flowchart provided by the embodiment of the application is shown;

[0044] Figure 2 Fig. 1 shows a data synchronization schematic diagram based on intermediate equipment for attestation verification according to an embodiment of the present application;

[0045] Figure 3 Fig. 2 shows a data synchronization schematic diagram based on off-chain server for attestation verification according to an embodiment of the present application;

[0046] Figure 4 Fig. 3 shows a structure schematic diagram of a system according to an embodiment of the present application. DETAILED DESCRIPTION

[0047] Exemplary embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. While example embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.

[0048] In view of the problem that it is difficult to balance the protection of user privacy and data accuracy in the data synchronization process. The embodiments of the present application provide a data synchronization method, as shown in Figure 1 The method comprises the following steps.

[0049] 101. Obtain the to-be-synchronized data, and determine the use scenario type corresponding to the to-be-synchronized data.

[0050] In the embodiment of the present application, the synchronization of data is the data synchronization between the smart wearable device and the blockchain end. The current execution subject is a smart wearable device, including but not limited to a smart watch, a health bracelet, etc. The data to be synchronized includes data collected by the smart wearable device during use and needing to be synchronized to the blockchain end. In daily use, the current execution subject continuously collects physiological data (such as heart rate, exercise steps, sleep quality) or environmental data (such as location, temperature) of the user. These data may involve user privacy (such as health data) or business sensitive information (such as exercise trajectory), and need to be dynamically judged according to the use scenario whether privacy protection is needed. If the data needs privacy protection, it is determined that the use scenario type is a sensitive scenario, otherwise, the use scenario type is a non-sensitive scenario. For example, the user publicly shares the daily steps to a social platform, and the data to be synchronized does not need to be encrypted, so the corresponding use scenario type is a non-sensitive scenario. For another example, the user wears the device to monitor sleep at night, and the data to be synchronized includes abnormal fluctuations in heart rate, which may involve health privacy; or the user wears the device into an enterprise park, and the data to be synchronized includes location information, which may involve business secrets, so the corresponding use scenario type is a sensitive scenario. The determination of the use scenario type can be based on keyword extraction, data identification, etc., and the embodiment of the present application does not make specific limitation. Through scenario type identification, the system can dynamically select whether to enable the privacy protection mechanism, avoid unnecessary encryption overhead on non-sensitive data, and only enable the proof for sensitive data, balancing privacy protection and computing efficiency.

[0051] 102、In the case where the use scenario type matches any sensitive scenario, generating proof information of the data to be synchronized based on a target arithmetic circuit matching the sensitive scenario.

[0052] In the embodiment of the present application, the current execution subject imports an arithmetic circuit pre-constructed for different sensitive scenarios. The arithmetic circuit is a code constructed based on rules or constraints that the data needs to meet in the respective corresponding sensitive scenario, and is used to prove that the current data meets the expected rules or constraints. For example: proving that the heart rate is within a reasonable range, the location data is within a certain area, etc., without directly exposing the specific value of each measurement, and it is also impossible to infer the specific average value based on this range. By proving the data to be synchronized, the execution end can confirm the data compliance without obtaining the original data, which safeguards data privacy while avoiding the leakage risk caused by directly transmitting sensitive data.

[0053] Preferably, the sensitive scene includes a scene in which the to-be-synchronized data contains user health monitoring data and / or user behavior monitoring data. That is, when the to-be-synchronized data contains one of user health monitoring data and user behavior monitoring data, or contains both of the above data, it is determined that the use scene type corresponding to the to-be-synchronized data is a sensitive scene. User health monitoring data (such as heart rate, blood pressure, sleep quality, etc.) and user behavior monitoring data (such as daily activity trajectory, exercise habit, etc.) directly reflect the personal health status and living habits of the user, and have high privacy. Configuring the scene containing these data as a sensitive scene and performing proof verification can effectively ensure the privacy and security of the user.

[0054] 103. The proof information is sent to the verification execution end, so that the verification execution end verifies the proof information, and a transaction containing a verification result is submitted to the blockchain end, so that the verification result is stored based on a smart contract pre-configured by the blockchain end, and an interface for querying the verification result is provided.

[0055] In the embodiment of the application, after obtaining the proof information, the current execution subject sends the proof information to the verification execution end to call the public parameters pre-stored on the server, such as finite field parameters, polynomial commitment related public parameters, etc., and confirms whether the proof information satisfies the arithmetic circuit constraint. If the verification is passed, a verification result (such as “heart rate data compliance”) is generated. Further, the verification result (such as “data compliance” or “data anomaly”) is submitted to the blockchain end by the verification execution end. The blockchain end stores the verification result through a smart contract, and provides an unforgeable query interface, ensuring that the result is traceable and non-repudiable. Specifically, based on the smart contract, the verification result is bound with data hash and timestamp and stored in the blockchain node, so that the user or a third party can query the historical verification record through the interface. The unforgeable nature of the blockchain ensures the authenticity of the verification result, avoiding data tampering or forgery.

[0056] In one embodiment of the application, for further illustration and limitation, the method further comprises:

[0057] In the case where the use scene type does not match the sensitive scene, the to-be-synchronized data is preprocessed;

[0058] The preprocessed to-be-synchronized data is uploaded to the blockchain end, so that the to-be-synchronized data is stored based on the blockchain end.

[0059] In the embodiment of the present application, when the use scenario type of the to-be-synchronized data does not match the sensitive scenario (such as user daily motion data, public environment monitoring data, etc.), the data does not need privacy protection processing, but needs to be preprocessed to ensure data quality, format uniformity and storage efficiency. The preprocessed data can be directly uploaded to the blockchain end, and the tamper-proof and distributed storage characteristics of the blockchain are used to realize the trusted storage and traceability of the data. Among them, the preprocessing includes at least one of data cleaning, data formatting, and data standardization. Data cleaning is to clean up abnormal values to avoid invalid data occupying storage resources. For example, the step data collected by the smart bracelet contains abnormal values (such as single-day step number exceeding 100,000 steps, which may be caused by device mis-touch), which are corrected by threshold filtering (such as deleting records with step number exceeding a reasonable range) or smoothing algorithm (such as moving average). Data formatting is to convert the data into a unified format to improve data readability and cross-system compatibility. For example, the data formats collected by different devices may not be consistent (such as timestamp format "YYYY-MM-DD" or "MM / DD / YYYY"), which are converted to the unified timestamp format "2023-10-01T12:00:00Z" and JSON or Protobuf format. Data standardization is to standardize the data. For example, the heart rate data units of different brands of devices may be different (such as "times / minute" or "BPM"), which are unified to the standard unit (such as "times / minute") and normalized value range. By flexibly selecting whether to perform privacy protection according to the scenario type, the data security and data processing amount can be effectively balanced, and in addition, by completing the preprocessing steps on the local device, the computational load and storage burden of the blockchain node can also be reduced, and the overall efficiency of the system can be improved.

[0060] In one embodiment of the present application, in order to further illustrate and limit, the proof information of the to-be-synchronized data is generated based on a target arithmetic circuit matching the sensitive scenario, comprising:

[0061] The target arithmetic circuit matching the sensitive scenario is called from the pre-constructed arithmetic circuit;

[0062] The to-be-synchronized data is encoded, and the encoded to-be-synchronized data is taken as the input of the target arithmetic circuit, and the operation of the target arithmetic circuit is simulated to obtain the input value and output value of each operation gate;

[0063] The execution track of the to-be-synchronized data in the simulation execution of the target arithmetic circuit is constructed according to the input value and the output value;

[0064] The proof information of the to-be-synchronized data is generated according to the execution track.

[0065] In the embodiment of the present application, before the proof of the data to be synchronized, the data set composed of the data to be synchronized needs to be encoded. That is, using the encoding function Encode to convert the data set D={d1, d2, …, d i ,…,d n} into an element D ′ on a finite field; wherein d i is the i-th data item in the data set. For example, the heart rate sensor of the smart watch collects n heart rate values in a period of time to form a data set H. The smart watch adds all the heart rate values in the data set H={h1, h2, …, h i ,…,h n} to obtain the total sum of heart rates sum, which is expressed as The smart watch calculates the multiplicative inverse of the total number of heart rate data n -1 (in a finite field) and multiplies n -1 by sum to obtain the average heart rate avg, which is expressed as: avg=sum×n -1 .

[0066] After obtaining the encoded data, the encoded data D ′ is taken as the input of the target arithmetic circuit C to simulate the operation of the circuit. The target arithmetic circuit includes a plurality of operation gates. Therefore, the input and output values of each gate in the circuit need to be recorded, and finally, the execution trace T is generated according to the input and output values of each gate, which is expressed as: T=Execute(C, D ′ ); wherein Execute represents the execution of the circuit, T={t1, t2, …, t i ,…,t m}, t i represents the output value of the i-th gate in the circuit; and m represents the number of gates in the target arithmetic circuit.

[0067] In an embodiment of the present application, in order to further illustrate and limit, the proof information of the data to be synchronized is generated according to the execution trace, which includes:

[0068] The execution trace is hashed by a hash function to obtain the hash value of the execution trace;

[0069] The values in the execution trace are taken as sampling points, a polynomial is constructed by an interpolation algorithm, and the polynomial is committed based on a commitment algorithm to obtain a commitment value and a verification path;

[0070] The proof is generated according to the hash value, the commitment value, and the verification path, and the proof information is generated according to the proof and the auxiliary information of the data to be synchronized.

[0071] In the embodiment of the present application, after obtaining the execution track, the execution track needs to be converted by hash to generate the hash value of the execution track. The hash value is used to verify the integrity and uniqueness of the execution track. The hash function used for conversion can be BLAKE2b. Then, using an interpolation algorithm (such as Reed-Solomon code), the values in the execution track are taken as sampling points to construct a polynomial p(x). The value of this polynomial at the sampling points is the same as the value of the corresponding sampling points in the execution track. Based on the FRI protocol (Fast Reed-Solomon Interactive Oracle Proof of Proximity), the polynomial p(x) is committed to generate a commitment value and a verification path. The hash value of the execution track, the commitment value of the polynomial and the verification path are packaged together to form a proof; and the generated proof is combined with the auxiliary information (such as smart wearable device ID, timestamp, and hash value of the data to be synchronized) of the data to be synchronized to form complete proof information. The verification path is used to verify the validity of the polynomial on the chain. By hashing the execution track and committing the polynomial, the tamper resistance of the calculation process can be ensured, the integrity of the data can be ensured, in addition, the size of the proof is usually a few hundred bytes, which can make the verification process fast and light, and improve the verification efficiency.

[0072] In one embodiment of the present application, in order to further illustrate and limit, before the target arithmetic circuit matching the sensitive scene is called from the pre-constructed arithmetic circuit, the method further comprises:

[0073] Determining all sensitive scenes covered by the expected synchronization data;

[0074] For each sensitive scene, call the logic rule to be proved under the sensitive scene, and convert the logic rule to be proved into an operation gate to obtain the arithmetic circuit corresponding to each protection scene respectively;

[0075] The arithmetic circuit and the corresponding protection scene are associated and stored to be called in the generation process of the proof information.

[0076] In the embodiments of the present application, before the data synchronization process is started, all possible sensitive scenarios involved need to be identified and defined. The sensitive scenario usually refers to a scenario involving user privacy or high-value data, such as health data (heart rate, step count), location data, financial data, etc. For example, heart rate data synchronization can be taken as the first sensitive scenario; location trajectory synchronization can be taken as the second sensitive scenario; sleep monitoring data synchronization can be taken as the third sensitive scenario. For each sensitive scenario, the corresponding to-be-proved logical rules are called from the pre-defined rule library, such as data range constraints, state transition rules, etc. The logical rules are converted into a series of addition and multiplication operations (i.e. arithmetic circuits) composed of addition gates and multiplication gates. These operations are represented in the form of circuit diagrams or codes to form the arithmetic circuit corresponding to the sensitive scenario. For example, for the heart rate scenario, it needs to be proved that the average heart rate avg is between the closed interval [lower, upper] (such as [60, 100]), and the code of the corresponding arithmetic circuit can be:

[0077] avg = 80 # private input

[0078] lower = 60 # public input

[0079] upper = 100 # public input

[0080] diff_lower = avg - lower

[0081] diff_upper = upper - avg

[0082] assert diff_lower >= 0 and diff_upper >= 0 # non-negativity constraint

[0083] # auxiliary variables (inputs in the circuit)

[0084] sqrt_diff_lower = 4.472

[0085] diff_lower = sqrt_diff_lower * sqrt_diff_lower

[0086] sqrt_diff_upper = 4.472

[0087] diff_upper = sqrt_diff_upper * sqrt_diff_upper

[0088] # constraints (enforced in the circuit)

[0089] assert abs(diff_lower-sqrt_diff_lower*sqrt_diff_lower)<0.0001 # handle floating point approximations with absolute value and small tolerance

[0090] assert abs(diff_upper-sqrt_diff_upper*sqrt_diff_upper)<0.0001

[0091] print("average heart rate in range:",diff_lower>=0 and diff_upper>=0)

[0092] Then, the generated arithmetic circuit is stored in association with the corresponding sensitive scenario, forming a mapping relationship table. In the subsequent proof information generation process, the corresponding arithmetic circuit can be quickly retrieved according to the scenario corresponding to the current data to be synchronized.

[0093] It should be noted that the creation of arithmetic circuits on smart watches needs to consider resource limitations, so it is necessary to simplify the circuit structure as much as possible, reduce memory occupation, and fully utilize hardware acceleration functions to optimize at the software level. By pre-constructing the arithmetic circuit, the pre-constructed arithmetic circuit avoids temporary calculation each time data is synchronized, significantly shortens the proof generation time, and reduces the computational burden of smart watches and other devices, prolonging the battery life. Taking a smart watch as an example, it takes 1 second to build an arithmetic circuit for heart rate range verification, and the verification itself takes 0.1 second. If the circuit is rebuilt each time the heart rate data is updated, each verification will take 1.1 seconds. By pre-constructing the circuit, only one construction is required, and each verification only takes 0.1 second, which is equivalent to saving 1 second per verification, with a 10-fold increase in verification speed and a significant improvement in battery life. In addition, through associated storage, new sensitive scenarios and corresponding arithmetic circuits can be flexibly expanded to adapt to diverse application requirements.

[0094] In an embodiment of the present application, in order to further illustrate and limit, the sending the proof information to the verification execution end, so that the verification execution end verifies the proof information, comprises:

[0095] sending the proof information to the intermediate device to verify the proof information based on the intermediate device to obtain a verification result; or,

[0096] sending the proof information to the forwarding device and forwarding the proof information to an off-chain server through the forwarding device to verify the proof information based on the off-chain server to obtain a verification result.

[0097] In the embodiment of the present application, the verification execution end includes an intermediate device or an off-chain server. The intermediate device can be a smart portable device such as a smart phone, a tablet computer, etc. The proof information generated by the smart wearable device can be sent to the intermediate device for verification, or the proof information can be sent to the off-chain server through the relay device for verification based on the off-chain server. The relay device can be the same device as the intermediate device. The verification method of the intermediate device and the off-chain server for the proof information is the same. That is, without accessing the original data, the mathematical structure of the proof is verified whether it conforms to the predefined rules, including parameter verification, consistency verification of polynomial commitment and proof information, and polynomial commitment verification. The specific verification process includes: performing validity check on the received parameters to ensure that the parameters conform to the specifications; checking whether the polynomial commitment is consistent with the generated proof to ensure the accuracy of the polynomial commitment; and performing FRI protocol verification to further confirm the validity of the polynomial commitment. During the verification process, the intermediate device may need to read the public parameters pre-stored on the server, such as finite field parameters, public parameters required by the polynomial commitment, etc., to ensure the accuracy and reliability of the verification. After completing the verification, the verification execution end generates a verification state according to the verification result. If the proof passes the verification, it is determined that the data uploaded by the smart watch is trustworthy, and the verification state is marked as "valid"; if the verification fails, it is determined that the data is untrustworthy, and the verification state is marked as "invalid". In addition, the intermediate device can also add other verification information such as verification time, verifier's identity information, etc. to provide more comprehensive verification records.

[0098] In one embodiment of the present application, in order to further illustrate and limit, a transaction containing the verification result is submitted to the blockchain end, including:

[0099] The private key signature information and the verification result are encapsulated into a transaction through the private key signature of the intermediate device or the off-chain server.

[0100] The method further includes verifying the private key signature information based on the smart contract of the blockchain end to verify whether the intermediate device or the off-chain server is a trusted server.

[0101] In the embodiments of the present application, the transaction further includes a key signature. To ensure the non-tamperability of the verification result, the verification execution end can choose to digitally sign the verification result. By signing the verification result using a private key, other entities can use the public key of the verification execution end to verify the signature, thereby confirming that the verification result is generated by a trusted verification execution end. Subsequently, the verification execution end encapsulates the verification result and optional signature information into transaction data. The transaction data usually contains the ID of the smart wearable device, the verification result status (valid / invalid), optional signature information, verification timestamp, and a unique ID of the transaction. These pieces of information collectively constitute the complete transaction data, providing necessary information support for subsequent blockchain submission. The verification execution end submits the transaction data containing the verification result to the blockchain. During the submission process, the verification execution end can sign the transaction using its own private key and broadcast the transaction to the blockchain network. Since the verification execution end is considered a trusted third party, its uploaded transaction is generally considered trustworthy. Through the decentralized and tamper-proof nature of the blockchain, the transaction data is securely and reliably stored and disseminated, providing strong support for subsequent data tracing.

[0102] In one application example, as shown in Figure 2 The smart watch, as the data collection end, continuously collects the user's heart rate data. After collecting sufficient data, the smart watch processes the heart rate data using a pre-built arithmetic circuit. This arithmetic circuit is carefully designed to generate a proof for verifying whether the user's average heart rate is within the healthy range of 60-100 beats per minute. After completing the proof generation, the smart watch sends this proof along with other auxiliary information (collectively referred to as proof information) to the paired smartphone. These auxiliary information may include the timestamp of data collection, the device identification of the smart watch, etc., which helps subsequent verification and tracing. Upon receiving the proof information from the smart watch, the smartphone immediately starts the verification process. It uses pre-stored parameters, which are set during the system initialization phase, to ensure the accuracy and consistency of the verification process. The smartphone verifies the validity of the received proof based on these parameters, the core of which is to check whether the mathematical logic of the proof meets the rules set by the arithmetic circuit, to determine whether the average heart rate is indeed between 60-100 beats per minute. After the verification is completed, the smartphone generates corresponding status information based on the verification result. If the proof is valid, it indicates that the user's average heart rate is within the healthy range; if the proof is invalid, it means that the average heart rate may be outside the range. To ensure the authenticity and non-tamperability of the verification result, the smartphone digitally signs the verification result using its own private key. This signature operation allows other entities to verify the validity of the signature using the public key of the smartphone, thereby confirming that the verification result indeed comes from the smartphone.

[0103] In another application example, as shown inFigure 3 As shown, the smartwatch, as a health data collection terminal, continuously monitors and collects the user's heart rate data. After collecting a certain amount of data, the smartwatch generates a proof using a pre-built arithmetic circuit. The core role of this proof is to prove that the user's average heart rate is within the healthy range of 60-100 beats per minute without revealing the specific heart rate data details. This feature greatly protects the user's privacy and avoids sensitive data leakage. After generating the proof, the smartwatch sends the proof and related auxiliary information (collectively referred to as proof information) to the off-chain server through the paired mobile phone as a relay device. These auxiliary information may include the data collection period, the device identifier of the smartwatch, etc., which is helpful for subsequent verification and traceability. After receiving the proof and auxiliary information from the mobile phone, the off-chain server immediately starts the verification process. It uses pre-stored parameters, which are set during the system initialization phase according to the pre-built generation method, to ensure the accuracy and consistency of the verification process. The off-chain server verifies the validity of the received proof based on these parameters. The core of the verification is to check whether the mathematical logic of the proof meets the rules set by the pre-built method to determine whether the average heart rate is indeed between 60-100 beats per minute. After verification, the off-chain server generates corresponding state information according to the verification result. If the proof is valid, it indicates that the user's average heart rate is within the healthy range; if the proof is invalid, it means that the average heart rate may exceed the range. To ensure the authenticity and non-tamperability of the verification result, the off-chain server uses its private key to digitally sign the verification result. This signature operation allows other entities to verify the validity of the signature through the public key of the off-chain server, thereby confirming that the verification result indeed comes from the off-chain server. Subsequently, the off-chain server encapsulates the verification result and signature information into transaction data. In addition to containing the verification result and signature, transaction data may also include the timestamp of the transaction, the unique identifier of the transaction, etc., to ensure the integrity and traceability of the transaction. After encapsulation, the off-chain server submits this transaction to the blockchain network. After receiving the transaction submitted by the off-chain server, the blockchain network broadcasts it to each node for verification and storage. The smart contract on the blockchain processes the transaction according to the pre-set logic after receiving it. The smart contract first verifies the validity of the transaction, including checking whether the signature is correct and whether the transaction format meets the requirements, etc. After verification, the smart contract stores the verification result on the blockchain, ensuring the data's non-tamperability and permanent preservation. At the same time, the smart contract also provides a query interface, allowing authorized users to query the heart rate verification results corresponding to specific smartwatch devices through this interface, providing a convenient and secure way for the management and traceability of health data.

[0104] This invention provides a data synchronization method. It involves acquiring data to be synchronized and determining the usage scenario type of the watch corresponding to the data. If the usage scenario type matches a sensitive scenario, proof information for the data to be synchronized is generated based on a target arithmetic circuit matching the sensitive scenario. This proof information is sent to a verification execution terminal, which verifies the information and submits a transaction containing the verification result to a blockchain. The verification result is stored based on a pre-configured smart contract on the blockchain, which provides an interface for querying the verification result. By accurately identifying the watch's usage scenario type and generating proof information for the data to be synchronized using a target arithmetic circuit when matching a sensitive scenario, this method effectively strengthens privacy protection, ensuring that sensitive user data is not leaked or misused during processing. Furthermore, when facing complex and diverse application scenarios, the system can flexibly adjust data processing strategies according to the scenario type, avoiding a "one-size-fits-all" approach and ensuring that the data processing process is more aligned with actual needs, thus improving the efficiency and accuracy of data processing.

[0105] Furthermore, as a response to the above Figure 1 To implement the method shown, this embodiment of the invention provides a smart wearable device, which is used to perform the operations corresponding to the above data synchronization method.

[0106] Furthermore, as a response to the above Figure 1 The implementation of the method shown in this invention provides a system, such as... Figure 4 As shown, it includes: a smart wearable device 41, a verification execution terminal 42, and a blockchain terminal 43;

[0107] The smart wearable device 41 is used to perform the operations corresponding to the above data synchronization method;

[0108] The verification execution terminal 42 is used to verify the proof information sent by the smart wearable device and upload the verification result to the blockchain terminal;

[0109] The blockchain terminal 43 is used to store the verification results based on a pre-configured smart contract and to provide an interface for querying the verification results.

[0110] The application provides a system, obtains to be synchronized data through a smart wearable device, and determines a use scene type corresponding to a watch used by the to-be-synchronized data; in the case that the use scene type matches a sensitive scene, proof information of the to-be-synchronized data is generated based on a target arithmetic circuit matched with the sensitive scene; the proof information is sent to a verification execution end, so that the verification execution end verifies the proof information, and a transaction containing a verification result is submitted to a block chain end, so that the verification result is stored based on a smart contract preconfigured by the block chain end, and an interface for querying the verification result is provided, through accurate identification of the watch use scene type, the proof information of the to-be-synchronized data is generated by using the target arithmetic circuit when the sensitive scene is matched, the privacy protection is effectively strengthened, it is ensured that the sensitive data of the user is not leaked and abused in the processing process, and meanwhile, when facing complex and various application scenes, the system can flexibly adjust the data processing strategy according to the scene type, the processing mode of 'one size fits all' is avoided, it is ensured that the data processing process is more in line with actual demands, and the efficiency and accuracy of data processing are improved.

[0111] Obviously, those skilled in the art should understand that the modules or steps of the application described above can be realized by general computing devices, which can be concentrated on a single computing device or distributed on a network composed of multiple computing devices, and optionally, they can be realized by program codes executable by the computing devices, so that they can be stored in storage devices and executed by the computing devices, and in some cases, the steps shown or described can be executed in different order, or they can be manufactured into individual integrated circuit modules, or multiple modules or steps thereof can be manufactured into a single integrated circuit module. Thus, the application is not limited to any specific combination of hardware and software.

[0112] The above only describes the preferred embodiments of the application and is not intended to limit the application. For those skilled in the art, the application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the application shall be included in the protection scope of the application.

Claims

1. A data synchronization method, characterized in that, include: Acquire the data to be synchronized and determine the usage scenario type corresponding to the data to be synchronized, wherein the data to be synchronized is data collected during the use of the smart wearable device; If the usage scenario type matches any sensitive scenario, proof information of the data to be synchronized is generated based on the target arithmetic circuit that matches the sensitive scenario. The proof information is sent to the verification execution terminal so that the verification execution terminal can verify the proof information and submit the transaction containing the verification result to the blockchain terminal. The verification result is stored based on the smart contract pre-configured on the blockchain terminal, and an interface for querying the verification result is provided.

2. The method according to claim 1, characterized in that, The method further includes: In the case where the usage scenario type does not match the sensitive scenario, the data to be synchronized is preprocessed, wherein the preprocessing includes at least one of data cleaning, data formatting, and data standardization; The pre-processed data to be synchronized is uploaded to the blockchain platform for storage.

3. The method according to claim 1, characterized in that, The proof information for generating the data to be synchronized based on the target arithmetic circuit matching the sensitive scenario includes: A target arithmetic circuit matching the sensitive scenario is retrieved from a pre-constructed arithmetic circuit, wherein the target arithmetic circuit includes multiple arithmetic gates; The data to be synchronized is encoded, and the encoded data to be synchronized is used as the input of the target arithmetic circuit. The operation of the target arithmetic circuit is simulated to obtain the input and output values ​​of each arithmetic gate. Based on the input and output values, an execution trajectory of the data to be synchronized is constructed in the target arithmetic circuit for simulation. Based on the execution trajectory, proof information for the data to be synchronized is generated.

4. The method according to claim 3, characterized in that, Before retrieving the target arithmetic circuit matching the sensitive scenario from the pre-constructed arithmetic circuit, the method further includes: Identify all sensitive scenarios to be covered by the data to be synchronized; For each sensitive scenario, the logic rule to be proved under the sensitive scenario is retrieved, and the logic rule to be proved is converted into an operation gate to obtain the arithmetic circuit corresponding to each different protection scenario; The arithmetic circuits and their corresponding protection scenarios will be associated and stored for use during the generation of proof information.

5. The method according to claim 3, characterized in that, The proof information for generating the data to be synchronized based on the execution trajectory includes: The execution trajectory is hashed using a hash function to obtain the hash value of the execution trajectory; Using the values ​​in the execution trajectory as sampling points, a polynomial is constructed through an interpolation algorithm, and a commitment is made to the polynomial based on a commitment algorithm to obtain a commitment value and a verification path. The value of the polynomial at the sampling point is the same as the value of the corresponding sampling point in the execution trajectory. A proof is generated based on the hash value, the commitment value, and the verification path, and proof information is generated based on the proof and the auxiliary information of the data to be synchronized.

6. The method according to claim 1, characterized in that, The verification execution terminal includes an intermediate device or an off-chain server. Sending the proof information to the verification execution terminal so that the verification execution terminal can verify the proof information includes: The proof information is sent to the intermediate device for verification, and a verification result is obtained based on the intermediate device; or, The proof information is sent to a forwarding device, and then forwarded to an off-chain server via the forwarding device, so that the proof information can be verified based on the off-chain server to obtain a verification result; The verification process includes parameter verification, consistency verification between polynomial commitments and proof information, and polynomial commitment verification.

7. The method according to claim 6, characterized in that, The transaction also includes key signing, and submitting the transaction containing the verification result to the blockchain includes: The verification result is signed with a private key by the intermediate device or the off-chain server, and the private key signing information and the verification result are encapsulated into a transaction. The method further includes: The private key signature information is verified based on the smart contract on the blockchain to verify whether the intermediate device or the off-chain server is a trusted server.

8. The method according to any one of claims 1-7, characterized in that, The sensitive scenarios include those where the data to be synchronized contains user health monitoring data and / or user behavior monitoring data.

9. A smart wearable device, characterized in that, The smart wearable device is used to perform the operations corresponding to the data synchronization method as described in any one of claims 1-8.

10. A system, characterized in that, include: Smart wearable devices, verification execution terminals, and blockchain terminals; The smart wearable device is used to perform the operation corresponding to the data synchronization method as described in any one of claims 1-8; The verification execution terminal is used to verify the proof information sent by the smart wearable device and upload the verification result to the blockchain terminal. The blockchain platform is used to store the verification results based on pre-configured smart contracts and to provide an interface for querying the verification results.

Images