Data product delivery synchronization method, system, program product, and electronic device

Abstract

The application provides a data product delivery synchronization method, including: a data provider transmitting delivery reference parameters prepared for sub-data of a to-be-delivered data product to a smart contract, and the smart contract performing blockchain notarization on the delivery reference parameters; the data provider sending a symmetric key to a trusted custodian; the data provider delivering encrypted data to a data demander, including sending a ciphertext sub-data and a cryptographic aggregate value, a ciphertext sub-data feature, and a first transmission parameter; in response, the data demander generates a receipt; the data demander sends the receipt including a receipt parameter and a private key signature to the smart contract for notarization and receipt verification, using the received cryptographic aggregate value as an identifier; the smart contract notarizes the receipt and verifies the receipt according to the public key of the data demander, the notarized ciphertext sub-data feature, and the private key signature, to determine whether the data demander has received complete ciphertext sub-data from the data provider; if the verification is passed, the smart contract obtains the symmetric key from the trusted custodian; and if the verification is passed, the smart contract instructs the trusted custodian to send the symmetric key to the data demander. The application also provides a corresponding system, electronic equipment, program product, and the like.

Description

Technical Field

[0001] This application relates to trusted data transmission, and more specifically, to technologies for the delivery and synchronization of data products. Background Technology

[0002] With the development of the digital economy, data has become a key factor of production. However, the market circulation of data products faces many challenges, such as ownership, privacy, and security. Existing technological solutions still have some limitations in terms of data authorization and the consistency management of the actual delivered content.

[0003] On the one hand, the asynchronous disconnect between data product authorization and content delivery poses an asymmetric risk. Most existing technical solutions treat "data authorization" and "content delivery" as two logically and physically independent processes. This separation between logical and physical spaces makes it difficult for these solutions to ensure the synchronicity of "authorization taking effect" and "data receipt," easily leading to asymmetric delivery risks. For example, in scenarios without centralized third-party guarantees, the data requester may refuse to acknowledge receipt of the data as agreed, or the data provider may confirm data authorization but fail to deliver the actual data content as agreed, resulting in obstructed data flow.

[0004] On the other hand, the fragmentation of data lineage in incremental product delivery scenarios leads to difficulties in subset verification. In actual circulation, data products are not always delivered in a one-time full-volume manner, but are often delivered incrementally multiple times over long periods in fragmented, streamlined, or subset forms. Most existing technical solutions treat data products in circulation as a static resource, only solidifying their overall characteristics once, lacking methods for fine-grained control over delivered product sub-data. This results in problems such as missing authorization synchronization of sub-data, difficulty in tracing subordinate relationships, and the risk of content tampering. For example, at the beginning of the year, a data provider company authorizes another customer company to use all its production data for the year as a product, agreeing to monthly delivery. However, since the registration and authorization of the data product occur before actual delivery, under traditional technical solutions, the data customer company finds it difficult to effectively verify the authenticity of the monthly data obtained in the middle of the year, and also finds it difficult to prove to the third-party company that it has the authorization for the monthly data content, as well as the lineage relationship between the sub-data and the authorized product.

[0005] Furthermore, existing solutions lack inherent default constraint capabilities, making it difficult to support large-scale data circulation. The performance guarantees of existing technical solutions largely rely on centralized third parties for verification and assurance. As the scale of data circulation expands, the verification pressure on centralized institutions' computing power increases exponentially, easily becoming an unavoidable single point of failure. Simultaneously, this model lacks credibility. In reality, participating parties often assume that the third party is a semi-honest entity, posing risks of spying on delivered data and collusion between supply and demand parties, making it impossible to guarantee the reliable implementation of default constraint mechanisms. Summary of the Invention

[0006] According to one aspect of this application, a method for synchronizing the delivery of data products is provided. The method includes a data provider transmitting delivery baseline parameters prepared for a sub-data of a data product to be delivered to a smart contract. The delivery baseline parameters include encryption features, a cryptographic aggregation value, encrypted sub-data features, a pre-configured generator of a cyclic group, group elements, and a pairing operation baseline for a pairing function. The encrypted sub-data is the encrypted sub-data of the product. The smart contract stores the delivery baseline parameters on a blockchain. The data provider sends a symmetric key to a trusted custodian, the symmetric key being randomly generated by the data provider when preparing the delivery baseline parameters. The data provider performs encrypted delivery to a data requester, including sending the encrypted sub-data, the cryptographic aggregation value, the encrypted sub-data features, and a first transmission parameter. The first transmission parameter is determined based on the generator and the encryption parameters, and the encryption parameters are randomly generated by the data provider when preparing the delivery baseline parameters. In response to the encrypted delivery, the data requester generates an acknowledgment, which includes an acknowledgment parameter v calculated by the data requester based on its private key sk and a private key signature of the encrypted sub-data. The data requester, using the received cryptographic aggregation value as an identifier, sends the acknowledgment, including the acknowledgment parameter v and the private key signature, to the smart contract for notarization and acknowledgment verification. The smart contract notarizes the acknowledgment and verifies it based on the data requester's public key, the notarized characteristics of the encrypted sub-data, and the private key signature to determine whether the data requester has received the complete encrypted sub-data from the data provider. If the verification passes, the smart contract obtains the symmetric key from the trusted custodian. And if the verification passes, the smart contract instructs the trusted custodian to send the symmetric key to the data requester.

[0007] According to another aspect of this application, a data product delivery system is provided, comprising a data provider, a smart contract module, a trusted custodian, and a data requester. The data provider is configured to transmit delivery baseline parameters to the smart contract module, the delivery baseline parameters including encryption features, a cryptographic aggregation value, encrypted sub-data features, a pre-configured generator of a cyclic group, group elements, and a pairing operation baseline for a pairing function, wherein the encrypted sub-data is the encrypted sub-data of the product; send a symmetric key to the trusted custodian, the symmetric key being randomly generated by the data provider when preparing the delivery baseline parameters; and send the encrypted sub-data, the cryptographic aggregation value, the encrypted sub-data features, and a first transmission parameter to the data requester, the first transmission parameter being determined based on the generator and the encryption parameters, the encryption parameters being randomly generated by the data provider when preparing the delivery baseline parameters. The data requester is configured to generate a receipt in response to receiving the encrypted sub-data. The receipt includes a receipt parameter v calculated by the data requester based on its private key sk, and a private key signature of the encrypted sub-data. Using the received cryptographic aggregation value as an identifier, the receipt, including the receipt parameter v and the private key signature, is sent to the smart contract for notarization and verification. The smart contract module is configured to perform blockchain notarization of the delivery benchmark parameters; notarize the receipt and verify it based on the data requester's public key, the notarized encrypted sub-data characteristics, and the private key signature to determine whether the data requester has received the complete encrypted sub-data from the data provider; if the verification passes, obtain the symmetric key from the trusted custodian; and if the verification passes, instruct the trusted custodian to send the symmetric key to the data requester.

[0008] A computer program product is also provided, the computer program product including a program product that, when executed, enables the implementation of the methods described herein.

[0009] Electronic devices are also provided, including a memory and a processor, wherein the memory stores instructions and the processor, when executing these instructions, is able to implement the methods described herein. Attached Figure Description

[0010] This application will be more fully understood by referring to the following detailed description of specific embodiments in conjunction with the accompanying drawings, wherein the same reference numerals in the drawings refer to the same elements, wherein: Figure 1 This is a schematic diagram of the process of a data product delivery synchronization method according to an embodiment of this application.

