Proxy method, apparatus, and computer readable storage medium
By acquiring transaction data on the blockchain platform and performing local storage and inter-agent verification, the problem of privacy data leakage on the blockchain platform is solved, enabling highly secure transactions across blockchain platforms and reducing storage space usage.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZTE CORP
- Filing Date
- 2020-06-28
- Publication Date
- 2026-05-22
AI Technical Summary
Existing blockchain platforms pose a risk of privacy breaches in cross-blockchain data transactions, and traditional transaction processes are cumbersome, time-consuming, and fail to effectively protect data privacy.
By acquiring users' transaction data, including transaction requests and private data, sending transaction requests to the blockchain platform and completing the transaction, the private data is stored locally, and transaction verification is performed between the agents of both parties. By leveraging the immutability of the blockchain, the trustworthiness and traceability of the transaction are ensured, while the private data is stored only locally to avoid being uploaded to the blockchain.
It improves transaction security, protects the privacy of private data, reduces storage space usage, and is suitable for transactions across blockchain platforms.
Smart Images

Figure CN113849851B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a proxy method, device, and computer-readable storage medium. Background Technology
[0002] In today's information age, data, as a new commodity, has seen its sharing and trading become a new hot topic in technology and business. Traditional transactions often rely on third-party trading centers, which are backed by trusted institutions for oversight and endorsement, making the process cumbersome and time-consuming. Because data differs significantly from traditional commodities—it is easily disseminated and copied, and involves the privacy of individuals and businesses requiring protection—there are higher demands for the traceability of data transactions and the integrity and reliability of the data. A trustworthy, tamper-proof, and traceable trading mechanism is needed to ensure the security of data transactions.
[0003] Blockchain is a distributed ledger database technology shared by multiple parties. Its core technology consists of block-based data storage and smart contracts, allowing only read and write operations, not modification or deletion. However, blockchain's decentralized architecture, where all nodes participate in record-keeping and maintenance, means that data on the chain is publicly available to all users. This design is detrimental to data privacy protection; directly storing private data on the chain could lead to data leaks. Currently, most blockchain platforms fail to effectively protect privacy data, posing a risk of privacy breaches, especially in the cross-blockchain platform technology area, where a unified and effective solution is lacking. Summary of the Invention
[0004] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.
[0005] This invention proposes a proxy method, device, and computer-readable storage medium that can solve the problem of easy leakage of privacy data in blockchain transactions, thereby effectively improving the security of transactions.
[0006] In a first aspect, an embodiment of the present invention provides a proxy method for a first proxy, comprising:
[0007] Obtain the user's transaction data, which includes transaction requests and private data;
[0008] The private data is stored locally, and the transaction request is sent to the blockchain platform so that the blockchain platform can complete the transaction according to the transaction request.
[0009] After the transaction is completed, the private data is sent to the peer agent for transaction verification.
[0010] Secondly, an embodiment of the present invention provides a proxy method for a second proxy, comprising:
[0011] Obtain private data sent by the peer agent, the private data being stored in the peer agent and used to verify transactions initiated by the peer agent through sending transaction requests to the blockchain platform;
[0012] Transaction verification is performed on the private data.
[0013] Thirdly, an embodiment of the present invention provides an apparatus including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the proxy method as described in the first or second aspect embodiment above.
[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer-executable instructions for performing the proxy method as described in the first or second aspect embodiments above.
[0015] This invention includes the following steps: acquiring user transaction data, which includes transaction requests and private data, and then sending the transaction request to a blockchain platform. The blockchain platform completes the transaction based on the transaction request and stores the private data locally. After the transaction is completed, the private data is sent to the peer agent for transaction verification. In this way, the immutability of blockchain technology is utilized to ensure the trustworthiness and traceability of transactions. At the same time, the private data is only traded between the local agents of the two parties and is stored locally, meaning that the private data is not uploaded to the blockchain platform. This effectively solves the problem of easy leakage of private data on blockchain platforms, resulting in high transaction security and effective protection of private data. It is applicable to cross-blockchain platforms, and since the private data does not need to be uploaded to the blockchain, it can reduce the amount of storage space required.
[0016] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the description, claims, and drawings. Attached Figure Description
[0017] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.
[0018] Figure 1 This is a schematic diagram of a system architecture platform provided in one embodiment of the present invention;
[0019] Figure 2 This is a flowchart of a proxy method provided in one embodiment of the present invention;
[0020] Figure 3 This is a flowchart of a proxy method provided in another embodiment of the present invention;
[0021] Figure 4 This is a flowchart of a proxy method provided in another embodiment of the present invention;
[0022] Figure 5 This is a flowchart of a proxy method provided in another embodiment of the present invention;
[0023] Figure 6 This is a flowchart of a proxy method provided in another embodiment of the present invention;
[0024] Figure 7 This is a flowchart of the deployment process in Embodiment 1 of the present invention;
[0025] Figure 8 This is a flowchart of the transaction process according to Embodiment 1 of the present invention;
[0026] Figure 9 This is a flowchart of the data acquisition process in Embodiment 1 of the present invention. Detailed Implementation
[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0028] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, or the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0029] Blockchain is a distributed ledger database technology that uses shared data across multiple parties. Its core technology consists of block-based data storage and smart contracts, allowing only read and write operations, not modification or deletion. Blockchain primarily addresses the problem of value transfer within a trustless network. Using blockchain technology for data transactions ensures trustworthiness and traceability while reducing third-party intervention and improving efficiency. However, because blockchain is a decentralized architecture, all nodes participate in recording and maintaining the ledger. Data uploaded to the chain is publicly available to all users, which can compromise data privacy. Directly uploading private data to the blockchain could lead to data leaks.
[0030] Currently, blockchain platforms still fail to effectively protect privacy data, and the risk of privacy leaks remains, especially in the field of cross-blockchain platform technology, where there is no unified and effective solution. This invention provides a proxy method, proxy node, device, and computer-readable storage medium. By acquiring user transaction data, including transaction requests and private data, the method sends a transaction request to the blockchain platform. The blockchain platform completes the transaction based on the request and stores the private data locally. After the transaction is completed, the private data is sent to the peer proxy for transaction verification. This leverages the immutable nature of blockchain technology to ensure the trustworthiness and traceability of transactions. Furthermore, private data is only traded between the local proxies of the two parties and is stored locally, meaning it is not uploaded to the blockchain platform. This effectively solves the problem of easy leakage of private data on blockchain platforms, resulting in high transaction security and effective protection of private data. It is applicable to cross-blockchain platforms, and since private data does not need to be uploaded to the blockchain, it reduces the amount of storage space required.
[0031] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are some embodiments of the present invention, not all embodiments.
[0032] See Figure 1 As shown, Figure 1 This is a schematic diagram of a system architecture platform 100 for executing proxy methods provided in an embodiment of the present invention.
[0033] exist Figure 1In the illustrated embodiment, the system architecture platform 100 includes a business layer 120, a communication layer 150, and a storage layer 160. The business layer 120 submits transaction requests to the blockchain platform and notifies the storage of private data. The communication layer 150 establishes communication connections between agent modules. The database stores user private data. When a transaction is conducted on the blockchain platform, the user's transaction data (including transaction requests and private data) is obtained. The business layer 120 sends the transaction request to the blockchain platform, which completes the transaction based on the request. The storage layer 160 stores the private data locally. After the transaction is completed, the communication layer 150 establishes a communication connection with the peer agent, and the private data is sent to the peer agent for transaction verification, thus completing the transaction.
[0034] The system architecture platform 100 can be understood as a proxy module that executes the proxy method. This proxy module is deployed on the ledger node of the blockchain platform. That is, the two parties to the transaction connect to the blockchain platform through the proxy module to conduct the transaction. In this way, the immutability of blockchain technology is utilized to ensure the trustworthiness and traceability of the transaction. At the same time, private data is only traded between the local proxies of the two parties to the transaction, and the private data is stored locally on the proxy mode. During the transaction, the private data will not be uploaded to the blockchain platform. The private data is only processed between the proxy modules of the two parties to the transaction, which effectively solves the problem of easy leakage of private data on the blockchain platform. The transaction security is high, and it plays an effective role in protecting private data. Moreover, since private data does not need to be uploaded to the blockchain, it can reduce the occupation of a large amount of storage space.
[0035] like Figure 1 As shown, a specific proxy module structure is used as an example for illustration. The proxy module is responsible for connecting the blockchain platform and the local database for users, helping users to securely complete transactions of private data.
[0036] Specifically, the proxy module includes an adaptation layer 110, a business layer 120, a model layer 130, an access layer 140, a communication layer 150, and a storage layer 160. The adaptation layer 110 adapts to the differences in interfaces of different blockchain platforms by encapsulating a unified interface, supporting various consortium blockchains and public / private blockchain platforms such as Hyperledger Fabric, Fisco BTC, and Ethereum. The business layer 120 is primarily responsible for submitting transactions to the blockchain platform and notifying the data management module to perform private data storage and synchronization. The model layer 130 provides support for storage and transactions by providing unified modeling for smart contracts, transactions, private data, and configurations. The access layer 140 interacts with transaction users via CLI command line to complete transaction proxying and data synchronization functions. The communication layer 150 communicates with other node proxy modules using the gossip protocol and uses a message queue to cache messages sent by other proxy modules. Storage layer 160 is used to store the configuration information and private data of the proxy module. The configuration initialization information is used to configure the type, address, port, channel information and access certificate of the blockchain platform to be connected. The private data is stored in a local database with encryption, supporting common databases such as CouchDB and RocksDB.
[0037] It should be noted that when transactions are conducted on a blockchain platform, they are executed through smart contracts. These smart contracts are responsible for executing the transactions, recording them, and simultaneously transferring points to the user's account. A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. Blockchain provides a decentralized and trusted environment, therefore smart contracts are compatible with blockchain technology. Furthermore, the proxy module can provide a unified interface through the adaptation layer 110, supporting different blockchain platforms and making the system architecture platform 100 suitable for cross-blockchain platforms. This addresses the privacy risks associated with most current blockchain platforms.
[0038] The system architecture platform 100 and application scenarios described in the embodiments of the present invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of the present invention, and do not constitute a limitation on the technical solutions provided by the embodiments of the present invention. As those skilled in the art will know, with the evolution of the system architecture platform 100 and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present invention are also applicable to similar technical problems.
[0039] It will be understood by those skilled in the art that Figure 1 The system architecture platform 100 shown does not constitute a limitation on the embodiments of the present invention. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0040] exist Figure 1 In the system architecture platform 100 shown, the adaptation layer 110, business layer 120, model layer 130, access layer 140, communication layer 150 and storage layer 160 can work together to execute proxy methods.
[0041] Based on the above system architecture platform 100, various embodiments of the proxy method of the present invention are proposed below.
[0042] See Figure 2 As shown, Figure 2 This is a flowchart of a proxy method provided in an embodiment of the present invention, which includes, but is not limited to, steps S100, S200 and S300.
[0043] Step S100: Obtain the user's transaction data, which includes transaction requests and private data.
[0044] In one embodiment, the transaction process is implemented based on blockchain technology. It can be understood that before the transaction, transaction data needs to be generated based on the user's transaction content, and then the transaction data is sent online. The transaction content can be understood as the transaction details agreed upon offline by both parties. The two parties can exchange accounts and public keys with each other for the purpose of generating transaction data and encrypting and decrypting the transaction data.
[0045] The transacting parties connect to the blockchain platform through a proxy module to conduct transactions. Specifically, both parties deploy corresponding proxy modules on the blockchain platform's ledger nodes, and complete the transaction through the local proxy module. In this embodiment, the step of obtaining user transaction data is executed through the proxy module. The obtained transaction data includes transaction requests and private data. The transaction requests may include the accounts of both parties, the transaction time, etc., while the private data includes personal identity information and other privacy information.
[0046] Step S200: Store the private data locally and send a transaction request to the blockchain platform so that the blockchain platform can complete the transaction according to the transaction request.
[0047] In one embodiment, storing private data locally can be understood as using a local proxy module to store the private data; specifically, the storage layer of the local proxy module stores the private data. Simultaneously, sending transaction requests to the blockchain platform means that only the transaction request is sent to the blockchain platform; the private data itself is not sent to the blockchain, i.e., the private data is not recorded on the blockchain. Upon receiving the transaction request, the blockchain platform executes the corresponding transaction.
[0048] It should be noted that the transaction request includes data that the blockchain platform can use to complete the transaction. The blockchain platform completes the transaction based on the transaction request, provided that both parties to the transaction can be identified. Private data is not sent to the blockchain platform, thus effectively preventing the leakage of private data and improving the security of the transaction.
[0049] Step S300: After the transaction is completed, the private data is sent to the peer agent for transaction verification.
[0050] In one embodiment, in step S200, private data is stored in a local agent module. After the transaction is completed on the blockchain platform, the private data is sent to the peer agent. The peer agent can be understood as the agent corresponding to the other party in the transaction. For example, if the buyer is the data provider, the buyer's agent is the first agent, and the seller is the data requester, the seller's agent is the second agent. During the transaction, the first agent sends a transaction request to the blockchain platform and stores the private data locally. After the transaction is completed, the first agent sends the private data to the second agent for transaction verification. The second agent can be understood as the peer agent of the first agent.
[0051] Compared to traditional transaction methods, in this embodiment, private data is not uploaded to the blockchain platform during the transaction process. Instead, private data is traded directly between agents, effectively solving the problem of easy leakage of private data on blockchain platforms. This ensures high transaction security and provides effective protection for private data. Furthermore, since private data does not need to be uploaded to the blockchain, the uploaded data is isolated from the private data. This not only ensures the traceability of transactions but also solves the problems of occupying a large amount of storage space and privacy leakage caused by uploading private data to the blockchain. This effectively addresses the issue of poor data privacy protection across blockchain platforms.
[0052] In this embodiment, steps S100, S200 and S300 are the execution flow of the first agent, which are the execution steps of the data provider side in the transaction entity. The transaction verification step in step S300 is executed on the peer agent.
[0053] See Figure 3 In one embodiment, before obtaining the user's transaction data, step S100 includes, but is not limited to, the following steps:
[0054] Step S110: Generate a digest based on the private data, encrypt the private data, and sign the encrypted private data;
[0055] Step S120: Generate a transaction request based on the digest and signature.
[0056] Specifically, before acquiring transaction data, a digest is generated based on the private data. This digest can be understood as a summary of the private data's content. The private data is then encrypted using the public keys of both parties to the transaction, and signed using their respective private keys. Here, the public key can be understood as the shared key held by both parties, and the private key as the key held by each party individually. The provider of the transaction data signs the private data using their own private key, and this signature facilitates verification of the data provider's identity.
[0057] It is understood that locally stored private data is encrypted and signed to ensure its security. A transaction request is generated based on the digest and signature; that is, the transaction request includes both a digest and a signature, but is not limited to just a digest and a signature. For example, the transaction request may also include the accounts of the two parties involved in the transaction. The local agent sends the transaction request, including the digest and signature, to the blockchain platform. The blockchain platform initiates the transaction and completes the transaction record between the two agents through a smart contract. The transaction record includes the digest and signature information of the private data, thus ensuring that the transaction is traceable and has higher security.
[0058] See Figure 4 In one embodiment, step S300, after the transaction is completed, sends private data to the peer agent for transaction verification, and also includes, but is not limited to, the following steps:
[0059] Step S310: Send a push request to the peer agent;
[0060] Step S320: Receive the response information sent by the peer agent based on the push request;
[0061] Step S330: Send private data to the peer agent based on the response information so that the peer agent can verify the transaction based on the private data.
[0062] Once the local agent module completes the transaction on the blockchain platform, the agent module of the data provider initiates a process of pushing private data to the agent module of the data requester.
[0063] Specifically, the first proxy acts as the sender of private data, acting as the data provider; the second proxy acts as the receiver of private data, acting as the data requester. This will be illustrated using this example, and includes, but is not limited to, the following steps:
[0064] Step S311: The first agent establishes a Transport Layer Security (TLS) connection with the second agent and initiates a push request so that the second agent returns an agreement response based on the push request and returns a request random number;
[0065] Step S321: The first agent receives the response information from the second agent and pushes private data to the second agent, including push log and summary information;
[0066] Step S331: After completing the private data push, the first agent sends a termination message to the second agent.
[0067] The parameters of the push request include the ID of the first agent, the channel number, the recipient's account, the transaction ID, and a random number. If the private data to be pushed is large, it can be sent in packets. Furthermore, after the private data push is complete, the second agent verifies the private data and stores it locally, thus completing the transmission of the private data.
[0068] It should be noted that the first agent sends private data to the second agent through the Gossip protocol. The Gossip protocol is a widely used protocol in distributed systems, mainly used to realize information exchange between distributed nodes or processes. The Gossip protocol also meets the requirements of low load, high reliability and scalability required by application layer multicast protocols.
[0069] See Figure 5 In one embodiment, the proxy method further includes, but is not limited to, the following steps:
[0070] Step S400: Receive a synchronization request from the peer agent and return a list of private data summaries based on the synchronization request, so that the peer agent can compare the list of summaries with its own stored private data, and return a request list when it is determined that private data is missing.
[0071] Step S500: Send private data to the peer agent according to the request list.
[0072] The synchronization request can be understood as a synchronization request for private data. Since data loss or transmission failure may occur during the transmission of private data, in order to ensure the consistency of private data in the proxy storage of both parties in the transaction and to meet the requirements of transaction verification, the peer proxy will initiate a synchronization request after the private data is sent.
[0073] The specific private data synchronization process is as follows:
[0074] Step S410: The first agent receives a synchronization request from the second agent;
[0075] Step S420: The first agent returns a list of private data that meet the conditions and a request random number according to the synchronization request, so that the second agent can determine the missing private data by comparing it with the summary of its own stored private data, and send the request list to the first agent;
[0076] Step S510: The first agent pushes private data to the second agent in sequence according to the request list;
[0077] Step S520: After all private data has been pushed, the first agent sends a push end message to the second agent.
[0078] The synchronization request includes the proxy ID, range filtering parameters for the synchronized data (e.g., time, account, transaction ID, etc.), and a random number (to indicate the current request). The second proxy sends the private data synchronization request to the first proxy via a TLS connection. Additionally, after the private data push is complete, the second proxy verifies the private data and stores it locally.
[0079] It should be noted that the private data synchronization process is executed periodically by all agents. In this example, the first agent periodically receives synchronization requests from the second agent, thereby effectively solving the problem of private data loss.
[0080] In one embodiment, the proxy method further includes, but is not limited to, the following steps:
[0081] Step S600: When the storage time of private data exceeds the preset retention time, delete the private data.
[0082] It can be understood that private data is stored on the local proxy module. For example, the private data of the first proxy is stored on the first proxy module, and the private data of the second proxy is stored on the second proxy module. The proxy module periodically clears the private data stored locally to ensure that the proxy module has sufficient storage space.
[0083] See Figure 6 As shown, another embodiment of the present invention provides a proxy method, which is an execution step on the data request side of the transaction subject. The subject executing the proxy method step is the peer proxy in step S300 of the embodiment.
[0084] Specifically, the proxy method includes, but is not limited to, the following steps:
[0085] Step S101: Obtain the private data sent by the peer agent. The private data is stored in the peer agent and used to verify the transactions made by the peer agent by sending transaction requests to the blockchain platform.
[0086] Step S201: Verify the transaction of private data.
[0087] Taking the example of a first agent providing data and a second agent requesting data, it can be understood that in this embodiment, the peer agent is the first agent, and the second agent obtains the private data sent by the first agent and performs transaction verification on the private data. The process of the first agent sending private data to the second agent can be found in [reference needed]. Figure 2 The process of the illustrated embodiment will not be described again here.
[0088] In one embodiment, step S201, which involves transaction verification of private data, further includes, but is not limited to, the following steps:
[0089] Step S211: Verify the signature of the private data to confirm the user who provided the private data;
[0090] Step S212: Decrypt the private data and generate a comparison digest of the decrypted private data. Compare the comparison digest with the digest of the private data of the peer proxy to confirm whether the private data is valid.
[0091] Specifically, the second agent stores the received private data locally. The data requester obtains the private data through the second agent and uses the public key to sign and verify the private data, confirming the identity of the user who provided the private data. For example, if the verified signatures match, the data provider is confirmed as the counterparty in the transaction.
[0092] After signature verification, the second agent decrypts the private data using the private key and generates a comparison digest of the decrypted private data. This comparison digest can be compared with the digest of the private data sent by the first agent to determine whether the private data has been tampered with. If the comparison digest does not match the sent digest, the private data can be considered to have been tampered with, and the transaction process can be traced, thereby ensuring the security of data transactions.
[0093] In one embodiment, the proxy method further includes, but is not limited to, the following steps:
[0094] Step S301: Send a synchronization request to the peer agent;
[0095] Step S302: Receive the digest list of private data returned by the peer agent according to the synchronization request, and compare the digest list with the private data stored in itself;
[0096] Step S303: When it is determined that private data is missing, return a request list to the peer agent so that the peer agent can send the private data according to the request list.
[0097] In this embodiment, the peer agent is the first agent. The second agent sends a synchronization request to the peer agent. The first agent returns a summary list of private data based on the synchronization request. The second agent compares the summary list with its own stored private data to confirm whether any private data is missing. When the second agent determines that there is missing private data, it returns a request list to the first agent. The first agent sends the private data based on the request list, thereby completing the private data synchronization operation. The step of the first agent sending private data to the second agent in the synchronization process can be referred to steps S410 to S520 of the above embodiment, and will not be repeated here.
[0098] It should be noted that the private data synchronization process is executed periodically by all agents. The second agent periodically sends synchronization requests to the first agent, thereby ensuring the consistency of the private data stored in the first agent and the second agent.
[0099] To more clearly illustrate the specific steps and flow of the proxy method in the above embodiments, the following two embodiments are used for explanation.
[0100] Example 1:
[0101] Taking the Fabric platform's privacy data transaction implementation process as an example, this includes the deployment, transaction, and data acquisition processes.
[0102] See Figure 7 As shown, the deployment process includes the following steps:
[0103] Step S701: Deploy the agent program to the local blockchain node environment, place the certificate in the cert certificate directory, and place the smart contracts to be installed in the corresponding language under the contracts directory;
[0104] Step S702: Modify the config / config.yaml configuration file, set the blockchain platform type to be connected, replace the local storage DB address, and configure the peer proxy address;
[0105] Step S703: Modify the config / config.yaml configuration file to complete the relevant configurations for the local blockchain platform;
[0106] Step S704: Execute the agent start command to start the agent service program;
[0107] Step S705: Deployment process complete.
[0108] The Fabric platform includes organization name, peer and orderer addresses, and certificate configuration.
[0109] See Figure 8 As shown, the transaction process includes the following steps:
[0110] Step S706: User A submits a transaction through the first agent, including encrypted private data, digest, signature, and the organization and account to which User B belongs;
[0111] Step S707: The first agent initiates a transaction with the blockchain platform and completes the transaction recording through a smart contract;
[0112] Step S708: The first agent uploads the encrypted private data to the local ledger node and stores it in the local database;
[0113] Step S709: The first agent pushes private data to the second agent of the accounting node where user B is located. The second agent receives the private data and stores it in the local database, completing the private data transaction.
[0114] The transaction log includes a summary of private data to ensure that transactions are traceable, while the smart contract can automatically deduct points from user B and add points to user A.
[0115] See Figure 9 As shown, the data acquisition process includes the following steps:
[0116] Step S710: User B obtains private data from the second agent, providing the transaction account and transaction ID;
[0117] Step S711: The second agent confirms that the private data belongs to user B based on the transaction account and transaction ID, and returns the address to user B to retrieve the private data;
[0118] Step S712: User B obtains private data through the address and uses User A's public key to sign and verify the private data, confirming that the data was provided by User A;
[0119] Step S713: User B decrypts the private data using the private key, generates a comparison digest of the private data, and compares it with the digest provided by User A to confirm that the data has not been tampered with.
[0120] Step S714: End the private data acquisition process.
[0121] Example 2:
[0122] Taking the cross-platform (Fabric-Fscio) privacy data transaction implementation process as an example, this includes the deployment, transaction, and data acquisition processes.
[0123] The deployment process includes the following steps:
[0124] Step S801: Deploy the agent program to the local blockchain node environment, place the certificate in the cert certificate directory, and place the smart contracts to be installed in the corresponding language under the contracts directory;
[0125] Step S802: Modify the config / config.yaml configuration file, set the blockchain platform type to be connected, replace the local storage DB address, and configure the peer proxy address;
[0126] Step S803: Modify the config / config.yaml configuration file to complete the relevant configurations for the local blockchain platform;
[0127] Step S804: Execute the agent start command to start the agent service program;
[0128] Step S805: Deployment process complete.
[0129] The Fabric platform includes organization name, peer, orderer address, encryption algorithm, and certificate configuration.
[0130] The transaction process includes the following steps:
[0131] Step S806: User A submits a transaction through the first agent, including encrypted private data, digest, signature, and the organization and account to which the transacting party B belongs;
[0132] Step S807: The first agent initiates a transaction with the blockchain platform and completes the transaction recording through a smart contract;
[0133] Step S808: The first agent uploads the encrypted data to the local blockchain ledger node and stores it in the local database;
[0134] Step S809: The first agent pushes private data to the second agent of the accounting node where user B is located. The second agent receives the data and stores it in the local database, completing the private data transaction.
[0135] The transaction log includes a summary of private data to ensure that transactions are traceable, while the smart contract can automatically deduct points from user B and add points to user A.
[0136] The data acquisition process includes the following steps:
[0137] Step S810: User B obtains private data from the second agent, providing the transaction account and transaction ID;
[0138] Step S811: The second agent confirms that the private data belongs to user B based on the transaction account and transaction ID, and returns the address to user B to retrieve the private data;
[0139] Step S812: User B obtains private data through the address and uses User A's public key to sign and verify the private data, confirming that the data was provided by User A;
[0140] Step S813: User B decrypts the private data using the private key, generates a comparison digest of the private data, and compares it with the digest provided by User A to confirm that the data has not been tampered with.
[0141] Step S814: End the private data acquisition process.
[0142] Additionally, one embodiment of the present invention provides an apparatus comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor and the memory may be connected via a bus or other means.
[0143] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0144] It should be noted that the terminal in this embodiment may include, for example, Figure 1 The system architecture platform 100 in the illustrated embodiment, the terminal in this embodiment, and so on Figure 1 The system architecture platform 100 in the illustrated embodiments belongs to the same inventive concept, therefore these embodiments have the same implementation principle and technical effect, which will not be described in detail here.
[0145] The non-transient software program and instructions required to implement the proxy method of the above embodiments are stored in memory. When executed by a processor, the proxy method in the above embodiments is executed, for example, the one described above. Figure 2 Method steps S100 to S300 in the text Figure 3 Method steps S110 to S120, Figure 4 Method steps S310 to S330 in the text Figure 5 Method steps S400 to S500 Figure 6 Method steps S100 to S102, Figure 7 Method steps S701 to S705 Figure 8 Method steps S706 to S709 in the above method Figure 9 Method steps S710 to S714.
[0146] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0147] Furthermore, one embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions that are executed by a processor or controller, for example, by a processor in the above-described terminal embodiment, causing the processor to perform the proxy method in the above-described embodiment, for example, performing the above-described... Figure 2 Method steps S100 to S300 in the text Figure 3 Method steps S110 to S120, Figure 4 Method steps S310 to S330 in the text Figure 5 Method steps S400 to S500 Figure 6 Method steps S100 to S102, Figure 7 Method steps S701 to S705 Figure 8 Method steps S706 to S709 in the above method Figure 9 Method steps S710 to S714.
[0148] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0149] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.
Claims
1. A proxy method for a first proxy, comprising: Obtain the user's transaction data, which includes transaction requests and private data; The private data is stored locally, and the transaction request is sent to the blockchain platform so that the blockchain platform can complete the transaction according to the transaction request. After the transaction is completed, the private data is sent to the peer agent for transaction verification; Receive a synchronization request from the peer proxy and return a summary list of the private data according to the synchronization request, so that the peer proxy can compare the summary list with the private data stored in itself, and return a request list when it is determined that the private data is missing; The private data is sent to the peer proxy according to the request list.
2. The proxy method according to claim 1, characterized in that, Before obtaining the user's transaction data, the process also includes: A digest is generated based on the private data, the private data is encrypted, and the encrypted private data is signed. The transaction request is generated based on the digest and the signature.
3. The proxy method according to claim 1, characterized in that, The step of sending the private data to the peer agent for transaction verification after the transaction is completed includes: Send a push request to the peer proxy; Receive response information sent by the peer agent in accordance with the push request; The private data is sent to the peer agent based on the response information, so that the peer agent can verify the transaction based on the private data.
4. The proxy method according to claim 3, characterized in that, Sending the private data to the peer agent based on the response information includes: Based on the response information, the private data is sent to the peer proxy via the Gossip protocol.
5. The proxy method according to any one of claims 1 to 4, characterized in that, Also includes: If the storage time of the private data exceeds the preset retention time, the private data will be deleted.
6. The proxy method according to claim 1, characterized in that, The receiving of synchronization requests from peer proxies includes: Periodically execute the process of receiving synchronization requests from the peer proxy.
7. A proxy method for a second proxy, comprising: Obtain private data sent by the peer agent, the private data being stored in the peer agent and used to verify transactions initiated by the peer agent through sending transaction requests to the blockchain platform; Transaction verification is performed on the private data; Send a synchronization request to the peer proxy; Receive a list of digests of the private data returned by the peer proxy in accordance with the synchronization request, and compare the list of digests with the private data stored in the user's own database. When it is determined that private data is missing, a request list is returned to the peer agent so that the peer agent can send the private data according to the request list.
8. The proxy method according to claim 7, characterized in that, The transaction verification of the private data includes: The private data is signed and verified to confirm the user who provided the private data; The private data is decrypted, and a comparison digest is generated from the decrypted private data. The comparison digest is then compared with the digest of the private data of the peer proxy to confirm whether the private data is valid.
9. The proxy method according to claim 7, characterized in that, Sending a synchronization request to the peer agent includes: Periodically execute the sending of synchronization requests to the peer proxy.
10. An apparatus comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the proxy method as described in any one of claims 1 to 9.
11. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the proxy method as described in any one of claims 1 to 9.