Product data processing method, device, program product, and electronic device
Patent Information
- Application Number
- CN202610911117.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-23
- Publication Date
- 2026-10-16
AI Technical Summary
[0006]本申请提供了一种产品数据的处理方法、装置、程序产品以及电子设备,以至少解决交互方在对产品数据进行处理的过程中,数据安全度低的技术问题
[0017] In this application, a blockchain node and a trusted platform are first deployed for the parties interacting with product data. These parties include a provider and a user. The user's blockchain node and the provider's blockchain node are connected via a blockchain network. The trusted platform is used at least to manage the product catalog, manage smart contracts, and control the use of product data. Then, within the trusted environment provided by the trusted platform, the signing of smart contracts between the parties is executed. After the smart contract signing is completed and the user pays the provider for the product, the product data corresponding to the product in the provider's local database is uploaded to a first smart contract. The first smart contract is a smart contract running on the provider's blockchain node. Subsequently, the product data is transmitted to a second smart contract via a preset link through the first smart contract, and the product data is encrypted using the second smart contract to obtain encrypted data. The second smart contract is a smart contract running on the user's blockchain node.
Smart Images

Figure CN122926458A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of blockchain technology or other related technical fields. Specifically, it relates to a method, apparatus, program product, and electronic device for processing product data. Background Technology
[0002] Existing technologies offer various solutions for implementing trusted data space, but current mainstream products and solutions suffer from the following two problems:
[0003] First, there is a technological fragmentation. Different application scenarios have different security requirements. Existing technologies can simply choose one of the following technologies—trusted execution environment, encrypted computation, secure multi-party computation, or federated learning—to achieve the goal of making interactive data usable but invisible, depending on the application scenario. Alternatively, data sandboxes can be selected, combined with data anonymization, access control, and usage control technologies to improve the security of interactive data. However, this approach has relatively weak data security protection capabilities. If multiple technologies are combined and blockchain is simply added for notarization and smart contracts for rights verification, although this can achieve a balance between different data security levels and data processing efficiency to a certain extent, the management functions of these technologies are redundant, and it is difficult to integrate the technologies into a whole. Seamless integration between different technologies is also difficult, resulting in a wide range of attack exposure.
[0004] Secondly, true secure data delivery is impossible. For example, traditional client-server (CS) based solutions can deliver data to the local user, allowing on-demand use and remote control by the provider to ensure security. However, users cannot trust the data usage process. For instance, with mobile apps, the app collects user behavior and input data and transmits it to the server for analysis, infringing on user privacy. Emerging solutions like privacy computing, such as secure multi-party computation and federated learning, do not deliver data directly and therefore cannot be used offline. Trusted execution environments suffer from centralized issues due to reliance on trusted third parties, requiring further solutions. Encrypted computation has limited functionality, only usable in specific situations. Data sandboxes present issues with administrators having superuser privileges.
[0005] There is currently no effective solution to the above problems. Summary of the Invention
[0006] This application provides a method, apparatus, program product, and electronic device for processing product data, in order to at least solve the technical problem of low data security during the processing of product data by the interacting parties.
[0007] According to one aspect of this application, a method for processing product data is provided, comprising: deploying blockchain nodes and a trusted platform for the parties interacting with the product data, wherein the parties interacting include a provider and a user, the blockchain nodes of the user and the provider are connected through a blockchain network, and the trusted platform is used at least to implement product catalog management operations, smart contract management operations, and product data usage control operations; executing the signing operation of a smart contract between the parties in a trusted environment provided by the trusted platform; after the smart contract signing operation is completed and the user pays the provider for the product, uploading the product data corresponding to the product in the provider's local database to a first smart contract, wherein the first smart contract is a smart contract running in the provider's blockchain node; transmitting the product data to a second smart contract through the first smart contract based on a preset link, and encrypting the product data through the second smart contract to obtain encrypted data, wherein the second smart contract is a smart contract running in the user's blockchain node.
[0008] Optionally, after the product data is transmitted to the second smart contract via the first smart contract through a preset link, the product data processing method further includes: uploading user data from the user's local database to the second smart contract; and performing data fusion on the user data and the received product data through the second smart contract to obtain the target data.
[0009] Optionally, after the product data is transmitted to the second smart contract via a preset link through the first smart contract, the product data processing method further includes: after the second smart contract receives the user's data usage request and verifiable credentials, it performs signature verification on the verifiable credentials through the second smart contract; after the verifiable credentials pass signature verification, it parses the verifiable credentials through the second smart contract to obtain a digital contract strategy, wherein the digital contract strategy is used to characterize the constraints in the process of controlling the use of product data; it checks whether the data usage request submitted by the user meets the constraints corresponding to the digital contract strategy; if the data usage request meets the constraints corresponding to the digital contract strategy, it generates return data based on the data usage request and encrypted data through the second smart contract, and sends the return data to the user.
[0010] Optionally, after detecting whether the data usage request submitted by the user meets the constraints corresponding to the digital contract strategy, the product data processing method further includes: if the data usage request does not meet the first constraint and / or the second constraint corresponding to the digital contract strategy, performing a destruction operation on the encrypted data through a second smart contract, wherein the first constraint is used to indicate that the number of times the user uses data is greater than or equal to the preset number of times, and the second constraint is used to indicate that the time when the user initiates the data usage request exceeds the preset usage time window.
[0011] Optionally, after deploying blockchain nodes and a trusted platform for the parties interacting with the product data, the product data processing method further includes: uploading the product data corresponding to all products in the provider's local database to the provider's blockchain node; performing hash calculations on the uploaded product data corresponding to all products through the provider's blockchain node to obtain the hash value of each product; generating a product catalog based on the hash value of each product and the description data of each product; and transmitting the product catalog to the blockchain network for storage.
[0012] Optionally, before executing the smart contract signing operation between the interacting parties, the product data processing method further includes: when the user needs to use products in the product catalog, the provider and the user jointly determine a digital contract strategy, wherein the constraint parameters in the constraints corresponding to the digital contract strategy include at least one of the following: the user's identity identifier, a preset usage time window, a preset number of uses, a preset application scope, a preset location, and a preset data processing mode; the user generates a digital contract request based on the digital contract strategy and sends the digital contract request to the provider; after the digital contract request passes the provider's verification operation, the provider generates the source code of the smart contract based on the digital contract strategy carried in the digital contract request; the provider issues a verifiable credential to the user based on the digital contract strategy carried in the digital contract request using its digital identity; and the verifiable credential and the source code of the smart contract are sent to the user.
[0013] Optionally, within a trusted environment provided by a trusted platform, the signing operation of the smart contract between the interacting parties is performed, including: starting the trusted environment on the trusted platform of the provider and the trusted platform of the user; in the trusted environment of the user, performing a hash calculation on the source code sent by the provider to obtain a first hash value, and comparing the first hash value with a second hash value to obtain a comparison result, wherein the second hash value is the hash value of the digital contract strategy jointly determined by the user and the provider in advance; if the comparison result indicates that the first hash value and the second hash value are consistent, digitally signing the comparison result with the digital identity of the user to obtain a remote proof report; sending the remote proof report from the trusted space of the user to the trusted space of the provider; in the trusted environment of the provider, performing signature verification and hash verification on the remote proof report sent by the user; and after the remote proof report passes the signature verification and hash verification of the provider, completing the signing operation of the smart contract between the interacting parties.
[0014] According to another aspect of this application, a product data processing apparatus is also provided, comprising: a deployment unit for deploying blockchain nodes and a trusted platform for the parties interacting with the product data, wherein the parties interacting include a provider and a user, the blockchain nodes of the user and the provider are connected through a blockchain network, and the trusted platform is used to at least implement product catalog management operations, smart contract management operations, and product data usage control operations; a signing unit for executing the signing operation of a smart contract between the parties in a trusted environment provided by the trusted platform; a first upload unit for uploading product data corresponding to the product in the provider's local database to a first smart contract after the smart contract signing operation is completed and the user pays the provider for the product, wherein the first smart contract is a smart contract running in the provider's blockchain node; and a first processing unit for transmitting the product data to a second smart contract through the first smart contract based on a preset link, and encrypting the product data through the second smart contract to obtain encrypted data, wherein the second smart contract is a smart contract running in the user's blockchain node.
[0015] According to another aspect of this application, a computer program product is also provided, which stores a computer program, wherein a method for processing product data of any of the above-mentioned items is provided when the computer program is running.
[0016] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the product data processing method described above.
[0017] In this application, a blockchain node and a trusted platform are first deployed for the parties interacting with product data. These parties include a provider and a user. The user's blockchain node and the provider's blockchain node are connected via a blockchain network. The trusted platform is used at least to manage the product catalog, manage smart contracts, and control the use of product data. Then, within the trusted environment provided by the trusted platform, the signing of smart contracts between the parties is executed. After the smart contract signing is completed and the user pays the provider for the product, the product data corresponding to the product in the provider's local database is uploaded to a first smart contract. The first smart contract is a smart contract running on the provider's blockchain node. Subsequently, the product data is transmitted to a second smart contract via a preset link through the first smart contract, and the product data is encrypted using the second smart contract to obtain encrypted data. The second smart contract is a smart contract running on the user's blockchain node.
[0018] As described above, this application employs a combination of blockchain networks, trusted environments, and smart contracts. By deploying a trusted platform as a service platform to provide a trusted space for the parties interacting with product data, and deploying blockchain nodes as access connectors for this trusted space, smart contracts are used to execute the signing and encryption operations of the delivered product data within the trusted environment. This securely delivers the provider's local product data to the user's trusted environment via a pre-defined link, achieving a controllable secure delivery process of product data from the provider to the user while ensuring product data security. This avoids the technical drawbacks of redundant construction of systems with different technical architectures and the wide range of security attacks, thereby preventing product data leakage and misuse, and ensuring that the user can trust the process of using the product data. Ultimately, this solves the technical problem of low data security during the product data processing process by the parties interacting with the product data. Attached Figure Description
[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0020] Figure 1 This is a hardware structure block diagram of an optional computer terminal (or mobile device) for implementing a product data processing method according to an embodiment of this application.
[0021] Figure 2 This is a flowchart of an optional product data processing method according to an embodiment of this application;
[0022] Figure 3 This is an architecture diagram of an optional blockchain BaaS platform according to an embodiment of this application;
[0023] Figure 4 This is an architecture diagram of an optional trusted space access connector according to an embodiment of this application;
[0024] Figure 5 This is an architecture diagram of an optional product data processing system according to an embodiment of this application;
[0025] Figure 6 This is a schematic diagram of an optional product data processing apparatus according to an embodiment of this application;
[0026] Figure 7 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0027] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0029] It should also be noted that all information and data (including but not limited to information used for display and analysis) involved in this application are authorized by the user or fully authorized by all parties. For example, if there is an interface between this system and the relevant user or organization, before obtaining the relevant information, it is necessary to send a request to the aforementioned user or organization through the interface, and obtain the relevant information only after receiving consent from the aforementioned user or organization.
[0030] Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of relevant information and data involved in this application all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary security measures have been taken. They do not violate public order and good morals. In addition, this application provides corresponding operation entry points for users to choose to agree to authorization or refuse authorization. If the user chooses to refuse authorization, the corresponding expert decision-making process will be initiated.
[0031] The present invention will now be described in detail with reference to various embodiments.
[0032] Example 1
[0033] According to an embodiment of this application, an embodiment of a product data processing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0034] The method embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of an optional computer terminal (or mobile device) for implementing a product data processing method according to an embodiment of this application. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0035] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).
[0036] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the product data processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned product data processing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0037] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0038] The display can be configured as a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).
[0039] Under the aforementioned operating environment, this application provides a product data processing system (hereinafter referred to as the processing system) for executing the product data processing method of this application. Figure 2 This is a flowchart of an optional product data processing method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:
[0040] Step S201: Deploy blockchain nodes and a trusted platform for the parties interacting with product data. The parties interacting with product data include the provider and the user. The blockchain nodes of the user and the provider are connected through a blockchain network. The trusted platform is used to implement at least the management operations of the product catalog, the management operations of smart contracts, and the operation of controlling the use of product data.
[0041] Optionally, a blockchain network is used to establish a communication network for participants in a trusted data space to achieve peer-to-peer collaborative processing.
[0042] Alternatively, a trusted platform, namely a blockchain-based financial trusted data space service platform (referred to as a blockchain BaaS (Blockchain as a Service) platform). Figure 3 This is an architecture diagram of an optional blockchain BaaS platform according to an embodiment of this application, such as... Figure 3 As shown, the trusted platform has functional modules for identity (DID) management, access connector (blockchain node, hereinafter referred to as node) management, directory management, digital contract (i.e., smart contract) management, trusted data space / network management, data usage control, and international space interconnection gateway. Among them, the identity management module supports the registration, update, authentication, and deregistration of the identities of the interacting parties; the access connector management module supports the registration / deregistration, operation monitoring, node authentication, and capability adaptation functions of blockchain nodes; the target management module supports product registration, product catalog, and service catalog management functions, and can accept user applications; the trusted data space / network management module supports the creation / deletion of trusted environments, trusted space member management, configuration modification, and operation monitoring functions; the digital contract management module supports the management functions of the policy module and the filing, signing, and termination of smart contracts; and the data usage control module supports data usage environment detection, control policy execution, and data usage evidence storage functions.
[0043] In this embodiment, the target management module is mainly used to provide registration services for data products, compile data catalogs, and provide data product query services to the outside world by sharing the data catalogs on the blockchain.
[0044] In this embodiment, the aforementioned digital contract management module is mainly used to assist data providers and users in completing supply and demand matching and contract signing. In the blockchain field, there are multiple implementation schemes for digital contracts. One is to use a digital identity verifiable credential template as the strategy template for the digital contract. The data user submits a data usage application, and the data provider signs the verifiable credential, i.e., the contract signing, according to the agreement between the two parties. Then, the smart contract verifies the credential and executes the data usage logic according to the requirements stipulated in the credential. The second is to directly use a smart contract template as the strategy template for the digital contract. The provider and user jointly discuss and develop a smart contract that meets the requirements of both parties based on the contract template, generating the final smart contract, i.e., the contract signing.
[0045] In this embodiment, the aforementioned data usage control module is mainly used to support data providers and data users in controlling data usage according to digital contract requirements using the capabilities provided by the platform. In the blockchain field, corresponding to digital contract solutions based on digital identity verification credentials or smart contract templates, the core is implemented through smart contracts. In terms of the data usage environment, hardware can be combined with Trusted Environment (TEE) technology to achieve confidentiality and integrity. On the software side, blockchain smart contracts themselves also have integrity and availability security features such as multi-node deployment and content consistency. At the same time, the mandatory execution feature of smart contracts can ensure the execution of control strategies, and usage records can be directly stored through the blockchain.
[0046] Optionally, the processing system will act as an access connector (hereinafter referred to as connector) for the blockchain nodes deployed by the interacting parties in the trusted space. Figure 4 This is an architecture diagram of an optional trusted space access connector according to an embodiment of this application, such as... Figure 4 As shown, the access connector supports standard capabilities of general clients such as identity authentication, network access, access control, log recording, and operation status reporting. In addition, the access connector in this embodiment extends the functions for product data circulation scenarios to include: data delivery, data resource management, data product management, digital contract management, and data usage control.
[0047] In this embodiment, data resource management mainly involves enabling data providers to load data resources from the data system into the access connector. In the blockchain field, smart contracts can, on the one hand, acquire off-chain local multi-source heterogeneous data resources through oracle technology for subsequent delivery and use; on the other hand, they can put data resources on the chain through hashing, storing resource description information on the chain to form a data resource catalog, supporting retrieval and querying.
[0048] In this embodiment, data product management primarily enables data providers to select some or all of the data from the accessed data resources, encapsulate it into data products, configure data usage policies, and provide data users with local data product retrieval and usage application services. Building upon the aforementioned blockchain-based data resource management, defining the scope of data resources and configuring data usage policies can be achieved by smart contracts reading parameters, product retrieval can directly search on-chain data, and usage applications can be made through interaction after both parties establish a communication connection.
[0049] In this embodiment, digital contract management in the access connector refers to enabling data providers and data users to directly sign digital contracts through the access connector and manage the signed digital contracts. Unlike service platforms that focus on contract strategy templates, signing, filing, and termination, the access connector emphasizes contract creation, contract negotiation, and contract performance. In blockchain-based solutions, this translates to the deployment and operation of smart contracts. Smart contract deployment requires simultaneous deployment by both the data provider and the data user to ensure data transmission from the provider to the user. Simultaneously, logs are recorded and evidence is stored during the user's execution, and information is synchronized to and monitored by the provider. Therefore, the deployment and operation of smart contracts must be completed jointly by all parties involved in the contract.
[0050] In this embodiment, data delivery primarily involves the data provider transmitting and processing raw data, anonymized data, or computational results data according to digital contract requirements via an access connector. In a blockchain-based solution, secure peer-to-peer transmission can be achieved through a smart contract jointly deployed by the data provider and data user. The raw data undergoes preprocessing such as anonymization before being sent from the data provider to the data user. Subsequently, the data user's smart contract aggregates and processes the data, ultimately returning the final result data, which does not reveal the original data, to the data user.
[0051] In this embodiment, data usage control primarily supports data providers and users in providing data according to digital contract requirements and controlling its use. The service platform focuses on managing the usage environment and policies, and monitoring their execution. The access connector, on the other hand, focuses on the effective operation of the usage environment and policies, as well as the accurate and complete recording of their execution. In the blockchain-based solution, the Trusted Execution Environment (TEE) invoked by blockchain nodes provides a confidential and secure hardware operating environment for smart contracts, while the smart contracts provide a trusted and secure software operating environment for data usage. Simultaneously, the smart contracts enforce control policies and ensure the traceability and evidence storage of behavioral records.
[0052] As shown in step S201, the processing system uses the blockchain BaaS platform as a service platform and blockchain nodes as access connectors to unify data access control, usage control and other functions within the blockchain framework. This avoids the problems of redundant system construction and complex interfaces caused by simply stacking different security components (such as TEE, cryptographic computation, etc.) in traditional solutions, effectively reducing the attack exposure surface. Furthermore, the processing system realizes standardized registration of data products and digital management of contracts through directory management and smart contract management modules, laying a unified foundation for the subsequent trusted circulation of data. At the same time, the processing system provides a decentralized and tamper-proof communication and recording network through the blockchain network, ensuring the credibility and traceability of the interaction records of all parties, and providing a basic trust environment for collaboration among multiple parties.
[0053] Step S202: In the trusted environment provided by the trusted platform, the signing operation of the smart contract between the interacting parties is performed.
[0054] Optionally, smart contracts possess many characteristics applicable to a trusted space for product data, including: First, open source, allowing data providers and users to jointly develop smart contracts, much like jointly signing a digital contract; second, peer-to-peer, enabling data providers and users to jointly deploy and execute smart contracts, just as digital contracts are backed up by relevant stakeholders; third, programmability, providing a data development and utilization environment that allows smart contracts to be applied to different data circulation and usage scenarios, including encoding data usage logic within the contract to achieve data usage control, and integrating privacy computing, big data, and artificial intelligence (AI) functions to provide diversified data services; fourth, mandatory and automatic execution, ensuring effective performance and protecting the rights and interests of data providers and users; and fifth, evidence preservation and traceability, as a carrier of data throughout its entire lifecycle in a trusted data space, smart contracts can directly preserve and trace various data operations, and utilize the blockchain's chain data structure to prevent illegal tampering, providing a standard-compliant legal basis for regulatory audits and dispute arbitration.
[0055] In this embodiment, smart contract code serves as the digital contract for the trusted data space. The code uses global variables or parameters to describe the expected commitments of relevant participants, such as data providers, data users, and data service providers, regarding data circulation and usage, which can vary depending on the scenario. The smart contract template, published by the data provider, serves as the strategy template for the digital contract. The data user selects the strategy template as needed and, after negotiating and determining specific parameter variables with the data provider, jointly completes the development of the final smart contract code. Simultaneously, a hash of the smart contract code is calculated to prevent tampering, thus completing the digital contract signing between the two parties. Before the data user uses the data product, both the data provider and the data user must deploy the corresponding hashed smart contract on the blockchain node, completing the creation of the connector's digital contract. Finally, when using data, the data user sends a data usage request to the smart contract. The smart contract checks the data usage request according to the strategy defined by the global variables. Then, the smart contract on the data provider's side obtains the local data and sends it to the smart contract on the data user's side. The smart contract on the data user's side executes the corresponding SQL (Structured Query Language) or other data services according to the data usage request, and then returns the processing result to the data user, completing the fulfillment of the digital contract. During this process, the contracts deployed by both parties will run simultaneously, which can record the entire process of data use and ensure compliant data use.
[0056] Optionally, a trusted execution environment (or simply trusted environment) refers to a security architecture based on hardware and operating system.
[0057] In this embodiment, a portion of the memory address of the CPU (processor) is allocated as a secure space to construct a secure computing environment isolated from the outside world. This environment is used for confidential computing, processing sensitive data, and protecting the smart contracts running within it from attacks such as eavesdropping and tampering. It provides remote proof and measurement of the code. Through measurement, the state of the smart contracts running on it can be collected and compared with reference values to determine whether the smart contracts have been tampered with. Through remote authentication, trusted software and hardware sign and endorse the measurement results using an internal private key and send them to a remote data provider to verify the trustworthy state of the smart contracts. Therefore, through remote proof and measurement, the data provider can remotely determine whether the smart contracts performing data processing on the data user side are trustworthy.
[0058] As shown in step S202, this step realizes the trusted binding of digital contract code implementation and execution environment. By jointly signing the smart contract, it ensures that the data provider and data user are executing the exact same logic code, eliminating performance disputes caused by inconsistent code versions. At the same time, the processing system utilizes the remote proof and measurement technology of TEE, allowing the data provider to remotely confirm that the smart contract being executed on the data user's side is indeed the agreed and tamper-proof version. This solves the problem in traditional CS architecture where the data user cannot trust the data usage process (such as data collection in the APP background), enabling the data provider to be confident that the data is being processed in a secure and controlled environment. Furthermore, the processing system deploys the smart contract in the TEE, using hardware isolation to protect the contract code and data from interference and theft by malicious applications in the main operating system, ensuring the confidentiality and integrity of the contract execution logic.
[0059] Step S203: After completing the smart contract signing operation and the user pays the provider for the product, the product data corresponding to the product in the provider's local database is uploaded to the first smart contract, wherein the first smart contract is a smart contract running in the provider's blockchain node.
[0060] As shown in step S203, this step achieves a controlled migration of data from the local private environment to a trusted circulation environment. Product data is only accessed by the first smart contract within the provider's TEE environment, rather than being directly exposed to the user or the blockchain network. Only after verification by the contract logic will the data be further processed or original data fragments transmitted (if necessary), ensuring the security of the provider's core data. Furthermore, the processing system uses payment confirmation as a prerequisite for uploading local product data and records it through the blockchain, ensuring the fairness of the transaction and achieving a closed-loop transaction. After the product data corresponding to the traded product enters the first smart contract, it is protected by TEE hardware isolation. Even if the provider's system administrator has permissions, they cannot directly read the data within the TEE, thus achieving the goal of the data provider being able to remotely control data usage and ensure data security.
[0061] Step S204: The product data is transmitted to the second smart contract through the first smart contract based on the preset link, and the product data is encrypted through the second smart contract to obtain encrypted data. The second smart contract is a smart contract running in the user's blockchain node.
[0062] Optionally, the preset link refers to the encrypted communication link between smart contracts, used for the secure transmission of product data between smart contracts.
[0063] As shown in step S204, this step ensures the secure delivery of product data, addressing the technical pain point of traditional solutions where data users cannot trust the usage process. Data is directly transmitted from the provider's TEE to the user's TEE, achieving the technical effect of delivering data to the user's local machine. This allows users to flexibly use data as needed, while the data is not exposed in plaintext to insecure areas on the user's local machine. For the provider, data transmission and processing within the TEE prevents interception or misuse. For the user, data processing within their own TEE ensures that the provider cannot access other data or usage activities on their local machine, and the user need not worry about data being stolen by their local administrator. Furthermore, the entire data transmission and processing process is recorded by a smart contract and stored on the blockchain, achieving full traceability and auditability of data usage, thus meeting regulatory and auditing requirements.
[0064] As described above, this application employs a combination of blockchain networks, trusted environments, and smart contracts. By deploying a trusted platform as a service platform to provide a trusted space for the parties interacting with product data, and deploying blockchain nodes as access connectors for this trusted space, smart contracts are used to execute the signing and encryption operations of the delivered product data within the trusted environment. This securely delivers the provider's local product data to the user's trusted environment via a pre-defined link, achieving a controllable secure delivery process of product data from the provider to the user while ensuring product data security. This avoids the technical drawbacks of redundant construction of systems with different technical architectures and the wide range of security attacks, thereby preventing product data leakage and misuse, and ensuring that the user can trust the process of using the product data. Ultimately, this solves the technical problem of low data security during the product data processing process by the parties interacting with the product data.
[0065] In one optional embodiment, after the product data is transmitted to the second smart contract via the first smart contract through a preset link, the processing system uploads the user data from the user's local database to the second smart contract. Then, the second smart contract performs data fusion on the user data and the received product data to obtain the target data.
[0066] Optionally, data fusion refers to the process of combining, associating, or performing calculations on received product data (from the data provider) and locally uploaded user data (from the data user) within the runtime environment of the second smart contract.
[0067] Optionally, the user can upload its local data (i.e., user data) to the smart contract by calling the local smart contract, thereby realizing the data fusion of the two parties. The fused target data can be used for data statistics, comparison and other application scenarios. Since the data of the two parties are truly fused together, it can handle higher data security requirements than specific algorithms such as multi-party secure computation or federated learning.
[0068] In one optional embodiment, after the product data is transmitted to the second smart contract via a preset link through the first smart contract, the processing system, upon receiving the user's data usage request and verifiable credentials from the user in the second smart contract, verifies the signature of the verifiable credentials through the second smart contract. After the verifiable credentials pass signature verification, the system parses the verifiable credentials through the second smart contract to obtain a digital contract strategy. This digital contract strategy characterizes the constraints in the product data usage control process. Then, the system checks whether the user's data usage request meets the constraints corresponding to the digital contract strategy. Subsequently, if the data usage request meets the constraints corresponding to the digital contract strategy, the system generates return data based on the data usage request and encrypted data through the second smart contract and sends the return data to the user.
[0069] Optionally, the digital contract strategy design in the verifiable credential can be implemented using JSON (JavaScript object representation) combined with the 4W2H (6W2H analysis) model. The 4W2H model defines the constraints that control the data user (Who) and the specific time (When) and location (Where) to process data according to the agreed application scope (HowTo) and frequency (How Many). For the attributes of each constraint parameter, metadata can be provided through regular expressions, offering scalability. For example, regarding "Do What," a list can be presented to allow users to select different SQL processing methods, as shown in the following example:
[0070] {
[0071] "cptId": "template id",
[0072] "issuanceDate": "Issuance Date",
[0073] "signature": "signature",
[0074] "proofType": "cryptographic algorithm",
[0075] "context": "DID template",
[0076] "claim": {
[0077] "doWhat": "Using control: what is allowed to be done",
[0078] "howMany": Use control: number of times,
[0079] "howTo": "Usage Controls: Applications",
[0080] "when": "Using control: time range",
[0081] "where": "Use control: location range",
[0082] "who": "Usage Control: Data User DID"
[0083] },
[0084] "id": "credential ID",
[0085] "proof": {
[0086] "creator": "credential issuing user",
[0087] "signature": "User signature for issuing the certificate",
[0088] "created": "Time of voucher issuance",
[0089] "type": "credential issuance password algorithm"
[0090] },
[0091] "hash": "credential hash",
[0092] "expirationDate": "Voucher expiration date"
[0093] }
[0094] Optionally, when using data, the user sends a data usage request and a verifiable credential that has been signed and authorized to the local smart contract. The smart contract verifies the signature validity of the verifiable credential and checks whether the data usage request conforms to the digital contract policy in the verifiable credential. For example, the Who policy can use distributed digital identity (DID) for authentication; the When policy can use the time on the blockchain for judgment; the Where and How To policies can assign digital identities to devices and applications, with the terminal signing and endorsing to determine the location and application; and the How Many policy can use the blockchain to store and accumulate counters. After the policy verification is successful, the smart contract executes the corresponding SQL instructions or other data services according to the SQL identifier specified in the data usage request. Then, it returns the processing result to the data user without disclosing the original data, completing the digital contract fulfillment. In this process, the smart contract can store the entire data usage process and broadcast it through the blockchain network to ensure compliant data use.
[0095] Optionally, after receiving a request, the second smart contract executes a complete process of signature verification, policy parsing, request verification, calculation execution, and result return. The technical effects that can be achieved include: (1) Achieving fine-grained automated usage control: By parsing verifiable credentials to obtain digital contract policies, the second smart contract can automatically verify each data usage request of the user based on the constraints in the policy (such as Who, When, Where), thereby transforming the digital contract from a static text agreement into a dynamic, code-enforced logic. Only when the data usage request fully meets the policy constraints is the data operation allowed to be executed, solving the technical problem of the control policy relying on manual supervision in the prior art, realizing the fine-grained control and automated measurement of the data usage process, and ensuring that the data provider can remotely and in real time control the data usage boundary; (2) Enhancing two-way trust: By signing and verifying verifiable credentials, the legality of the data source and the integrity of the credentials are ensured, preventing the execution of forged or tampered contract policies. At the same time, the second smart contract runs in a trusted environment. In the environment, its execution process is protected by hardware isolation, avoiding interference from system administrators or unauthorized programs of the data user. This allows the data user to be sure that the data provider will not steal data by tampering with the contract logic in the background, and the data provider can also be sure that the data user has not bypassed the contract policy to illegally use the data. This mechanism based on cryptographic proof and hardware root of trust solves the problem of data user not trusting the server in the CS mode and mutual distrust between the two parties in the privacy computing scheme; (3) Implement a usable but invisible data delivery mode: the encrypted data is directly processed locally through the second smart contract (such as executing SQL) and the result is returned, instead of transmitting the original data. This realizes the real data delivery to the user's local area, while the original data does not leave the TEE security space. Compared with the schemes such as secure multi-party computation or federated learning that require complex interaction and cannot be used offline, this embodiment allows the user to run general data service logic directly in the local TEE environment, supports users to use it on demand, has a wider range of applicable scenarios, and avoids the risk of leakage of original sensitive data.
[0096] In one optional embodiment, after detecting whether the data usage request submitted by the user meets the constraints corresponding to the digital contract strategy, and if the data usage request does not meet the first constraint and / or the second constraint corresponding to the digital contract strategy, the encrypted data is destroyed through the second smart contract. The first constraint is used to indicate that the number of times the user uses data is greater than or equal to the preset number of times, and the second constraint is used to indicate that the time when the user initiates the data usage request exceeds the preset usage time window.
[0097] Optionally, when the user reaches the maximum preset number of uses or preset time window, the smart contract completes the data lifecycle closed loop by executing data destruction. The technical effects that can be achieved include: (1) reducing the risk of human intervention: In traditional technology, data destruction often relies on manual operation or external management system instructions, which has a lag. In this embodiment, the second smart contract deployed in the TEE automatically triggers the destruction process based on the immutable timestamp on the blockchain (used to judge the second constraint condition) and the number of uses counted on the chain (used to judge the first constraint condition), ensuring that the data is cleaned up immediately and irreversibly when the agreed conditions are met, without the need for human intervention, thus improving the efficiency and consistency of data lifecycle management; (2) preventing privacy leakage caused by excessive use: By setting the first constraint condition (maximum number of uses) and the second constraint condition (time window), this embodiment transforms the policy restrictions of the digital contract into automatically executed hardware-level security actions. Once the agreed scope is exceeded, the data is immediately destroyed, eliminating the possibility of the data user continuing to use the data beyond the contract validity period or number of uses. Combined with the confidentiality protection provided by TEE, even if the system administrator of the data user has operating system privileges, they cannot steal the original encrypted data before destruction, thus truly realizing the remote control and risk blocking of the data usage process by the data provider; (3) Improve the trust in data circulation and meet compliance audit requirements: The execution process and destruction results of smart contracts can be stored and traced through the blockchain network. When the destruction operation occurs, the event and its triggering reason (such as the number of uses being exhausted or timeout) will be recorded on the blockchain. This provides audit basis for data providers and regulatory agencies, proving that the data has been destroyed in accordance with regulations after it expires or is exhausted, without causing persistent data retention risks, thereby enhancing the trust of data users in the security and reliability of the data usage process and promoting the safe and efficient circulation of data elements.
[0098] In one optional embodiment, after deploying blockchain nodes and a trusted platform for the parties interacting with product data, the processing system uploads all product data corresponding to all products in the provider's local database to the provider's blockchain node. Then, the provider's blockchain node performs hash calculations on all the uploaded product data to obtain the hash value of each product. Subsequently, a product catalog is generated based on the hash value and description data of each product, and then the product catalog is transmitted to the blockchain network for storage.
[0099] Optionally, after deploying blockchain nodes and a trusted platform for the parties interacting with product data, the processing system first generates digital identities for the parties on the blockchain network, and the provider, as the provider of product data, develops data products and publishes a data catalog on the chain.
[0100] Optionally, by transforming data resources into an on-chain searchable product catalog, the data provider can achieve the following technical effects: (1) On-chain registration and global searchability of data resources: By transmitting the product catalog to the blockchain network for storage, the shared characteristics of the blockchain distributed ledger are utilized. Data users do not need to directly access the data provider's internal system. They can find available data products by querying the product catalog, thus establishing a foundation for connecting data supply and demand; (2) Ensuring the integrity and tamper-proof nature of data content and establishing a data trust mechanism: Because the hash algorithm has one-wayness and collision resistance, any minor modification to the product data will cause the hash value to change. Significant changes: When the data user subsequently obtains the data, they can verify whether the data has been tampered with during transmission or storage by recalculating the hash value and comparing it with the hash value stored on the chain, thereby enhancing the data user's trust in the authenticity of the data source; (3) Improve system efficiency and protect data privacy: In this embodiment, only the description data and hash value are stored on the chain, instead of directly storing massive amounts of product data on the chain, avoiding the performance bottleneck and surge in storage costs caused by storing massive amounts of plaintext data on the blockchain. At the same time, only the hash value and metadata are stored on the chain, without disclosing the specific content of the original product data, which conforms to the security principle of "data is usable but not visible" and reduces the risk of data leakage.
[0101] In one optional embodiment, before executing the smart contract signing operation between the interacting parties, and when the user needs to use products from the product catalog, the processing system jointly determines a digital contract strategy through the provider and the user. The constraint parameters in the constraints corresponding to the digital contract strategy include at least one of the following: the user's identity identifier, a preset usage time window, a preset number of uses, a preset application scope, a preset location, and a preset data processing mode. Then, the user generates a digital contract request based on the digital contract strategy and sends the request to the provider. After the digital contract request passes the provider's verification operation, the provider generates the source code of the smart contract based on the digital contract strategy carried in the digital contract request. Subsequently, the provider issues a verifiable credential to the user based on the digital contract strategy carried in the digital contract request using its digital identity. Finally, the verifiable credential and the source code of the smart contract are sent to the user.
[0102] Optionally, the data user searches the data catalog on the blockchain for the data products required, negotiates the smart digital module (i.e., the digital contract strategy) with the provider, and determines the parameters of the smart contract. Then, the user initiates a digital contract request to the provider using their own digital identity. The provider issues a verifiable credential using their own digital identity and sends it along with the smart contract source code to organization B. Finally, both parties start a trusted environment in the blockchain node and deploy the smart contract in the TEE. The TEE is used for smart contract measurement and remote authentication to prove to the other party that the source code of the smart contract deployed on it has not been tampered with, thus enabling both parties to agree on and understand the same smart contract.
[0103] Optionally, the technical effects that the processing system can achieve through the above steps include: (1) Refining the control of product data usage: By directly mapping specific parameters such as user identity, time window, number of times, location, application scope, and data processing mode to global variables or constraints of smart contracts, this embodiment transforms abstract management strategies into enforceable code logic, avoiding the problems of redundant construction of management functions and inconsistent strategy execution in traditional solutions, and realizing the technical effect that data providers can remotely control data to ensure data security: (2) Establishing a trust mechanism between the two parties: The user can see the source code of the smart contract, and the provider issues a certificate, ensuring the openness and transparency of the contract and eliminating the lack of trust caused by black box operations. Through the digital identity signature and verifiable certificate of the blockchain, the non-repudiation of the contract signing process is ensured. Combined with the remote proof of TEE in the subsequent steps, the user can verify that the smart contract deployed on its local machine has not been tampered with, thereby trusting that the data processing process has not leaked its privacy (such as local data not being illegally extracted).
[0104] In one optional embodiment, the processing system first initiates trusted environments on the provider's trusted platform and the user's trusted platform. Subsequently, in the user's trusted environment, the source code sent by the provider is hashed to obtain a first hash value. The first hash value and a second hash value are then compared to obtain a comparison result. The second hash value is the hash value of the digital contract strategy pre-determined by the user and the provider. If the comparison result indicates that the first hash value and the second hash value are consistent, the comparison result is digitally signed by the user's digital identity to obtain a remote proof report. The remote proof report is then sent from the user's trusted space to the provider's trusted space. Subsequently, in the provider's trusted environment, the remote proof report sent by the user is subject to signature verification and hash verification. After the remote proof report passes the provider's signature verification and hash verification, the smart contract signing operation between the interacting parties is completed.
[0105] Optionally, the processing system utilizes a trusted environment to complete the remote measurement and authentication process of the interacting parties before signing the smart contract. The technical effects that can be achieved include: (1) Ensuring the integrity and tamper-proof nature of the smart contract code: By performing hash calculation on the source code in the user's TEE (obtaining the first hash value) and comparing it with the pre-agreed digital contract strategy hash value (the second hash value), it can accurately verify whether the smart contract code deployed locally on the data user's premises is consistent with the agreement between the two parties. If the first hash value is inconsistent with the second hash value, signing is prevented, thereby solving the problem that the data user cannot trust the data usage process; (2) Achieving secure remote authentication across domains: The user's digital identity signs the comparison result to generate a remote proof report, which is then verified by the provider's trusted environment, enabling... The data provider can remotely verify the security of the user's operating environment and the authenticity of the code without directly contacting the user's local system or relying on an untrusted intermediary. This overcomes the shortcomings of the traditional CS model, such as the untrusted client and the inability of privacy computing schemes to truly deliver data. (3) Ensure the mandatory and non-repudiable execution of digital contracts: The smart contract is signed only after the remote proof report passes the provider's signature verification and hash verification. This means that the contract's effectiveness is based on the consistency of the code between the two parties and the trustworthiness of the environment. Once the signing is completed, the smart contract will be automatically executed in the TEE. Since the code has not been tampered with and has been endorsed by the digital identities of both parties, the subsequent data usage behavior will be executed according to the contract logic, preventing any party from denying the contract content or execution process afterward.
[0106] In one alternative embodiment, Figure 5 This is an architecture diagram of an optional product data processing system according to an embodiment of this application, such as... Figure 5 As shown, the processing system includes a blockchain network (i.e., Figure 5 1) A trusted data space service platform based on a blockchain BaaS platform (i.e. Figure 5 2.1 and 2.2 in the text correspond to the aforementioned trusted platform), and the trusted data space access connector based on blockchain nodes (i.e. Figure 5 3.1 and 3.2 in the text correspond to the aforementioned access connector and smart contracts (i.e. Figure 5 4.1 and 4.2 in the text), Trusted Execution Environment (i.e. Figure 5 5.1 and 5.2 in the text correspond to the aforementioned trusted environment), and the organization's internal business application systems (i.e. Figure 5 6.1 and 6.2 in the text), and private databases within the organization (i.e. Figure 5 Sections 7.1 and 7.2 (corresponding to the aforementioned local database) and the encrypted communication links between smart contracts (i.e. Figure 5 The number 8 in the equation corresponds to the aforementioned preset link.
[0107] Optionally, the organization's internal business application system connects to the private database within the interacting party to invoke the trusted data space connector for contract initialization and data upload; the organization's internal private database is used to store the interacting party's local data; and encrypted communication links between smart contracts are used to achieve secure data transmission between smart contracts.
[0108] Optionally, through Figure 5 The steps of the data processing method executed by the processing system in the middle are as follows:
[0109] (1) System initialization: For the two parties that need to join the trusted data space for data circulation and utilization (taking two parties as an example, the logic is the same for three or more parties), such as... Figure 5 Organization A (the provider) and Organization B (the user) first deploy a blockchain BaaS platform and blockchain nodes, and then add the blockchain nodes to the blockchain network to form a trusted data space.
[0110] (2) Data initialization: Organization A and Organization B generate digital identities on the chain. Organization A, as a data provider, develops data products and publishes a data catalog on the chain.
[0111] (3) Signing a digital contract: Organization B, as the data user, searches the data catalog on the chain according to the data products required, negotiates the digital contract and usage control strategy with Organization A, determines the smart contract parameters, and then initiates a digital contract request with its own digital identity. Organization A issues a verifiable certificate with its own digital identity and sends it to Organization B along with the smart contract source code. Finally, Organization A and Organization B start a Trusted Execution Environment (TEE) in the blockchain node and deploy the smart contract in the TEE. The TEE is used to measure and remotely authenticate the smart contract, proving to the other party that the source code of the smart contract deployed on it has not been tampered with and that both parties agree to and understand the same smart contract.
[0112] (4) Data delivery: After Organization B pays the data product fee, Organization A calls the smart contract through the SDK to upload local data to the smart contract. Organization B then calls the smart contracts of both parties, requesting Organization A's smart contract to deliver the data to Organization B's smart contract through the TLS secure link according to the digital contract. After receiving the data, Organization B's smart contract uses a key to encrypt and store the data in the TEE. The entire process is protected by the TEE to prevent Organization B's system administrator from having unauthorized access to the smart contract code and data. Although the two smart contract codes are the same, their collaborative processing can be differentiated by role based on the digital identity signature of the caller.
[0113] (5) Data fusion: When Organization B uses the data delivered by Organization A, it can call the local smart contract to upload Organization B's local data to the smart contract, thereby realizing the data fusion between the two parties. The fusion result can be used for data statistics, comparison and other application scenarios.
[0114] (6) Data usage control: When Organization B uses data, it sends a data usage request and a verifiable credential that has been signed and authorized to the local smart contract. The smart contract verifies the validity of the verifiable credential and checks that the data usage request should comply with the digital contract strategy in the verifiable credential. For example, the Who strategy can use distributed digital identity (DID) for identity authentication, When can use the time on the blockchain for judgment, Where and How To can assign digital identities to devices and applications and be signed and endorsed by the terminal to determine the location and application, and How Many can use the blockchain to store the counter to accumulate the number of times. After the strategy verification is passed, the smart contract executes the corresponding SQL or other data services according to the SQL ID specified in the data usage request, and then returns the processing result to the data user without disclosing the original data, thus completing the digital contract performance.
[0115] (7) Data destruction: When organization B reaches the maximum number of uses or time window, the smart contract shall perform data destruction operation to complete the data life cycle closed loop.
[0116] In summary, this embodiment uses a blockchain BaaS platform as a service platform and blockchain nodes and smart contracts as access connectors to construct a blockchain-based data delivery implementation path. This embodiment integrates data usage control and trusted execution environment technologies through blockchain technology, thereby reducing redundant system construction and security attack surfaces, and achieving true data delivery. That is, the data provider can securely deliver the original data to the local environment of the data user through the blockchain network. While ensuring that the data user can use the data as needed (such as executing SQL queries), the smart contract ensures that the data is used according to the agreement, and the TEE ensures the security and trustworthiness of the smart contract and the data. This achieves the technical effect of "usable but invisible, controllable and measurable", which enables the data provider to remotely verify and control the entire process of data use, and avoids the leakage and abuse of original data, providing technical support for the secure and efficient circulation of product data.
[0117] Example 2
[0118] This application embodiment can also provide a product data processing device. It should be noted that the product data processing device of this application embodiment can be used to execute the product data processing method provided in this application embodiment. The product data processing device provided in this application embodiment is described below.
[0119] According to an embodiment of this application, an apparatus for implementing the above-described product data processing method is also provided. Figure 6 This is a schematic diagram of an optional product data processing apparatus according to an embodiment of this application, such as... Figure 6 As shown, the device includes: a deployment unit 601, a signing unit 602, a first uploading unit 603, and a first processing unit 604.
[0120] Optionally, deployment unit 601 is used to deploy blockchain nodes and a trusted platform for the parties interacting with product data. The parties include a provider and a user. The user's blockchain node and the provider's blockchain node are connected via a blockchain network. The trusted platform is used at least to implement product catalog management operations, smart contract management operations, and product data usage control operations. Signing unit 602 is used to execute the signing operation of smart contracts between the parties in a trusted environment provided by the trusted platform. First upload unit 603 is used to upload the product data corresponding to the product in the provider's local database to a first smart contract after the smart contract signing operation is completed and the user pays the provider for the product. The first smart contract is a smart contract running in the provider's blockchain node. First processing unit 604 is used to transmit product data to a second smart contract via the first smart contract based on a preset link, and to encrypt the product data through the second smart contract to obtain encrypted data. The second smart contract is a smart contract running in the user's blockchain node.
[0121] As described above, this device combines blockchain networks, a trusted environment, and smart contracts. It deploys a trusted platform as a service platform to provide a trusted space for the parties interacting with product data, and deploys blockchain nodes as access connectors for this trusted space. Smart contracts are used to execute the signing of smart contracts and the encryption of delivered product data within the trusted environment. This securely delivers the provider's local product data to the user's trusted environment via a pre-defined link. This achieves the goal of ensuring product data security while making the secure delivery process from provider to user controllable. It avoids the technical shortcomings of redundant construction of systems with different technical architectures and the wide range of security attacks, thus preventing product data leakage and misuse. Furthermore, it ensures that users can trust the process of using product data, thereby solving the technical problem of low data security during product data processing.
[0122] In one optional embodiment, the product data processing apparatus further includes a second uploading unit and a second processing unit.
[0123] Optionally, the second uploading unit is used to upload user data from the user's local database to the second smart contract after the product data is transmitted to the second smart contract via the first smart contract based on a preset link; the second processing unit is used to perform data fusion on the user data and the received product data through the second smart contract to obtain the target data.
[0124] In one optional embodiment, the product data processing apparatus further includes: a first signature verification unit, a parsing unit, a detection unit, and a first generation unit.
[0125] Optionally, the first signature verification unit is used to verify the signature of the verifiable credential after the product data is transmitted to the second smart contract via a preset link through the first smart contract, and the second smart contract receives the user's data usage request and verifiable credential. The parsing unit is used to parse the verifiable credential through the second smart contract after the signature verification is passed, to obtain a digital contract strategy, wherein the digital contract strategy is used to characterize the constraints in the process of controlling the use of product data. The detection unit is used to detect whether the data usage request submitted by the user meets the constraints corresponding to the digital contract strategy. The first generation unit is used to generate return data based on the data usage request and encrypted data through the second smart contract if the data usage request meets the constraints corresponding to the digital contract strategy, and send the return data to the user.
[0126] In one alternative embodiment, the product data processing apparatus further includes a destruction unit.
[0127] Optionally, the destruction unit is used to perform a destruction operation on the encrypted data through a second smart contract after detecting whether the data usage request submitted by the user meets the constraints corresponding to the digital contract strategy, and if the data usage request does not meet the first constraint and / or the second constraint corresponding to the digital contract strategy. The first constraint is used to indicate that the number of times the user uses the data is greater than or equal to the preset number of times the data is used, and the second constraint is used to indicate that the time when the user initiates the data usage request exceeds the preset usage time window.
[0128] In one optional embodiment, the product data processing device further includes: a third uploading unit, a hash calculation unit, a second generation unit, and an on-chain storage unit.
[0129] Optionally, the third uploading unit is used to upload the product data corresponding to all products in the provider's local database to the provider's blockchain node after deploying blockchain nodes and a trusted platform for the parties interacting with the product data; the hash calculation unit is used to perform hash calculation on the product data corresponding to all uploaded products through the provider's blockchain node to obtain the hash value of each product; the second generation unit is used to generate a product catalog based on the hash value of each product and the description data of each product; and the on-chain storage unit is used to transmit the product catalog to the blockchain network for storage.
[0130] In one optional embodiment, the product data processing apparatus further includes: a strategy determination unit, a third generation unit, a fourth generation unit, a voucher issuance unit, and a contract sending unit.
[0131] Optionally, the strategy determination unit is used to jointly determine a digital contract strategy with the provider and the user before executing the signing operation of the smart contract between the interacting parties, provided that the user needs to use products in the product catalog. The constraint parameters in the constraints corresponding to the digital contract strategy include at least one of the following: the user's identity identifier, a preset usage time window, a preset number of uses, a preset application scope, a preset location, and a preset data processing mode. The third generation unit is used to generate a digital contract request based on the digital contract strategy by the user and send the digital contract request to the provider. The fourth generation unit is used to generate the source code of the smart contract by the provider based on the digital contract strategy carried in the digital contract request after the digital contract request has passed the provider's verification operation. The credential issuance unit is used to issue a verifiable credential to the user based on the digital contract strategy carried in the digital contract request using the provider's digital identity. The contract sending unit is used to send the verifiable credential and the source code of the smart contract to the user.
[0132] In one optional embodiment, the signing unit 602 includes: a startup subunit, a hash calculation subunit, a signature subunit, a report sending subunit, a report verification subunit, and a signing subunit.
[0133] Optionally, the system includes: a startup subunit for starting the trusted environment on the provider's trusted platform and the user's trusted platform; a hash calculation subunit for performing hash calculation on the source code sent by the provider in the user's trusted environment to obtain a first hash value, and comparing the first hash value with a second hash value to obtain a comparison result, wherein the second hash value is the hash value of the digital contract strategy jointly determined by the user and the provider in advance; a signature subunit for digitally signing the comparison result with the user's digital identity when the comparison result indicates that the first hash value and the second hash value are consistent, thereby obtaining a remote proof report; a report sending subunit for sending the remote proof report from the user's trusted space to the provider's trusted space; a report verification subunit for performing signature verification and hash verification on the remote proof report sent by the user in the provider's trusted environment; and a signing subunit for completing the signing operation of the smart contract between the interacting parties after the remote proof report passes the provider's signature verification and hash verification.
[0134] It should be noted that the deployment unit 601, signing unit 602, first upload unit 603, and first processing unit 604 mentioned above correspond to steps S201 to S204 in the method embodiment. The instances and application scenarios implemented by the above units and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and run in the computer terminal 10 provided in the embodiment.
[0135] Example 3
[0136] Embodiments of this application can also provide an electronic device. Figure 7 This is a structural block diagram of an electronic device according to an embodiment of this application, such as... Figure 7 As shown, the electronic device includes: one or more ( Figure 7 (Only one is shown) processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.
[0137] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, to realize the above-mentioned product data processing method.
[0138] The memory may include high-speed random access memory (RAM), and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.
[0139] The processor can access information and applications stored in memory via a transmission device to execute the following steps: deploying blockchain nodes and a trusted platform for the parties interacting with product data, wherein the parties include a provider and a user, the user's blockchain node and the provider's blockchain node are connected through a blockchain network, and the trusted platform is used at least to implement product catalog management operations, smart contract management operations, and product data usage control operations; executing the signing operation of smart contracts between the parties in the trusted environment provided by the trusted platform; after the smart contract signing operation is completed and the user pays the provider for the product, uploading the product data corresponding to the product in the provider's local database to a first smart contract, wherein the first smart contract is a smart contract running in the provider's blockchain node; transmitting the product data to a second smart contract through the first smart contract based on a preset link, and encrypting the product data through the second smart contract to obtain encrypted data, wherein the second smart contract is a smart contract running in the user's blockchain node.
[0140] This application provides a product data processing solution. The solution combines blockchain networks, a trusted environment, and smart contracts. It deploys a trusted platform as a service platform to provide a trusted space for the parties interacting with the product data, and deploys blockchain nodes as access connectors for this trusted space. Smart contracts are used to execute the signing and encryption of the delivered product data within the trusted environment. This securely delivers the provider's local product data to the user's trusted environment via a pre-defined link, achieving a controllable secure delivery process from provider to user while ensuring product data security. This avoids the technical drawbacks of redundant system construction with different technical architectures and the wide range of security attacks, thus preventing product data leakage and misuse, and ensuring that users can trust the use of product data. This solves the technical problem of low data security during product data processing by the parties involved.
[0141] Those skilled in the art will understand that Figure 7 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, PDAs, mobile internet devices, PADs, and other terminal devices. Figure 7This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 7 The different configurations shown.
[0142] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.
[0143] Example 4
[0144] Embodiments of this application may also provide a storage medium.
[0145] Optionally, in this embodiment of the application, the storage medium can be used to store the program code executed by the product data processing method provided in the above method embodiment.
[0146] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.
[0147] This application also provides a computer program product, which, when executed on a data processing device, is adapted to perform the steps of a method for processing product data.
[0148] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0149] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0150] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.
[0151] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0152] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0153] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0154] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. A method for processing product data, characterized in that, include: Deploy blockchain nodes and a trusted platform for the parties interacting with product data. The parties interacting with product data include providers and users. The blockchain nodes of the users and the blockchain nodes of the providers are connected through a blockchain network. The trusted platform is used to implement at least the management operations of the product catalog, the management operations of smart contracts, and the operation of controlling the use of the product data. Within the trusted environment provided by the trusted platform, the signing operation of the smart contract between the interacting parties is executed; After the smart contract signing operation is completed and the user pays the provider for the product, the product data corresponding to the product in the provider's local database is uploaded to the first smart contract, wherein the first smart contract is a smart contract running in the provider's blockchain node. The product data is transmitted to the second smart contract via a preset link through the first smart contract, and the product data is encrypted through the second smart contract to obtain encrypted data. The second smart contract is a smart contract running in the blockchain node of the user.
2. The product data processing method according to claim 1, characterized in that, After the product data is transmitted to the second smart contract via the first smart contract through a preset link, the method for processing the product data further includes: Upload the user data from the user's local database to the second smart contract; The target data is obtained by fusing the user data and the received product data through the second smart contract.
3. The product data processing method according to claim 1, characterized in that, After the product data is transmitted to the second smart contract via the first smart contract through a preset link, the method for processing the product data further includes: After the second smart contract receives the user's data request and verifiable credentials, it performs signature verification on the verifiable credentials through the second smart contract. After the verifiable credential is verified by the signature, the verifiable credential is parsed by the second smart contract to obtain a digital contract strategy, wherein the digital contract strategy is used to characterize the constraints in the process of controlling the use of the product data; Detect whether the data usage request submitted by the user meets the constraints corresponding to the digital contract strategy; If the data usage request meets the constraints corresponding to the digital contract strategy, the second smart contract generates return data based on the data usage request and the encrypted data, and sends the return data to the user.
4. The product data processing method according to claim 3, characterized in that, After detecting whether the data usage request submitted by the user meets the constraints corresponding to the digital contract strategy, the product data processing method further includes: If the data usage request does not meet the first constraint and / or the second constraint corresponding to the digital contract strategy, the encrypted data is destroyed through the second smart contract. The first constraint is used to indicate that the number of times the user uses data is greater than or equal to the preset number of times, and the second constraint is used to indicate that the user's data usage request was initiated at a time that exceeds the preset usage time window.
5. The product data processing method according to claim 1, characterized in that, After deploying blockchain nodes and a trusted platform for the parties interacting with the product data, the product data processing method further includes: Upload the product data corresponding to all products in the provider's local database to the provider's blockchain node; The provider's blockchain node performs hash calculations on the product data corresponding to all uploaded products to obtain the hash value of each product; The product catalog is generated based on the hash value of each product and the description data of each product. The product catalog is transmitted to the blockchain network for storage.
6. The product data processing method according to claim 1, characterized in that, Before executing the smart contract signing operation between the interacting parties, the product data processing method further includes: When the user needs to use the products in the product catalog, the provider and the user jointly determine the digital contract strategy, wherein the constraint parameters in the constraints corresponding to the digital contract strategy include at least one of the following: the user's identity identifier, the preset usage time window, the preset number of uses, the preset application scope, the preset location, and the preset data processing mode. The user generates a digital contract request based on the digital contract strategy and sends the digital contract request to the provider. After the digital contract request passes the provider's verification operation, the provider generates the source code of the smart contract based on the digital contract strategy carried in the digital contract request. Based on the digital contract policy carried in the digital contract request, the provider issues verifiable credentials to the user using its digital identity. The verifiable credentials and the source code of the smart contract are sent to the user.
7. The product data processing method according to claim 1, characterized in that, In the trusted environment provided by the trusted platform, the signing operation of the smart contract between the interacting parties is performed, including: Start the trusted environment on the trusted platform of the provider and the trusted platform of the user; In the trusted environment of the user, the source code sent by the provider is hashed to obtain a first hash value, and the first hash value and the second hash value are compared to obtain a comparison result, wherein the second hash value is the hash value of the digital contract strategy jointly determined by the user and the provider in advance; If the comparison result indicates that the first hash value and the second hash value are consistent, the comparison result is digitally signed using the user's digital identity to obtain a remote proof report; The remote proof report is sent from the user's trusted space to the provider's trusted space; In the trusted environment of the provider, the remote proof report sent by the user is subject to signature verification and hash verification. After the remote proof report passes the signature verification and hash verification by the provider, the signing operation of the smart contract between the interacting parties is completed.
8. A product data processing device, characterized in that, include: The deployment unit is used to deploy blockchain nodes and a trusted platform for the parties interacting with product data. The parties interacting with product data include providers and users. The blockchain nodes of the users and the blockchain nodes of the providers are connected through a blockchain network. The trusted platform is used to implement at least the management operations of the product catalog, the management operations of smart contracts, and the usage control operations of the product data. The signing unit is used to perform the signing operation of the smart contract between the interacting parties in the trusted environment provided by the trusted platform; The first uploading unit is used to upload the product data corresponding to the product in the provider's local database to the first smart contract after the smart contract signing operation is completed and the user pays the provider for the product. The first smart contract is a smart contract running in the provider's blockchain node. The first processing unit is configured to transmit the product data to a second smart contract via a preset link through the first smart contract, and to encrypt the product data through the second smart contract to obtain encrypted data, wherein the second smart contract is a smart contract running in the blockchain node of the user.
9. A computer program product, characterized in that, The computer program product includes a computer program, wherein, when the computer program is running, it controls the computer program product to perform the product data processing method according to any one of claims 1 to 7.
10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the product data processing method according to any one of claims 1 to 7.