[0011] Figure 2This is a flowchart illustrating the method for implementing incremental lineage synchronization of data products based on smart contracts according to an embodiment of this application.

[0012] Figure 3 This illustrates a Merkle tree of continuously growing data features according to an embodiment of this application; Figure 4 This is a flowchart of a data product delivery synchronization method performed by a data provider according to some embodiments of this application.

[0013] Figure 5 This is a flowchart of a data product delivery synchronization method executed by a smart contract according to some embodiments of this application.

[0014] Figure 6 This is a flowchart of a data product delivery synchronization method performed by a data requester according to some embodiments of this application.

[0015] Figure 7 This is a schematic diagram of the structure of a data product delivery system according to an embodiment of this application.

[0016] Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described implementation methods are only a part of the implementation methods of the technical solutions of this application, and not all of them.

[0018] Data products are data-processed products and services that meet specific needs. In a trusted data space, data products are basic units obtained by processing data resources and capable of data circulation and use. For example, data products can take the form of datasets, files, or data application programming interfaces (APIs).

[0019] Product sub-data refers to individual, batch-specific, or shard-specific data units derived from a data product. It represents the smallest data content actually delivered and incrementally distributed. For example, a data product is a complete data asset package provided by the data provider. This data product possesses globally unique cryptographic characteristics, is pre-registered on the blockchain, and its permissions are granted by default for the entire data product—i.e., product-level authorization. This data product consists of multiple product sub-data units. Each product sub-data unit independently calculates its own cryptographic characteristics. During business processing, typically only a portion of the shards needs to be delivered; the entire data product does not need to be delivered to the requesting party. Therefore, this application's embodiments include sub-data-level authorization.

[0020] If the plaintext data of the data product is sent to the data requester in one go, with no subsequent supplements, this delivery method is called full delivery. If the overall cycle of the data product is long and cannot be delivered all at once, but instead new product subsets are transmitted in batches and at different times, with each batch of data to be delivered corresponding to one data increment, this delivery method is called incremental delivery.

[0021] Metadata (also known as metadata) is an information carrier that describes the attributes of a data product. In a trusted data space, metadata is the basic unit for data product registration, retrieval, and circulation management. It is submitted by the data provider, reviewed by the operator, and stored on the blockchain. As an example, metadata may include the data product's identity, unique identifier, cryptographic features, content description, and usage rights policies.

[0022] Typically, smart contracts are contracts based on computer protocols, disseminated, verified, and executed in an information-based manner. They support trusted transactions without the need for third parties, ensuring the traceability and irreversibility of transactions. In the embodiments of this application, smart contracts are implemented as code in the blockchain, which can be automatically executed and is tamper-proof. The descriptions of "smart contract execution notarization, verification, parameter review, and instruction issuance" in the claims and embodiments of this application all refer to the fact that after the smart contract code deployed on the blockchain is triggered by an external transaction, the corresponding business logic is automatically run in the blockchain virtual machine, and key data is written into blocks to complete distributed notarization. The smart contract itself does not run independently of the blockchain; all execution results are synchronously solidified in the blockchain distributed ledger, possessing the characteristics of immutability and full traceability.

[0023] In all embodiments of this application, by way of example and not limitation, the password aggregation algorithm is a hash algorithm, and the password aggregation value is a hash value. Therefore, in the following embodiments, hash algorithms and hash values ​​will be used directly for explanation.

[0024] Figure 1 This is a schematic diagram illustrating the process of a data product delivery synchronization method according to an embodiment of this application. In the embodiment, the data provider 10 may include one or more electronic devices, the trusted provider 40 may include one or more electronic devices, and the data requester 20 may include one or more electronic devices. The smart contract 30 is executable code deployed on the blockchain, enabling automatic operation and recording the execution results on the blockchain.

[0025] According to the embodiments of this application, a set of global cryptographic basic parameters are pre-configured in the data provider 10, the data requester 20, and the smart contract 30 on the blockchain. For example, this set of global cryptographic basic parameters can also be pre-configured in the trusted provider 40. This set of global cryptographic basic parameters includes generator constants g1 and g2 belonging to two cyclic groups G1 and G2, respectively, and a bilinear pairing function e. For any constants a and b, the pairing function satisfies the bilinear equation (1); for the data requester 20, the private key sk of the data requester is defined, and the number of public keys pk corresponding to the data requester satisfies the group generation relation (2), wherein the pairing mapping, equation (1), and generation relation (2) are as follows: e: G1×G2 →GT; (1) (2) In the field of cryptography, a cyclic group is a class of finite algebraic groups in which all elements can be generated by repeatedly multiplying a single fixed element, which is called the generator.

[0026] In step S200, the data provider 10 transmits the delivery baseline parameters prepared for the sub-data of the data product to be delivered to the smart contract 30. The delivery baseline parameters may include encryption features, cryptographic aggregation values, encrypted sub-data features, pre-configured generators of cyclic groups, group elements, and pairing operation baselines of pairing functions. The encrypted sub-data is the encrypted sub-data of the product.

[0027] According to some embodiments of this application, the data provider 10 may perform preprocessing (S100) on the product sub-data to be delivered to prepare delivery baseline parameters for the product sub-data to be delivered.

[0028] As an example, for the product sub-data to be delivered this time, data provider 10 first randomly generates encryption parameters. and symmetric keys Encryption parameters The symmetric key is used for encryption / decryption verification in subsequent atomic synchronization processing. This is the base key for subsequent encryption of plaintext sub-data. Based on Encrypt the product data to be delivered to form encrypted product data, i.e., obtain encrypted sub-data. Based on the encrypted sub-data, calculate its encrypted sub-data characteristics. ;Calculate its cryptographic features based on the sub-data of the product to be delivered. m That is, the cryptographic characteristics of product sub-data m The cryptographic characteristics of the product sub-data can be observed. m It is based on the original plaintext product sub-data, and is a dense state sub-data feature. It is calculated based on the encrypted encrypted sub-data, and the two have different subsequent uses. It uses the public key of data requester 20. Cryptographic characteristics of the product's sub-data m Perform encryption operations to generate the first encryption feature in the encryption features. M pk , with symmetric key Cryptographic characteristics of the product's sub-data m Perform encryption operations to generate a second encryption feature within the encryption features. Therefore, data provider 10 generated multiple auxiliary cryptographic parameters that can be used for data transmission and on-chain evidence storage. and the public key of data requester 20 cryptographic features Perform encryption operations to generate corresponding encryption features. and This serves as an auxiliary cryptographic parameter for data transmission and on-chain evidence storage. As an example, a hash algorithm can be used to calculate the cryptographic characteristics of the sub-data of the product to be delivered. m Other cryptographic hash algorithms can also be applied.

[0029] Furthermore, data provider 10 will use the encryption parameter k and the symmetric key... First encryption feature M pk This is used as the input value for the hash algorithm to obtain the hash value. Data provider 10 will determine the cryptographic characteristics of the identified product sub-data. m As a constant used in the pairing function to generate element g1, and the constant of generator element g2 being 1, the pairing operation result calculated based on the pairing function serves as the pairing operation benchmark for this batch of products to be delivered. Data provider 10 also uses the public key of data requester 20. Cryptographic features of encryption parameter k, generator g2, and product sub-data. m Determine group elements Among them, pk k It involves performing a power-k operation on the public key pk of the data requester on the cyclic group G2. The generator g2 is raised to the power of m on the cyclic group G2. The results of the two powers are multiplied together to obtain the final composite group element.

[0030] In step S202, the smart contract performs blockchain-based notarization of the received delivery baseline parameters.

[0031] The smart contract establishes a binding association with the delivery baseline parameters and simultaneously completes blockchain notarization to achieve on-chain association and retention of the complete set of cryptographic credentials corresponding to the delivery of this product sub-data. Specifically, smart contract 30 will hash the value dense state sub-data features Generator Generator , pairing operation results and group elements They are mutually bound and stored on the blockchain; among them, the hash value... Used to solidify the binding relationship between encryption parameters and targeted delivery behavior; encrypted sub-data characteristics Generator Generator , pairing operation results and group elements This serves as a verification baseline parameter for subsequent verification of the receipt confirmation uploaded by data requester 20. It can be seen that throughout the entire interaction between data provider 10 and smart contract 30, the cryptographic features in plaintext form are evident. Not exposed to the public, smart contract 30 cannot be accessed. The plaintext content.

[0032] In step S204, the data provider 10 sends the symmetric key to the trusted custodian 40. The symmetric key is randomly generated by the data provider 10 when preparing to deliver the baseline parameters. As described above, the symmetric key... It is randomly generated in step S100.

[0033] The data provider 10 privatizes and stores the encryption parameter k, and also stores the symmetric key. Securely back up to a trusted hosting provider 40. The trusted hosting provider 40 is, for example, an operator with neutral attributes, a trusted execution environment, etc. Encrypted parameters are privately stored by the data provider 10. Neutral hosting provider backup This avoids the situation where a single trusted third party possesses all the core cryptographic materials, thereby eliminating the possibility of a single organization snooping on the complete delivery data or colluding with any party.

[0034] In step S206, the data provider 10 delivers encrypted data to the data requester 20, including sending encrypted sub-data, a cryptographic aggregation value, encrypted sub-data characteristics, and a first transmission parameter. The first transmission parameter is determined based on the generator and the encryption parameter; the encryption parameter is randomly generated by the data provider when preparing the delivery baseline parameters, as in step S100 of this example. Specifically, the data provider 10 sends encrypted sub-data and the first transmission parameter to the data requester 20. Features of dense-state sub-data Hash value Among them, the first transmission parameter Based on generator The group elements are calculated using the encryption parameter k.

[0035] In step S207, in response to the encrypted delivery, the data requester 20 generates a receipt, i.e., a receipt receipt; this receipt includes information generated by the data requester based on its own private key. sk The calculated receipt parameter v and the private key signature for the encrypted sub-data. Specifically, the data requester 20 uses its own private key. Calculate receipt parameters And generate a private key signature for the complete encrypted sub-data, and then based on the parameters The receipt is formed by signing with the private key. The receipt parameter v satisfies equation (4): (4) Where g2 is the generator of the pre-configured global cyclic group G2, k is the encryption parameter randomly generated by the data provider 10, and pk is the public key corresponding to the data requester 20.

[0036] Based on equation (4), it can be seen that the receipt parameter v integrates the encryption parameters of the data provider and the public and private key information of the data requester through cyclic group operation, and binds the identities of both the supply and demand parties. This can prevent third parties from forging legitimate receipts and also constrain the data requester from denying that it has received the encrypted sub-data. At the same time, the operation logic of this parameter is compatible with the bilinear pairing system mentioned above, and realizes the non-repudiation and trust verification of the delivery behavior from the cryptographic bottom layer.

[0037] In step S208, the data requester 20 will send the hash value As a delivery identifier (ID), it is sent to smart contract 30 along with the receipt for evidence storage and receipt verification.

[0038] In step S209, smart contract 30 stores the receipt received from data requester 20 and verifies the receipt. Specifically, after storing the receipt on the blockchain to complete the notarization, smart contract 30 calls the public key pk of data requester 20 and compares it with the notarized encrypted sub-data features on the chain. The private key signature generated by the data requester 20 for the encrypted sub-data is verified to confirm that the data requester 20 has fully received the encrypted sub-data sent by the data provider 10. Thus, the private key signature verification can be used to verify the integrity of the encrypted sub-data transmission. The following describes the pairing equation verification, which is used to verify the legality of the receipt parameter v and realize the non-repudiation determination of the receipt behavior. As an example, the smart contract 30 performs the pairing equation verification and determines the legality of the receipt by judging whether equation (6) is true. If equation (6) is true, the verification passes, indicating that the parameter carried by the receipt is valid. Cryptographic characteristics of the original sub-data m It possesses a legitimate and credible correspondence. Combining this with the definition of the receipt parameter mentioned earlier (see equation (4)), v=pk kSubstituting into equation (6) completes the interpolation on the right side of equation (6). The pairing results on both sides are equal if and only if v is a validly calculated result of the private key of the data requester. Equation (6) is as follows: (6) in,( The division symbol in the diagram represents the group inverse operation within the cyclic group G2.

[0039] Thus, relying on the built-in bilinear pairing equation of the smart contract for automatic calculation, the verification of the legality of the receipt and the determination of the authenticity of the product sub-data are completed simultaneously. On the one hand, in high-frequency, large-scale incremental delivery scenarios, the smart contract can process the storage and verification in a distributed and parallel manner, solving the problem of the traditional centralized verification scheme where the verification computing power pressure increases sharply as the scale of data circulation expands, forming a single point of performance bottleneck in the system. On the other hand, all receipts, private key signatures, and pairing verification records are timestamped and stored in the blockchain distributed ledger; according to this embodiment, if the pairing verification fails, the delivery behavior corresponding to the receipt does not have on-chain credible validity. All default judgment criteria are solidified in the blockchain and cannot be tampered with, forming an endogenous performance constraint in the system; compared with the traditional model that relies on centralized third-party guarantees and can only assume that the third party is a semi-honest entity, which has the risk of stealing delivery data and colluding with the transacting party, this solution can ensure the objective, reliable, and automatic execution of default constraint rules from the cryptographic level.

[0040] In step S210, if the receipt verification passes, the smart contract 30 sends a key distribution notification to the trusted custodian 40 to retrieve the symmetric key. In some embodiments, if the receipt verification passes, the smart contract 30 may also instruct the trusted custodian 40 to issue a symmetric key to the data requester 20. .

[0041] According to the method of this embodiment, further, in step S211a, the trusted custodian 40 sends a symmetric key to the smart contract 30. In step S211b, the trusted custodian 40 sends the symmetric key to the data requester 20. .

[0042] Symmetric key In step S205, the data has been backed up to the trusted custodian 40. The symmetric key will only be triggered after the smart contract verifies the validity of the receipt from the data requester 20. The keys are distributed to both smart contract 30 and data requester 20, thus achieving an atomic binding between receipt confirmation and decryption key distribution. Simultaneously, verification is performed by smart contract 30, while the key distribution entity is the trusted custodian 40, satisfying the security architecture design of key separation and escrow.

[0043] It should be noted that, following an alternative example, the trusted custodian 40 only sends the symmetric key to the data requester 20 if the initial verification passes and the subsequent verification described below also passes. .

[0044] The data product delivery synchronization method according to the embodiments of this application may further include verification of delivery baseline parameters, etc. The following will continue to combine... Figure 1 The method for synchronizing the delivery of data products according to the embodiments of this application is further described.

[0045] In step S212, the smart contract verifies the delivery benchmark parameters based on the symmetric key.

[0046] Specifically, smart contract 30 uses For the second encryption feature Decryption is performed to obtain the cryptographic characteristics of the original product sub-data, i.e., to obtain the cryptographic characteristics of the product sub-data. m Subsequently, smart contract 30 used the cryptographic features obtained from decryption. m Perform a pairing operation on the pairing function to calculate the result of the pairing operation. The result of this calculation is then compared with the pairing calculation benchmark of the pairing function that has been stored on the chain. If they match, the parameter verification passes. This step uses smart contract decryption to restore plaintext features and a second recalculation of the pairing value for verification, preventing the on-chain benchmark parameters uploaded by the data provider from being tampered with, thus forming a double-layer verification protection.

[0047] If the verification is successful, smart contract 30 confirms that the encrypted sub-data of the product sub-data has been fully received by the data requester 20.

[0048] According to some examples in this application, when smart contract 30 completes the verification and it is successful, smart contract 30 sends a verification success message to trusted custodian 40. Based on the successful receipt verification in step S209 and the successful verification in step S212, the trusted custodian transfers the symmetric key. The data is sent to the data requester 20 so that the data requester 20 can decrypt the received encrypted sub-data to obtain the product sub-data for that batch, as shown in step S215.

[0049] Following the example in this application, if the verification passes, smart contract 30 will assign cryptographic features to the product sub-data. m Anchoring to the cryptographic characteristics of data products, where the data product is the data product to which the sub-data of the product belongs. This anchoring enables synchronization between product-level authorization and sub-data-level authorization; that is, it synchronously binds and activates product-level authorization with single incremental sub-data subset authorization. For example, a smart contract-driven incremental lineage synchronization method for data products according to embodiments of this application can be used (hereinafter referred to in conjunction with...). Figure 2 (Description) to define the cryptographic characteristics of product sub-data Anchor the association on-chain with the global cryptographic features of the corresponding product.

[0050] It should be noted that in the above process, the step numbers are mainly used to distinguish each step, rather than to limit the execution order of the steps. For example, steps S200, S204 and S206 can be executed in parallel, and steps S214 and S215 can be executed in parallel, and so on.

[0051] The atomic synchronization method automatically implemented by smart contracts according to the embodiments of this application has a logical closed-loop verification capability, which can effectively prevent delivery fraud. Specifically, the method realizes the strong cryptographic binding between the delivery content and the authorization features. For example, the smart contract verifies the cryptographic state of the currently received encrypted sub-data through the pairing equation (6), ensuring from a cryptographic perspective that the original product sub-data with cryptographic feature m can only be decrypted from the data requester's current encrypted sub-data. The relevant verification records are synchronously completed and stored on the blockchain. The method can identify the data provider's parameter fraud behavior through verification. For example, in step S212, the delivery benchmark parameters that have been stored on the chain are subjected to a second cryptographic verification. Only after the verification is passed can the subsequent authorization synchronization process anchored to the global features of the product be executed. The method can also realize the matching verification between the decryption key and the original sub-data. For example, in S212, the smart contract uses the symmetric key to decrypt the second encryption feature to restore the correct sub-data cryptographic feature m. If the data provider provides an invalid or incorrect symmetric key, the verification will be performed. Decryption and pairing comparison will directly fail the verification, blocking subsequent feature anchoring processes and triggering a risk warning simultaneously. Therefore, before the data requester decrypts and obtains the original plaintext data, the smart contract has already completed a pre-check of the decryption key's validity, ensuring the reliability of the entire authorization, decryption, and delivery process.

[0052] In summary, based on the process shown in Figure 1, before the data requester decrypts the original sub-data, multi-layered on-chain verification has already guaranteed the data's authenticity. After the data requester submits a receipt to smart contract 30, it can confirm that as long as subsequent parameter verification passes, the encrypted sub-data it signed for corresponds to genuine and valid product sub-data, and it can normally obtain a usable symmetric key. During execution... Figure 1 Throughout the entire process of the method shown, all key interaction information and verification records are stored on the blockchain in a distributed manner. If a performance dispute occurs later, the complete cryptographic evidence chain can be retrieved to complete the traceability of the entire process.

[0053] Figure 2 This is a flowchart illustrating the method for implementing incremental lineage synchronization of data products based on smart contracts according to an embodiment of this application.

[0054] In step S300, based on the unique identifier of the data product, the latest metadata of the product is queried from the blockchain storage, and the product's cryptographic features (i.e., the product's global features) are extracted from the latest metadata. dfeat For example, the unique identifier of the data product can be used as an index key to traverse all evidence-stored blocks associated with that identifier in the blockchain ledger, arranged in reverse chronological order by the block's on-chain timestamp, to locate the latest evidence-stored record in the block; the structured metadata message within the target block is parsed and basic data verification is completed to obtain the latest metadata of the product; the predefined product cryptographic feature fields are located in the metadata, and the original values ​​of the fields are read, which are the product cryptographic features (product global features). In some cases, if the blockchain ledger does not have a record corresponding to the identifier, it may return an error message; if the latest block does not store a metadata node, it may return an error message indicating missing metadata; if the product cryptographic feature field is not present in the metadata, it may return an error message indicating that the product cryptographic feature has not been uploaded to the blockchain; if the block hash verification fails, it may return an error message indicating that the metadata has been tampered with.

[0055] In step S301, a cryptographic aggregation operation is performed on the cryptographic features of the product sub-data, the cryptographic features of the queried data product, and the public key of the data requester to obtain a new cryptographic aggregation value. Specifically, this will be performed as follows: Figure 1 The cryptographic features of the current delivered product sub-data obtained by decryption (as in step 212) during the atomic synchronization process shown. m The results obtained in step S300 Public key of the data requester Combine them to calculate a new hash value. .

[0056] In step S302, the obtained hash value will be calculated. As a new cryptographic feature of this data product, it is stored on the blockchain by a smart contract, which also updates the corresponding fields in the product metadata.

[0057] After each round of incremental delivery of product sub-data, steps S300, S301, and S302 are executed sequentially to form a global feature iteration and update mechanism. Specifically, step S300 reads the product's global features fixed in the previous moment (previous round) from the blockchain; in S301, historical global features, current incremental sub-data features, and the data recipient's public key are integrated to perform hash aggregation, resulting in the global features of the new version of the data product; step S302 writes the new version's global features into a new block to complete the notarization. Because blockchain records have the characteristics of incremental updates and immutability, the iteration results of multiple rounds of incremental delivery are nested with hashes, logically and dynamically constructing... Figure 3 The data features shown are Merkle trees that continue to grow.

[0058] The following section further elaborates on the data lineage verification and batch authorization on-chain evidence storage mechanism, combining the structural definition of the Merkle tree with the cryptographic verification logic.

[0059] exist Figure 1 After the incremental synchronization process completes step S212 parameter verification and passes, the smart contract executes the process shown in Figure 2, reading the product's global cryptographic features stored in the blockchain. d dfeat Combining the cryptographic characteristics of the current batch of product sub-data m Calculate a new hash value H using the public key pk of the data requester. d dfeat , m, pk In the blockchain, a cryptographic binding relationship is established between global product characteristics, batch sub-data characteristics, and the recipient's public key, and this binding relationship is written into the block for permanent storage.

[0060] like Figure 3 As shown, the root node of this time-series hash Merkle tree represents the latest overall characteristics of the data product; while Product sub-data features m delivered at any time (t) , corresponding receiver public key pk (t) Then, as a leaf node, it is determined by hash operation. It is continuously incorporated into the iterative update calculation of the root node.

[0061] if The global cryptographic characteristics of data products solidified by blockchain at all times are The cryptographic characteristics of the product sub-data in the current delivery batch are as follows: Then, the global characteristics of the data product at time t+1 after iteration are as shown in equation (8): (8) in, It can vary with the delivery time, meaning that data providers can distribute different batches of sub-data of the same data product to multiple different demanders, adapting to data circulation scenarios with multiple entities in parallel.

[0062] In any At any time, if public key verification is required To verify the authenticity of a batch of sub-data received by the data requester, and to determine the relationship between the sub-data and the original parent product, it is only necessary to extract the cryptographic features of the sub-data again. And retrieve the data product characteristics stored in the previous moment from the blockchain. Verify whether equation (10) is true. If it is true, the verification is successful. (10) because and All data is stored on the blockchain and is immutable; the public key of the data requester is a publicly available identity key, and the hash function... It possesses unidirectionality and collision resistance, so if the equation holds, it proves that the sub-data received by the data requester is indeed a subset of the authorized data product at the mathematical level, and has not been tampered with during the delivery process.

[0063] Meanwhile, since the data product completes global identification through its unique on-chain identifier, combined with the complete product authorization record from the previous period, it can be used to verify that the data requester possesses the required characteristics. Legal usage permissions for corresponding product sub-data. A new root node is generated in each iteration. This is both a time-series incremental update of the product's cryptographic features and a... The trusted chain for storing the authorization relationship corresponding to the batch of sub-data at any given time can support audit traceability of this "batch-level" authorization.

[0064] Figure 4 This is a flowchart of a data product delivery synchronization method performed by a data provider according to some embodiments of this application. For example... Figure 4 As shown, the method includes steps S501 to S505. In step S501, delivery baseline parameters are transmitted to the smart contract. These parameters include cryptographic features, a cryptographic aggregation value, encrypted sub-data features, a pre-configured generator of a cyclic group, group elements, and a pairing operation baseline for the pairing function. The encrypted sub-data is the encrypted product sub-data. In step S503, a symmetric key is sent to a trusted custodian. This symmetric key is randomly generated by the data provider when preparing the delivery baseline parameters. In step S505, the encrypted sub-data is sent to the data requester, along with the cryptographic aggregation value, the encrypted sub-data features, and a first transmission parameter. This first transmission parameter is determined based on the generator and the cryptographic parameters, and the cryptographic parameters are randomly generated by the data provider when preparing the delivery baseline parameters.

[0065] As an example, Figure 4 The method shown can be Figure 1 The steps performed by the data provider in the method shown, or in other words, the steps described above, are combined with... Figure 1 The embodiments of the steps performed by the data provider as described in the method shown can be applied to... Figure 4 The method shown will not be elaborated further.

[0066] Figure 5This is a flowchart of a data product delivery synchronization method executed by a smart contract according to some embodiments of this application. In step S601, the delivery baseline parameters transmitted by the data provider are notarized on the blockchain. The delivery baseline parameters include encryption features, a cryptographic aggregation value, cryptographic sub-data features, a pre-configured generator of a cyclic group, group elements, and a pairing operation baseline for the pairing function. The cryptographic sub-data is the product sub-data encrypted by the data provider. In step S603, a receipt sent by the data requester and a cryptographic aggregation value serving as the receipt identifier are received. The receipt includes a receipt parameter v calculated by the data requester based on its private key sk and a private key signature of the cryptographic sub-data. The cryptographic aggregation value is sent by the data provider to the data requester. In step S605, the receipt is notarized, and verification is performed based on the data requester's public key, the notarized cryptographic sub-data features, and the private key signature to determine whether the data requester has received the complete cryptographic sub-data from the data provider. If the verification passes, the symmetric key is obtained from a trusted custodian, as in step S607. If the verification passes, the trusted custodian can be instructed to send the symmetric key to the data requester, as in step S609. However, in an alternative example, step S609 requires both verification and re-verification to pass, with the re-verification being performed by the smart contract.

[0067] As an example, Figure 5 The method shown can be Figure 1 The steps executed by the smart contract in the method shown, or in other words, the steps described above, are combined with... Figure 1 The embodiments of the steps for executing a smart contract described in the method shown can be applied to... Figure 5 The method shown will not be elaborated further.

[0068] Figure 6This is a flowchart of a data product delivery synchronization method performed by a data requester according to some embodiments of this application. In step S701, the system receives encrypted sub-data, a cryptographic aggregation value, encrypted sub-data features, and a first transmission parameter sent by the data provider. The first transmission parameter is determined by the data provider based on a generator and encryption parameters. The encryption parameters are randomly generated by the data provider when preparing delivery baseline parameters. The encrypted sub-data is product sub-data encrypted by the data provider. In step S703, in response to receiving the encrypted sub-data, a receipt is generated. The receipt includes a receipt parameter v calculated based on the data requester's private key sk and a private key signature of the encrypted sub-data. In step S705, using the received cryptographic aggregation value as an identifier, the receipt, including the receipt parameter v and the private key signature, is sent to a smart contract for notarization and receipt verification. In step S707, after obtaining the symmetric key generated by the data provider from a trusted custodian, the encrypted sub-data is decrypted.

[0069] As an example, Figure 6 The method shown can be Figure 1 The steps performed by the data requester in the method shown, or in other words, the steps described above, are combined with... Figure 1 The embodiments of the steps performed by the data requester as described in the method shown can be applied to... Figure 6 The method shown will not be elaborated further.

[0070] Figure 7 This is a schematic diagram of the structure of a data product delivery system according to an embodiment of this application, such as... Figure 7 As shown, the system includes a data provider 80, a smart contract module 82, a trusted custodian 84, and a data requester 86.

[0071] Data provider 80 is configured to execute Figure 5 The method shown. Smart contract module 82 is configured to execute Figure 6 The method shown. Data request side 86 is configured to execute. Figure 7 The method is illustrated. The trusted custodian 84 is configured to receive the symmetric key sent by the data provider 80; upon triggering by the smart contract module 82, it sends the symmetric key to the smart contract module 82; and it sends the symmetric key to the data requester 86.

[0072] Figure 1 The data product delivery synchronization method shown can be provided by Figure 7 The data product delivery system shown is executed. Specifically, Figure 1 Each step performed by the data provider can be executed by the data provider 80; Figure 1 Each step of the smart contract execution can be performed by the smart contract module 82; Figure 1 Each step executed by the trusted custodian can be performed by the trusted custodian (84); the data requester (86) will execute the steps. Figure 1 The steps performed by the data requester in China.

[0073] According to some embodiments of this application, a data provider is also provided, configured to execute the steps, processes, etc., described herein and performed by the data provider. For example, the data provider may include an electronic device or multiple electronic devices capable of communicating with each other. The electronic device may be one or more selected from servers, desktop computers, laptops, tablets, and smart portable terminals. Generally, the data provider includes a processor and a memory. The methods, steps, etc., executable by the data provider according to embodiments of this application can be implemented as program instructions, stored in the memory, and executed by the processor.

[0074] According to some embodiments of this application, a data request terminal is also provided, configured to execute the methods described herein performed by a data requester. As an example, the data request terminal may include an electronic device or multiple electronic devices capable of communicating with each other. The electronic device may be selected from one or more of a server, desktop computer, laptop computer, tablet computer, or smart portable electronic terminal. Generally, the data request terminal includes a processor and a memory. The methods, steps, etc., executable by the data requester according to embodiments of this application can be implemented as program instructions, stored in the memory, and executed by the processor.

[0075] According to some embodiments of this application, a smart contract module is also provided, configured to execute the methods described herein by smart contracts. As an example, this smart contract module is deployed in a blockchain network and internally encapsulates executable program instructions. When the instructions are executed, it can implement all the logic of evidence storage, pairing verification, parameter verification, feature iteration, and instruction issuance that are executed by smart contracts in this specification.

[0076] The data product delivery system according to the embodiments of this application decouples the functions of data transmission and reception, key custody, on-chain cryptographic verification, and distributed evidence storage in a layered manner. Each unit operates independently without interfering with each other, and can process a large number of incremental delivery businesses in parallel, avoiding the single point performance bottleneck caused by the growth of business volume in traditional centralized verification architecture. The entire set of verification, authorization, and key distribution logic is solidified in the blockchain smart contract, and the native performance constraints are formed by relying on the immutable ledger, eliminating the security risks of third-party institutions snooping on data and colluding to commit fraud, and fully realizing batch-level data lineage traceability and non-repudiation and reliable control of delivery behavior.

[0077] According to the embodiments of this application, after receiving data delivery from the data provider, the data requester generates a receipt parameter v based on its own private key and forms a receipt including the receipt parameter, which is then sent to the smart contract for notarization and receipt legality verification. If the data requester does not submit a valid receipt, the smart contract will not trigger the trusted custodian to issue the symmetric key, and the data requester will therefore not be able to obtain full authorization to use the product sub-data. If the data provider uploads forged, mismatched, or tampered benchmark parameters, the verification will fail in the parameter review stage of the smart contract, and the global product feature update will not be completed. False data will not pollute the metadata of the on-chain data product. The data provider and data requester form a closed-loop verification logic with balanced constraints, eliminating the need for offline paper agreements and third-party manual verification, reducing disputes over breach of contract in cross-institutional data collaboration. Therefore, compared with existing technologies, the atomic synchronization method forms a strong binding between receipt and authorization, reducing the trust cost of cross-domain data collaboration.

[0078] After each round of incremental delivery is completed, the smart contracts execute sequentially as follows: Figure 2 Step S300 involves reading the historical global features on the chain; step S301 involves fusing the global features of the parent product, the current batch of sub-data features m, and the demander's public key to complete hash aggregation; and step S302 involves updating the new hash value to the latest global features of the product. The entire iterative record is solidified on the chain in the form of a time-series Merkle tree. Moreover, at any time, the hash relationship can be recalculated using equation (10) to quickly verify the hierarchical relationship between a single batch of sub-data and the original parent data product, without needing to completely store the entire historical plaintext to complete the data ownership verification. Thus, the cryptographic lineage between incremental sub-data and the parent product can be traced.

[0079] Complete authorization records for data products are stored synchronously in blockchain metadata along with the product's unique identifier. When each batch of incremental sub-data undergoes iterations S300 to S302, it inherits the global characteristics of the parent product fixed on-chain from the previous round and participates in hash calculations, synchronously binding the data product authorization relationship to the current batch of product sub-data. All feature iteration records are permanently uploaded to the chain and cannot be tampered with. When authorization compliance verification occurs, the on-chain time-series feature records can be directly retrieved as objective verification evidence, avoiding compliance risks caused by lost authorization records or human tampering.

[0080] Unlike traditional solutions that only retain authorization records at the overall product level, according to the embodiments of this application, each incremental delivery independently performs a round of S300-S302 hash calculations and generates a new block for evidence storage. Each batch of sub-data corresponds to a set of independent hash authorization records and Merkel leaf tree child nodes. In post-event compliance audits and dispute evidence collection scenarios, the characteristics of sub-data, recipient public keys, and delivery timestamps corresponding to a single batch of delivery can be accurately located. The granularity of traceability is refined from the broad overall product to a single incremental delivery batch, achieving refined data flow control across the entire chain.

[0081] From example Figure 1 The steps S100 (supplier parameter preparation), S207 (receipt generation), S209 (pairing verification), and S212 (parameter re-verification) to S300-S302 (feature anchoring update) are all executed automatically and serially by the smart contract module. This eliminates the need for centralized third-party institutions to manually verify each transaction or conduct offline reconciliation. The blockchain's distributed parallel processing of evidence storage and computation tasks avoids the problems of computing power congestion and single-point performance bottlenecks that arise with increasing delivery volume in traditional centralized verification architectures. This shortens the overall processing time for multi-batch, long-cycle continuous data delivery and accelerates the efficiency of cross-entity data element flow.

[0082] In summary, based on blockchain distributed ledger, bilinear pairing cryptography, and Merkle tree temporal feature iteration, this application solves the problems of "inconsistency between delivered data and authorized scope, inability to record and trace delivery behavior, and untrustworthy third-party institutions" in the construction of a trusted data space through three layers of cryptographic constraints: non-repudiation verification of receipts, verification of the authenticity of parameters, and binding of sub-data lineage. The entire automated verification, evidence storage, and authorization synchronization process can be standardized and deployed on data circulation infrastructure, providing a practical and feasible solution for compliant and controllable cross-domain circulation of data elements.

[0083] This application also provides electronic devices, Figure 8 This is a schematic diagram of the electronic device, such as... Figure 8 As shown, the electronic device includes a memory 90 and a processor 92. The memory 90 stores program instructions, which, when executed by the processor 902, enable the implementation of any of the methods described herein.

[0084] This application also provides a computer program product, which includes a program product that, when executed, can implement any of the methods described herein.

[0085] The technical features in the various embodiments of this application can be combined with each other to form new implementation methods without departing from the spirit of this application and without conflicting with each other. Although specific embodiments of this application have been shown and described in detail to illustrate the principles of this application, it should be understood that this application can be implemented in other ways without departing from such principles.

Claims

1. A method for synchronizing the delivery of data products, characterized in that, The method includes: The data provider will transmit the delivery benchmark parameters prepared for the sub-data of the data product to be delivered to the smart contract. The delivery benchmark parameters include encryption features, cryptographic aggregation values, encrypted sub-data features, pre-configured generators of cyclic groups, group elements, and pairing operation benchmarks of pairing functions. The encrypted sub-data is the encrypted sub-data of the product. The smart contract stores the delivery benchmark parameters on the blockchain. The data provider sends a symmetric key to a trusted custodian, the symmetric key being randomly generated by the data provider when preparing the delivery baseline parameters; The data provider delivers encrypted data to the data requester, including sending the encrypted sub-data, the cryptographic aggregation value, the encrypted sub-data features, and a first transmission parameter. The first transmission parameter is determined based on the generator and the encryption parameter. The encryption parameter is randomly generated by the data provider when preparing the delivery baseline parameter. In response to the encrypted delivery, the data requester generates an acknowledgement, which includes an acknowledgement parameter v calculated by the data requester based on its private key sk and a private key signature of the encrypted sub-data. The data requester uses the received cryptographic aggregation value as an identifier and sends the receipt, including the receipt parameter v and the private key signature, to the smart contract for evidence storage and receipt verification. The smart contract stores the receipt and verifies the receipt based on the public key of the data requester, the characteristics of the stored encrypted sub-data, and the signature of the private key to determine whether the data requester has received the complete encrypted sub-data from the data provider. If the verification passes, the smart contract obtains the symmetric key from the trusted custodian; and If the verification passes, the smart contract instructs the trusted custodian to send the symmetric key to the data requester.

2. The method according to claim 1, characterized in that, The method further includes: The smart contract verifies the delivery baseline parameters based on the symmetric key; if the verification passes, the smart contract determines that the encrypted sub-data has been fully received by the data requester.

3. The method according to claim 2, characterized in that, The smart contract verifies the delivery baseline parameters through the following process: The smart contract decrypts the second encryption feature in the encryption features into the cryptographic features of the product sub-data based on the symmetric key; The pairing function is paired based on the cryptographic features of the product sub-data, and the result of the pairing operation is compared with the pairing benchmark of the pairing function in the evidence storage. If the comparison results are consistent, the verification of the benchmark parameters is successful.

4. The method according to claim 2, characterized in that, The smart contract instructs the trusted custodian to send the symmetric key to the data requester only if the verification and the re-verification both pass.

5. The method according to claim 2, characterized in that, If the verification passes, the smart contract decrypts the second encryption feature in the encryption feature into the cryptographic feature of the product sub-data according to the symmetric key; and anchors the cryptographic feature of the product sub-data with the cryptographic feature of the data product.

6. The method according to claim 5, characterized in that, Anchoring the cryptographic features of the product sub-data to the cryptographic features of the data product includes: Based on the unique identifier of the data product, the latest metadata of the data product is retrieved from the blockchain storage, and the cryptographic features of the data product are extracted from the latest metadata. A cryptographic aggregation operation is performed on the cryptographic features of the product sub-data, the cryptographic features of the queried data product, and the public key of the data requester to obtain a new cryptographic aggregation value; The new cryptographic aggregation value is used as a new cryptographic feature of the data product, and blockchain notarization is performed to update the corresponding field in the metadata of the data product.

7. The method according to claim 1, characterized in that, The cryptographic aggregation value is obtained by the data provider performing a cryptographic aggregation operation on the encryption parameters, the symmetric key, and the first encryption feature among the encryption features; the first encryption feature is the value obtained by the data provider encrypting the cryptographic features of the product sub-data using the public key of the data requester; the cryptographic features of the product sub-data are the cryptographic features obtained by the data provider from the product sub-data; and the second encryption feature of the encryption feature is the value obtained by the data provider encrypting the cryptographic features of the product sub-data using the symmetric key.

8. The method according to claim 7, characterized in that, The encrypted sub-data feature is the feature of the encrypted sub-data obtained by the data provider from the encrypted sub-data; the cyclic group includes a first cyclic group G1 and a second cyclic group G2, and correspondingly, the generator includes the generator g1 of the first cyclic group G1 and the generator g2 of the second cyclic group G2; the pairing operation benchmark of the pairing function is the operation result obtained by inputting the generator g1, the generator g2, and the cryptographic features of the product sub-data into the pairing function; the group element is determined according to the public key of the data requester, the encryption parameter k, the generator g2, and the cryptographic features of the product sub-data.

9. The method according to claim 8, characterized in that, The first transmission parameter is determined based on the generator g1 and the encryption parameter k.

10. The method according to any one of claims 1 to 9, characterized in that, The password aggregation algorithm is a hash algorithm, and the password aggregation value is a hash value.

11. A method for synchronizing the delivery of data products performed by a data provider, characterized in that, The method includes: The delivery baseline parameters are transmitted to the smart contract. The delivery baseline parameters include cryptographic features, cryptographic aggregation values, cryptographic sub-data features, pre-configured generators of cyclic groups, group elements, and pairing operation baselines of pairing functions. The cryptographic sub-data is the encrypted product sub-data. The symmetric key is sent to the trusted custodian, and the symmetric key is randomly generated by the data provider when preparing the delivery baseline parameters; The encrypted sub-data is sent to the data requester, along with the cryptographic aggregation value, the encrypted sub-data features, and a first transmission parameter. The first transmission parameter is determined based on the generator and the encryption parameter, and the encryption parameter is randomly generated by the data provider when preparing the delivery baseline parameter.

12. The method according to claim 11, characterized in that, The encryption feature also includes a second encryption feature, provided by the data provider: The cryptographic features of the product sub-data are obtained in advance from the product sub-data; The cryptographic features of the product sub-data are encrypted using the public key of the data demander to obtain the first encrypted feature among the encrypted features; The encryption parameters, the symmetric key, and the first encryption feature are subjected to a cryptographic aggregation operation to obtain the cryptographic aggregation value. The second encryption feature is obtained by encrypting the cryptographic features of the product sub-data with the symmetric key.

13. The method according to claim 12, characterized in that, The cyclic group includes a first cyclic group G1 and a second cyclic group G2. Correspondingly, the generator includes a generator g1 of the first cyclic group G1 and a generator g2 of the second cyclic group G2, as well as the data provided by the data provider. The dense state sub-data features obtained from the dense state sub-data; The pairing operation benchmark is obtained by inputting the generator g1, the generator g2, and the cryptographic features of the product sub-data into the pairing function; the group element is determined based on the public key of the data requester, the encryption parameter k, the generator g2, and the cryptographic features of the product sub-data.

14. The method according to claim 13, characterized in that, The first transmission parameter is determined by the data provider based on the generator g1 and the encryption parameter k.

15. The method according to any one of claims 11 to 14, characterized in that, The password aggregation algorithm is a hash algorithm, and the password aggregation value is a hash value.

16. A method for synchronizing the delivery of data products executed by a smart contract, characterized in that, The method includes: The delivery benchmark parameters transmitted by the data provider are stored on the blockchain. The delivery benchmark parameters include encryption features, cryptographic aggregation values, encrypted sub-data features, pre-configured generators of cyclic groups, group elements, and pairing operation benchmarks of pairing functions. The encrypted sub-data is the product sub-data after being encrypted by the data provider. The system receives a receipt sent by the data requester and a cryptographic aggregate value that serves as the identifier of the receipt. The receipt includes a receipt parameter v calculated by the data requester based on its private key sk and a private key signature of the encrypted sub-data. The cryptographic aggregate value is sent by the data provider to the data requester. The receipt is stored as evidence, and verified based on the public key of the data requester, the characteristics of the stored encrypted sub-data, and the signature of the private key to determine whether the data requester has received the complete encrypted sub-data from the data provider. If the verification passes, the symmetric key is obtained from the trusted custodian; and If the verification passes, the trusted custodian is instructed to send the symmetric key to the data requester.

17. The method according to claim 16, characterized in that, The method further includes: The delivery baseline parameters are verified based on the symmetric key. If the verification passes, it is determined that the dense state sub-data has been fully received by the data requester.

18. The method according to claim 17, characterized in that, The delivery baseline parameters are verified through the following process: Based on the symmetric key, the second encryption feature in the encryption features is decrypted into the cryptographic features of the product sub-data; Using the cryptographic features of the product sub-data obtained through decryption, a pairing operation is performed on the pairing function, and the result of this pairing operation is compared with the pairing operation benchmark of the pairing function stored in the evidence. If the comparison results are consistent, the verification of the benchmark parameters is successful.

19. The method according to claim 17, characterized in that, Only if the verification passes and the re-verification passes, the trusted custodian is instructed to send the symmetric key to the data requester.

20. The method according to claim 17, characterized in that, The method further includes: if the verification is successful, decrypting the second encryption feature in the encryption feature into the cryptographic feature of the product sub-data according to the symmetric key; and anchoring the cryptographic feature of the product sub-data to the cryptographic feature of the data product.

21. The method according to claim 20, characterized in that, Anchoring the cryptographic features of the product sub-data to the cryptographic features of the data product includes: Based on the unique identifier of the data product, the latest metadata of the data product is retrieved from the blockchain storage, and the cryptographic features of the data product are extracted from the latest metadata. A cryptographic aggregation operation is performed on the cryptographic features of the product sub-data, the cryptographic features of the queried data product, and the public key of the data requester to obtain a new cryptographic aggregation value; The new cryptographic aggregation value is used as a new cryptographic feature of the data product, and blockchain notarization is performed to update the corresponding field in the metadata of the data product.

22. The method according to any one of claims 16 to 21, characterized in that, The password aggregation algorithm is a hash algorithm, and the password aggregation value is a hash value.

23. A method for synchronizing the delivery of data products executed by a data requester, characterized in that, The method includes: The system receives encrypted sub-data, cryptographic aggregation value, encrypted sub-data characteristics, and a first transmission parameter sent by a data provider; wherein the first transmission parameter is a parameter determined by the data provider based on the generator and encryption parameter, the encryption parameter is randomly generated by the data provider when preparing delivery benchmark parameters, and the encrypted sub-data is product sub-data encrypted by the data provider. In response to receiving the encrypted sub-data, an receipt is generated, the receipt including a receipt parameter v calculated based on the private key sk of the data requester and a private key signature of the encrypted sub-data; Using the received password aggregation value as an identifier, the receipt, including the receipt parameter v and the private key signature, is sent to the smart contract for evidence storage and receipt verification. After obtaining the symmetric key generated by the data provider from the trusted custodian, the encrypted sub-data is decrypted.

24. A data product delivery system, characterized in that, The data product delivery system includes a data provider, a smart contract module, a trusted custodian, and a data requester, wherein: The data provider is configured as follows: The delivery baseline parameters are transmitted to the smart contract module. The delivery baseline parameters include cryptographic features, cryptographic aggregation values, cryptographic sub-data features, pre-configured generators of cyclic groups, group elements, and pairing operation baselines of pairing functions. The cryptographic sub-data is the encrypted product sub-data. The symmetric key is sent to the trusted custodian, and the symmetric key is randomly generated by the data provider when preparing the delivery baseline parameters; Send the encrypted sub-data to the data requesting end, and send the cryptographic aggregation value, the encrypted sub-data features and the first transmission parameter, wherein the first transmission parameter is determined according to the generator and the encryption parameter, and the encryption parameter is randomly generated by the data provider when preparing the delivery benchmark parameter; The data request side is configured as follows: In response to receiving the encrypted sub-data, an receipt is generated, the receipt including a receipt parameter v calculated by the data requester based on its private key sk, and a private key signature of the encrypted sub-data; Using the received password aggregation value as an identifier, the receipt, including the receipt parameter v and the private key signature, is sent to the smart contract for evidence storage and receipt verification. The smart contract module is configured as follows: The delivery baseline parameters are stored on the blockchain. The receipt is stored as evidence, and verified based on the public key of the data requester, the characteristics of the stored encrypted sub-data, and the signature of the private key to determine whether the data requester has received the complete encrypted sub-data from the data provider. If the verification passes, the symmetric key is obtained from the trusted custodian; and If the verification passes, the trusted custodian is instructed to send the symmetric key to the data requester.

25. The system according to claim 24, characterized in that, The smart contract module is further configured as follows: The delivery baseline parameters are verified based on the symmetric key. If the verification passes, it is determined that the dense state sub-data has been fully received by the data requester.

26. The system according to claim 25, characterized in that, The smart contract module is further configured to verify the delivery baseline parameters through the following process: Based on the symmetric key, the second encryption feature in the encryption features is decrypted into the cryptographic features of the product sub-data; Using the cryptographic features of the product sub-data obtained through decryption, a pairing operation is performed on the pairing function, and the result of this pairing operation is compared with the pairing operation benchmark of the pairing function stored in the evidence. If the comparison results are consistent, the verification of the benchmark parameters is successful.

27. The system according to claim 25, characterized in that, The smart contract module is further configured to instruct the trusted custodian to send the symmetric key to the data requester only if the verification passes and the re-verification passes.

28. The system according to claim 25, characterized in that, The smart contract module is further configured to decrypt the second encryption feature in the encryption feature into the cryptographic feature of the product sub-data according to the symmetric key; and to anchor the cryptographic feature of the product sub-data to the cryptographic feature of the data product.

29. The system according to claim 28, characterized in that, The smart contract module is configured to anchor the cryptographic features of the product sub-data to the cryptographic features of the data product through the following process: Based on the unique identifier of the data product, the latest metadata of the data product is retrieved from the blockchain storage, and the cryptographic features of the data product are extracted from the latest metadata. A cryptographic aggregation operation is performed on the cryptographic features of the product sub-data, the cryptographic features of the queried data product, and the public key of the data requester to obtain a new cryptographic aggregation value; The new cryptographic aggregation value is used as a new cryptographic feature of the data product, and blockchain notarization is performed to update the corresponding field in the metadata of the data product.

30. The system according to claim 24, characterized in that, The data provider is configured as follows: The cryptographic features of the product sub-data are obtained in advance from the product sub-data; The cryptographic features of the product sub-data are encrypted using the public key of the data demander to obtain the first encrypted feature among the encrypted features; The encryption parameters, the symmetric key, and the first encryption feature are subjected to a cryptographic aggregation operation to obtain the cryptographic aggregation value. The second encryption feature is obtained by encrypting the cryptographic features of the product sub-data with the symmetric key.

31. The system according to claim 30, characterized in that, The data provider is pre-configured with a first cyclic group G1 and a second cyclic group G2. Correspondingly, the generator includes a generator g1 of the first cyclic group G1 and a generator g2 of the second cyclic group G2. The data provider is configured as follows: The dense state sub-data features obtained from the dense state sub-data; The pairing operation benchmark is obtained by inputting the generator g1, the generator g2, and the cryptographic features of the product sub-data into the pairing function; the group element is determined based on the public key of the data requester, the encryption parameter k, the generator g2, and the cryptographic features of the product sub-data. The first transmission parameter is determined by the generator g1 and the encryption parameter k.

32. The system according to any one of claims 24 to 31, characterized in that, The password aggregation algorithm is a hash algorithm, and the password aggregation value is a hash value.

33. A data provider, characterized in that, The data provider is configured to perform the method according to any one of claims 11 to 15.

34. The data providing terminal according to claim 33, characterized in that, The data provider includes one or more electronic devices that can communicate with each other, and the electronic devices are one or more of a server, desktop computer, laptop computer, tablet computer, or smart portable electronic terminal.

35. A data demand side, characterized in that, The data request side is configured to execute the method according to claim 23.

36. The data demand side according to claim 35, characterized in that, The data demand side includes one or more electronic devices that can communicate with each other, and the electronic devices are one or more of servers, desktop computers, laptops, tablets, and smart portable electronic terminals.

37. A smart contract module, characterized in that, The smart contract module is configured to execute the method according to any one of claims 16 to 22.

38. A computer program product, characterized in that, The computer program product includes a program product that, when executed, can implement the method according to any one of claims 1 to 23.

39. An electronic device, characterized in that, The electronic device includes: Memory, used to store program products; A processor for executing an operation program product to implement the method according to any one of claims 1 to 23 during execution.

Images