Transaction Data Processing Method, Device, and Server

Abstract

This specification provides a transaction data processing method, apparatus, and server. Based on this method, after the first user terminal determines the first type of bill to be consumed in response to a transaction data processing request and creates the second type of bill to be effective according to the corresponding rules, it can first send an authorization request for the first type of bill to the supervision server; the supervision server performs a consistency check on the first type of bill carried in the authorization request, and generates and feeds back an authorization certificate for the first type of bill in the case where the consistency check passes; the first user terminal generates a transaction content according to the first authorization certificate, the first type of bill, and the second type of bill; and uses the transaction private key generated for the transaction data processing request to sign to obtain a transaction signature; then combines the transaction content and the transaction signature to obtain a transaction message; and sends the transaction message to the transaction server deployed with the smart contract for specific transaction data processing.

Description

Technical Field

[0001] This specification belongs to the field of Internet technologies, and particularly relates to a method, apparatus, and server for processing transaction data. Background Art

[0002] Existing blockchain transaction systems often cannot effectively protect the relevant data privacy during the transaction data processing while supporting supervision.

[0003] For the above problems, no effective solution has been proposed yet. Summary of the Invention

[0004] This specification provides a method, apparatus, and server for processing transaction data, which can effectively protect the user privacy of users participating in transactions and the resource value data privacy related to transactions while introducing supervision in a blockchain-based transaction system, avoid the leakage of relevant privacy data, and better protect the data security during the transaction data processing.

[0005] An embodiment of this specification provides a method for processing transaction data, which is applied to a first user terminal and includes: responding to a transaction data processing request, determining a first type of bill to be consumed; and creating a second type of bill to be effective; generating an authorization request for the first type of bill and sending the authorization request to a supervision server; wherein the authorization request carries at least the first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server performs a consistency check on the first type of bill according to a preset check rule and the first observation identifier, and feeds back a first authorization certificate for the first type of bill when it is determined that the consistency check passes; generating a transaction content according to the first authorization certificate, the first type of bill, and the second type of bill; and signing the transaction content with a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request; combining the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; and sending the transaction message to a transaction server; wherein the transaction server is deployed with a smart contract.

[0006] In one embodiment, creating a second type of bill to be effective includes: determining a resource value of the second type of bill according to the transaction data processing request; obtaining a second observation public key and a second payment public key of a second user; generating a second temporary public key and a second bill public key for the second type of bill according to the second observation public key and the second payment public key of the second user; generating encrypted data for the second type of bill according to the resource value of the second type of bill; and constructing the second type of bill by using the second temporary public key, the second bill public key, and the encrypted data.

[0007] In one embodiment, generating a second temporary public key and a second bill public key for a second type of bill according to the second observation public key and the second payment public key of the second user includes: obtaining a random number as the second temporary private key for the second type of bill; generating a corresponding second temporary public key according to the second temporary private key; constructing intermediate data by using the second observation public key and the second temporary private key of the second user based on a preset construction rule; and constructing the second bill public key according to the intermediate data and the second payment public key.

[0008] In one embodiment, generating transaction content according to the first authorization credential, the first type of bill, and the second type of bill includes: constructing a first bill private key for the first type of bill; signing the first type of bill with the first bill private key to obtain a corresponding first bill signature; generating in-band transmission ciphertext data for the second type of bill and a proof document for the first type of bill and the second type of bill; and combining the first type of bill, the first bill signature, the first authorization credential, the second type of bill, the in-band transmission ciphertext data, and the proof document to obtain the transaction content.

[0009] In one embodiment, constructing a first bill private key for the first type of bill includes: obtaining a first bill public key of the first type of bill; and constructing the first bill private key by using the first bill public key, the first observation private key, and the first payment private key of the first user.

[0010] In one embodiment, constructing the first bill private key by using the first bill public key, the first observation private key, and the first payment private key of the first user includes:

[0011] Constructing the first bill private key in the following manner:

[0012]

[0013] where p1 is the first bill private key, R1 is the first bill public key, a1 is the first observation private key of the first user, and b1 is the first payment private key of the first user.

[0014] In one embodiment, the proof document includes a zero-knowledge proof document for proving that the resource value of the first type of bill is equal to the resource value of the second type of bill and that the resource value of the second type of bill meets the resource value range requirement.

[0015] In one embodiment, the method further includes: receiving and responding to an initialization request to generate a first observation secret key and a first payment secret key; where the first observation secret key includes a first observation private key and a first observation public key; the first payment secret key includes a first payment public key and a first payment private key; and providing the first observation secret key to a regulatory server.

[0016] In one embodiment, the first type of bills includes bills based on the UTXO model.

[0017] An embodiment of this specification also provides a transaction data processing method, which is applied to a supervision server and includes: receiving and obtaining a first observation identifier and the first type of bills according to an authorization request for the first type of bills; performing a consistency check on the first type of bills according to a preset check rule and the first observation identifier; and generating and feedbacking a first authorization certificate when it is determined that the consistency check passes.

[0018] In one embodiment, after generating and feedbacking the first authorization certificate, the method further includes: saving the first observation identifier and the first type of bills in a first database.

[0019] In one embodiment, performing a consistency check on the first type of bills according to a preset check rule and the first observation identifier includes: querying a second database according to the first observation identifier to obtain a first observation private key; obtaining a first bill public key, a first temporary public key for the first type of bills, and a first payment public key of a first user; constructing a check public key by using the first temporary public key, the first observation private key, and the first payment public key according to the preset check rule; comparing the check public key with the first bill public key to obtain a corresponding comparison result; and determining whether the first type of bills passes the consistency check according to the comparison result.

[0020] In one embodiment, constructing a check public key by using the first temporary public key, the first observation private key, and the first payment public key according to a preset check rule includes:

[0021] Constructing the check public key in the following manner:

[0022]

[0023] Where P′1 is the check public key, R1 is the first temporary public key, a1 is the first observation private key, G is the base point on the elliptic curve group, and B1 is the first payment public key.

[0024] In one embodiment, before receiving and obtaining an authorization request for the first type of bills, the method further includes: obtaining a first observation secret key provided by a first user terminal; and saving the first observation secret key in a second database.

[0025] In one embodiment, the method further includes: querying a smart contract to determine abnormal bills related to an abnormal transaction; and determining the originator and / or recipient of the abnormal bills by querying the first database and / or the second database according to the abnormal bills.

[0026] The embodiments of this specification also provide a transaction data processing method, which is applied to a transaction server deployed with a smart contract and includes: obtaining a transaction message; performing verification processing on the transaction message; wherein, the verification processing at least includes: verifying the validity of a first authorization credential; and in the case where it is determined that the transaction message passes the verification, performing corresponding transaction data processing according to the transaction message.

[0027] In one embodiment, in the case where it is determined that the transaction message passes the verification, performing corresponding transaction data processing according to the transaction message includes: determining a first type of bill to be consumed and a second type of bill to be made effective according to the transaction message; destroying the first type of bill saved in the smart contract; and saving the second type of bill in the smart contract.

[0028] In one embodiment, the verification processing further includes at least one of the following: verifying the validity of a first bill signature, verifying the validity of a certification document, and verifying the validity of a transaction signature.

[0029] The embodiments of this specification also provide a transaction data processing method, which is applied to a first user terminal and includes: responding to a transaction data processing request, determining a first type of bill to be consumed; and creating a second type of bill to be made effective; wherein, the second type of bill at least includes a second temporary public key, a second bill public key, and ciphertext data; generating a transaction content according to the first type of bill and the second type of bill; and signing the transaction content with a transaction private key to obtain a corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request; combining the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; and sending the transaction message to a transaction server; wherein, the transaction server is deployed with a smart contract.

[0030] The embodiment of this specification also provides a transaction data processing device, which is applied to a first user terminal and includes: a first processing module, configured to respond to a transaction data processing request, determine a first type of bill to be consumed; and create a second type of bill to be effective; a second processing module, configured to generate an authorization request for the first type of bill and send the authorization request to a supervision server; wherein, the authorization request carries at least the first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server performs a consistency check on the first type of bill according to a preset check rule and the first observation identifier, and feeds back a first authorization certificate for the first type of bill when it is determined that the consistency check passes; a third processing module, configured to generate a transaction content according to the first authorization certificate, the first type of bill, and the second type of bill; and sign the transaction content with a transaction private key to obtain a corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request; a combination module, configured to combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; a sending module, configured to send the transaction message to a transaction server; wherein, the transaction server is deployed with a smart contract.

[0031] The embodiment of this specification also provides a transaction data processing device, which is applied to a supervision server and includes: an acquisition module, configured to receive and acquire a first observation identifier and a first type of bill according to an authorization request for the first type of bill; a verification module, configured to perform a consistency check on the first type of bill according to a preset check rule and the first observation identifier; a generation module, configured to generate and feed back a first authorization certificate when it is determined that the consistency check passes.

[0032] The embodiment of this specification also provides a transaction data processing device, which is applied to a transaction server deployed with a smart contract and includes: an acquisition module, configured to acquire a transaction message; a verification module, configured to perform verification processing on the transaction message; wherein, the verification processing at least includes: verifying the validity of a first authorization certificate; a processing module, configured to perform corresponding transaction data processing according to the transaction message when it is determined that the transaction message verification passes.

[0033] The embodiment of this specification also provides a server, which includes a processor and a memory for storing processor-executable instructions, and the processor implements the steps of the transaction data processing method when executing the instructions.

[0034] The embodiment of this specification also provides a computer-readable storage medium, on which computer instructions are stored, and the instructions implement the steps of the transaction data processing method when being executed by a processor.

[0035] Based on the transaction data processing method, device and server provided in this specification, when a first user holding a first user terminal needs to conduct a transfer transaction to a second user terminal held by a second user, the first user terminal can receive and respond to the transaction data processing request initiated by the first user, determine the first type of bill to be consumed, and create the second type of bill to be effective according to the corresponding rules; then, the first user terminal can first send the generated authorization request for the first type of bill to the supervision server; wherein the authorization request carries at least the first observation identifier of the first user's observation key and the first type of bill; the supervision server performs a consistency check on the first type of bill carried in the authorization request according to the preset verification rules and the first observation identifier to verify the user information of the first user , and make a record; if it is determined that the consistency check has passed, the regulatory server generates and feedbacks an authorization certificate for the first type of bill; then, the first user terminal can generate transaction content based on the first authorization certificate, the first type of bill, and the second type of bill; and use the transaction private key generated for the transaction data processing request to sign the transaction content to obtain the corresponding transaction signature; then combine the transaction content and the transaction signature to generate a transaction message; and send the transaction message to the transaction server deployed with the smart contract for processing; the transaction server can first verify the transaction message; if it is determined that the verification has passed, then perform specific transaction data processing based on the transaction message, for example, destroying the first type of bill stored in the smart contract, and / or storing the second type of bill in the smart contract, etc. In this way, while introducing supervision in the blockchain-based transaction system, it can effectively protect the user privacy of users participating in the transaction and the data privacy of resource values related to the transaction, avoid the leakage of private data related to the transaction, and better protect the data security of the transaction data processing process. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of this specification, the following is a brief introduction to the drawings required for use in the embodiments. The drawings described below are only some of the embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0037] Figure 1 This is a flowchart of a transaction data processing method provided by an embodiment of this specification;

[0038] Figure 2 This is a schematic diagram of an embodiment of a transaction data processing method provided by an embodiment of this specification, applied in a scenario example;

[0039] Figure 3 This is a schematic diagram of an embodiment of a transaction data processing method provided by an embodiment of this specification, applied in a scenario example;

[0040] Figure 4 It is a schematic diagram of an embodiment applying the transaction data processing method provided in the embodiments of this specification in a scenario example;

[0041] Figure 5 It is a schematic diagram of an embodiment applying the transaction data processing method provided in the embodiments of this specification in a scenario example;

[0042] Figure 6 It is a schematic flowchart of the transaction data processing method provided in an embodiment of this specification;

[0043] Figure 7 It is a schematic flowchart of the transaction data processing method provided in an embodiment of this specification;

[0044] Figure 8 It is a schematic flowchart of the transaction data processing method provided in an embodiment of this specification;

[0045] Figure 9 It is a schematic diagram of the structural composition of a server provided in an embodiment of this specification;

[0046] Figure 10 It is a schematic diagram of the structural composition of a transaction data processing device provided in an embodiment of this specification;

[0047] Figure 11 It is a schematic diagram of the structural composition of a transaction data processing device provided in an embodiment of this specification;

[0048] Figure 12 It is a schematic diagram of the structural composition of a transaction data processing device provided in an embodiment of this specification;

[0049] Figure 13 It is a schematic diagram of the structural composition of a transaction data processing device provided in an embodiment of this specification. Detailed implementation manners

[0050] In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0051] Refer to Figure 1As shown, the embodiments of this specification provide a transaction data processing method, which is specifically applied to the first user terminal. Specifically, the method may include the following content.

[0052] S101: Respond to the transaction data processing request, determine the first type of bill to be consumed; and create the second type of bill to be effective.

[0053] S102: Generate an authorization request for the first type of bill and send the authorization request to the supervision server; wherein, the authorization request carries at least the first type of bill and the first observation identifier of the first observation key of the first user; the supervision server performs consistency verification on the first type of bill according to the preset verification rules and the first observation identifier, and feeds back the first authorization certificate for the first type of bill when it is determined that the consistency verification passes.

[0054] S103: Generate the transaction content according to the first authorization certificate, the first type of bill, and the second type of bill; and sign the transaction content with the transaction private key to obtain the corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request.

[0055] S104: Combine the transaction content and the transaction signature to obtain the transaction message for the transaction data processing request.

[0056] S105: Send the transaction message to the transaction server; wherein, the transaction server deploys a smart contract.

[0057] In some embodiments, the above-mentioned first user terminal may specifically be the terminal device held by the first user. Refer to Figure 2 As shown. The above-mentioned first user can be understood as the initiator or the payer.

[0058] Currently, the first user wants to transfer the resource data of the corresponding resource value to the second user; at the same time, it also hopes to safely complete the transaction data processing for the transfer on the premise of supervision and without disclosing relevant privacy data to the outside.

[0059] Correspondingly, the above-mentioned second user can be understood as the recipient or the payee. Among them, the second user may specifically hold the second user terminal.

[0060] In some embodiments, the above-mentioned first user terminal and second user terminal may specifically include clients deployed on the side of the first user and the second user, which can implement functions such as data collection and data transmission. Specifically, the above-mentioned first user terminal and second user terminal may be, for example, electronic devices such as desktop computers, tablet computers, laptop computers, and smart phones. Alternatively, the above-mentioned first user terminal and second user terminal may also be software applications that can run on the above-mentioned electronic devices. For example, it may be a certain trading APP running on a smart phone, etc.

[0061] In some embodiments, referring to Figure 2 As shown, in a blockchain-based trading system applying the trading data processing method provided in this specification, it further includes a regulatory server and a trading server.

[0062] Among them, the above-mentioned regulatory server can be specifically understood as a server deployed on the side of the regulatory party. The above-mentioned regulatory party is specifically responsible for supervising and auditing relevant trading data on the blockchain to protect the security and compliance of the trading data on the chain.

[0063] The above-mentioned trading server can be specifically understood as a node server on the blockchain responsible for specific trading data processing. The above-mentioned trading server is deployed with corresponding smart contracts. The above-mentioned smart contract can be specifically understood as a computer protocol that aims to spread, verify, or execute a contract in an informatized manner, is used for performing a certain specific data processing, and has the characteristic of being tamper-proof. Based on the above smart contract, it is possible to allow for trusted trading data processing without a third party and in a decentralized manner.

[0064] In this embodiment, the regulatory server and the trading server may specifically include backend servers that can implement functions such as data transmission and data processing. Specifically, the regulatory server and the trading server may be, for example, an electronic device with data operation, storage functions, and network interaction functions. Alternatively, the regulatory server and the trading server may also be software programs running on the electronic device that provide support for data processing, storage, and network interaction. In this embodiment, the number of servers included in the regulatory server and the trading server is not specifically limited. The regulatory server and the trading server may specifically be one server, or several servers, or a server cluster formed by several servers.

[0065] In some embodiments, before specific implementation, the first user terminal and the second user terminal may first perform initialization data processing. Specifically, the method may further include the following: receiving and responding to an initialization request, and generating a first viewing key and a first payment key; wherein, the first viewing key includes a first viewing private key and a first viewing public key; the first payment key includes a first payment public key and a first payment private key; providing the first viewing key to a regulatory server.

[0066] In some embodiments, when providing the first viewing key to a regulatory server during specific implementation, it may include the following: generating a registration request; wherein, the registration request contains the first viewing key; sending the registration request to the regulatory server.

[0067] In some embodiments, before specific implementation, the first user may use the first user terminal to perform an initialization operation to initiate an initialization request. Correspondingly, the first user terminal may receive and respond to the initialization request, and generate a first viewing key and a first payment key.

[0068] Wherein, the above first viewing key and first payment key correspond to the first user (or the account of the first user).

[0069] It should be noted that based on the existing method, the first payment key is often directly used to process transaction data. However, since the first payment key corresponds to the first user, other data parties can easily obtain and track the relevant information of the first user, the initiator of the transaction, based on the first payment key used by the first user to process transaction data, thereby resulting in the leakage of the first user's privacy. The transaction data processing method provided in the embodiments of this specification can effectively avoid the leakage of user privacy because it does not directly use the first payment key to process transaction data, and specific details will be described separately later. In addition, based on the existing method, the first user does not generate and use a viewing key either.

[0070] Specifically, for example, the first user terminal may first generate a random number a1 as the first viewing private key; then, according to the following formula, use the first viewing private key to generate the corresponding first viewing public key A1: A1 = a1·G, where G is the base point on the elliptic curve group, and obtain the first viewing key (or the first viewing key pair): (a1, A1). When generating the first viewing private key and the first viewing public key, the first user terminal may also generate a first viewing identifier corresponding to the first viewing key.

[0071] Similarly, the first user terminal can first generate a random number b1 as the first payment private key; then, according to the following formula, use the first payment private key to generate the corresponding first payment public key B1: B1 = b1·G, where G is the base point on the elliptic curve group, and obtain the first payment secret key: (b1, B1).

[0072] The first user terminal can publicly disclose the first observation public key and the first payment public key, but does not disclose the held first observation private key and the first payment private key.

[0073] Furthermore, the first user terminal can provide the above first observation secret key to the supervision server. The first observation secret key provided to the supervision server can also include a first observation identifier corresponding to the first observation secret key.

[0074] Specifically, when registering with the supervision server, the first user terminal can provide the above first observation secret key to the supervision server by means such as sending an email or sending a registration request, so as to complete the initialization data processing.

[0075] Correspondingly, the supervision server receives the first observation secret key and saves the first observation secret key in the second database.

[0076] Similarly, the second user terminal can respond to the initialization request, first generate a second observation secret key (a2, A2) and a second payment secret key (b2, B2); then publicly disclose the second observation public key A2 and the second payment public key B2, and provide the second observation secret key to the supervision server to complete the initialization data processing. Correspondingly, the supervision server receives the second observation secret key and also saves the second observation secret key in the second database.

[0077] In some embodiments, during specific implementation, for example, when the first user needs to initiate a transfer to the second user, corresponding operations can be first performed on the first user terminal to initiate a transaction data processing request regarding the transfer. Correspondingly, the first user terminal can generate and obtain the transaction data processing request.

[0078] In some embodiments, the above first type of bill can be specifically understood as the bill to be consumed held by the current first user (which can also be called the input bill). The above second type of bill can be specifically understood as the bill to be effective to be transferred to the second user currently (which can also be called the output bill).

[0079] In some embodiments, the first type of bill can specifically include bills based on the UTXO model, etc. Correspondingly, the second type of bill can also specifically include bills based on the UTXO model, etc.

[0080] The above-mentioned UTXO (Unspent Transaction Outputs) model can be specifically understood as a transaction record model in a blockchain network that is different from the account model adopted by conventional methods.

[0081] Based on the UTXO model, each transaction consumes the output of previous transactions (e.g., existing bills, notes, etc.) and generates new output. These new outputs may be consumed through future transactions. All unconsumed outputs are stored in multiple nodes (e.g., sub-accounts) that are associated with and synchronized with the user's account (e.g., the user's e-wallet, main chain account, etc.). The user's account can record the resource data held by the user by accumulating the output stored in the associated nodes. Specific transactions can also be carried out by using the output stored in the associated nodes, and the output stored in each node can only be used once.

[0082] For details, please refer to Figure 3 As shown in the figure, each transaction consumes the UTXO (Input Note) generated by the previous transaction and then generates a new UTXO (Output Note); the balance of an account is the set of all unconsumed UTXO belonging to the address; and transactions can be understood as changes to the UTXO set. The corresponding concepts of account and balance can be abstract concepts on the UTXO set. For example, see Figure 3 , the input of transaction 3 (Transaction3) is the two outputs (UTXO) of transaction 1 (Transaction1) and transaction 2 (Transaction2).

[0083] Of course, it should be noted that the UTXO-based bills listed above are merely illustrative. In practice, depending on specific application scenarios and transaction requirements, the first and second categories of bills mentioned above may also include other types of bills. This specification does not limit this.

[0084] In some embodiments, after obtaining the transaction data processing request, the first user terminal may first respond to the transaction data processing request and determine the resource value of the resource data that the first user wants to transfer to the second user by performing parsing processing.

[0085] The first user terminal can search for valid tickets currently held by the first user based on the resource value, and find one or more tickets whose sum of resource values equals the resource value as the first-category tickets to be consumed. Simultaneously, one or more second-category tickets can be created based on corresponding protocol rules.

[0086] Among them, the sum of the resource values corresponding to the first type of bills is equal to the sum of the resource values corresponding to the second type of bills. Moreover, the resource value corresponding to each first type of bill and the resource value corresponding to each second type of bill should meet the requirement that the resource value is a value greater than 0.

[0087] Specifically, for example, refer to Figure 4 As shown, the above resource data can specifically be token data, and the resource value determined based on the transaction data processing request can be 4 BTC. The first user terminal searches and finds two bills: Bill 1 with a corresponding resource value of 2 BTC and Bill 2 with a corresponding resource value of 3 BTC as two first type of bills. Further, the first user terminal can, according to the corresponding protocol rules, newly create two bills: Bill 3 with a corresponding resource value of 4 BTC and Bill 4 with a corresponding resource value of 1 BTC as two second type of bills. Among them, Bill 1 and Bill 2 can be called the first type of bills to be consumed (or input bills), and Bill 3 and Bill 4 can be called the second type of bills to take effect (or output bills).

[0088] It should be noted that the above-listed token data is only an illustrative explanation. According to specific application scenarios and processing requirements, the above resource data can also include other types of data, such as computing resource data, information resource data, etc.

[0089] In some embodiments, when specifically implementing the creation of the second type of bills to take effect, it may include the following content:

[0090] S1: Determine the resource value of the second type of bill according to the transaction data processing request;

[0091] S2: Obtain the second viewing public key and the second payment public key of the second user;

[0092] S3: Generate a second temporary public key and a second bill public key for the second type of bill according to the second viewing public key and the second payment public key of the second user;

[0093] S4: Generate ciphertext data for the second type of bill according to the resource value of the second type of bill;

[0094] S5: Construct the second type of bill by using the second temporary public key, the second bill public key, and the ciphertext data.

[0095] Among them, the above second temporary public key and the second bill public key do not correspond to the first user or the second user, but correspond to the second type of bill. In this way, when the second temporary public key and the second bill public key are used later, the user information of the participating parties will not be leaked, thus better protecting the user privacy of the participating parties.

[0096] In some embodiments, the first user terminal may query on the blockchain based on the identification information related to the second user (e.g., the username of the second user, the second observation identifier, etc.) to obtain the second observation public key and the second payment public key publicly disclosed by the second user terminal.

[0097] In some embodiments, to better protect the data privacy of the participants, specifically in implementation, the first user terminal may generate a second temporary public key and a second bill public key for the second type of bill based on the stealth address algorithm, using the second observation public key and the second payment public key of the second user.

[0098] In some embodiments, specifically in implementation, the first user terminal may also generate a second temporary public key and a second bill public key for the second type of bill according to the second observation public key and the second payment public key of the second user in the following manner:

[0099] S1: Obtain a random number as the second temporary private key for the second type of bill; and generate the corresponding second temporary public key according to the second temporary private key;

[0100] S2: Based on a preset construction rule, construct intermediate data using the second observation public key and the second temporary private key of the second user;

[0101] S3: Construct the second bill public key according to the intermediate data and the second payment public key.

[0102] In some embodiments, specifically, for example, the first user terminal may first randomly select a random number r from the parameter set Z p as the second temporary private key corresponding to a second type of bill. Wherein, r2 ∈ Z p . Then, the first user terminal may generate the corresponding second temporary public key R2 according to the following formula using the second temporary private key: R2 = r2·G. Wherein, G is the base point on the elliptic curve group.

[0103] Then, the first user terminal may construct the intermediate data c2 according to the preset construction rule and the following formula using the second observation public key and the second temporary private key: Wherein, H represents the hash operation, A2 is the second observation public key, and r2 is the second temporary public key corresponding to the second type of bill.

[0104] Finally, the first user terminal may construct the corresponding second bill public key P2 according to the following formula using the second temporary public key and the second payment public key: P2 = B2 + c2·G. Wherein, B2 is the second payment public key.

[0105] In some embodiments, each confidential data corresponds to a second type of bill, and the resource value of the corresponding second type of bill is hidden. When specifically implementing the generation of the confidential data about the second type of bill according to the resource value of the second type of bill, it may include: using a cryptographic commitment algorithm (commitment) or an encryption algorithm (encryption) to generate the confidential data about the second type of bill according to the resource value of the corresponding second type of bill.

[0106] In some embodiments, referring to Figure 5 As shown, the second temporary public key, the second bill public key, and the confidential data can be combined to construct the corresponding second type of bill. Further, the second type of bill may also include the bill identifier of the second type of bill. Correspondingly, the second type of bill can be expressed in the following form: [bill identifier of the second type of bill, confidential data, second temporary public key, second bill public key]. Among them, the above bill identifier can be specifically understood as an identification information that has no association with the participating party and can correspond to the bill one by one. For example, the serial number of the bill, the bill number, etc.

[0107] The first type of bill and the second type of bill have the same formal structure and can be expressed as: [bill identifier of the first type of bill, confidential data, first temporary public key, first bill public key].

[0108] In some embodiments, different from the existing methods, before using the first type of bill to be consumed to generate a transaction message, the first user terminal also needs to apply to the supervision server for an authorization credential for the first type of bill (i.e., the authorization credential for using the first type of bill). According to the corresponding protocol rules, the first user terminal can only normally use the first type of bill to generate the corresponding transaction message when it obtains the authorization credential generated by the supervision server.

[0109] In some embodiments, when specifically implementing, the first user terminal can generate an authorization request for the first type of bill to be consumed; among them, the authorization request carries at least the first observation identifier of the first user and the first type of bill.

[0110] Further, when the first user terminal needs to use multiple first type of bills, it can also make a batch application for multiple first type of bills. Correspondingly, the authorization request sent to the supervision server can carry multiple first type of bills at one time.

[0111] In some embodiments, the supervision server can first receive and obtain the first observation identifier and the first type of bill according to the above authorization request; then perform a consistency check on the first type of bill according to the preset verification rules and the first observation identifier; and generate and feedback the first authorization credential to the first user terminal when it is determined that the consistency check passes. One first authorization credential corresponds to one first type of bill.

[0112] In some embodiments, after the consistency check passes and the first authorization voucher is generated and fed back, the supervision server may also save the first observation identifier and the first type of bill in the first database for subsequent backtracking queries when processing abnormal transactions. Specifically, the first database may store the corresponding relationship between the first observation identifier and the first type of bill.

[0113] In some embodiments, when performing the consistency check on the first type of bill according to the preset check rules and the first observation identifier, the following specific operations may be included:

[0114] S1: Query the second database according to the first observation identifier to obtain the first observation private key;

[0115] S2: Obtain the first bill public key, the first temporary public key for the first type of bill, and the first payment public key of the first user;

[0116] S3: Construct a verification public key according to the preset check rules using the first temporary public key, the first observation private key, and the first payment public key;

[0117] S4: Compare the verification public key with the first bill public key to obtain the corresponding comparison result;

[0118] S5: Determine whether the consistency check of the first type of bill passes according to the comparison result.

[0119] In some embodiments, specifically, the supervision server may find the first observation secret key matching the first observation identifier by querying the second database, and obtain the first observation private key a1 from the first observation secret key.

[0120] In some embodiments, the supervision server may obtain the first bill public key P1 and the first temporary public key R1 corresponding to the first type of bill by parsing the first type of bill; at the same time, obtain the first payment public key B1 corresponding to the first user by querying.

[0121] In some embodiments, when constructing the verification public key according to the preset check rules using the first temporary public key, the first observation private key, and the first payment public key, the following specific operations may be included:

[0122] Construct the verification public key in the following manner:

[0123]

[0124] where P′1 is the verification public key, R1 is the first temporary public key, a1 is the first observation private key, G is the base point on the elliptic curve group, and B1 is the first payment public key.

[0125] In some embodiments, the supervision server may compare the verification public key P′1 with the first bill public key P1 to obtain a corresponding comparison result; according to the comparison result, when it is determined that the verification public key and the first bill public key are the same, it may be determined that the consistency verification of the first type of bill passes, and it is determined that the first type of bill is a trustworthy bill generated according to the corresponding protocol rules. At the same time, the first user using the first type of bill may be determined, and then a first authorization credential corresponding to the first type of bill may be generated and fed back to the first user terminal.

[0126] Specifically, the supervision server may use the held supervision private key to sign the first type of bill to obtain a corresponding first authorization credential.

[0127] On the contrary, when it is determined that there is a difference between the verification public key and the first bill public key, it may be determined that the consistency verification of the first type of bill fails, and then the first authorization credential for the first type of bill will not be generated. Further, the supervision server may also generate and feed back an error prompt regarding the first type of bill to the first user terminal so that the first user terminal can re-select the first type of bill that meets the requirements.

[0128] In some embodiments, after receiving the first authorization credential for the first type of bill, the first user terminal may use the first authorization credential, the first type of bill, and the second type of bill to generate the transaction content of the transaction message; at the same time, a one-time transaction secret key for this transaction (or this transaction data processing request) may be generated; then, the transaction content may be signed using the transaction secret key to obtain a corresponding transaction signature; and then the transaction signature and the transaction content may be combined to obtain a corresponding transaction message.

[0129] It should be noted that the above transaction secret key is the secret key data corresponding to this transaction (or this transaction data processing request), and based on this transaction secret key, other data parties cannot trace the first user. In this embodiment, the first user uses the above transaction secret key to sign instead of the first payment secret key corresponding to the first user, which can better hide the user information of the first user, thereby effectively protecting the user data privacy of the first user.

[0130] In some embodiments, the above-mentioned generation of the transaction content according to the first authorization credential, the first type of bill, and the second type of bill may specifically include the following when implemented:

[0131] S1: Construct a first bill private key for the first type of bill;

[0132] S2: Use the first bill private key to sign the first type of bill to obtain a corresponding first bill signature;

[0133] S3: Generate the in-band transmission ciphertext data for the second type of bill and the certification documents for the first type of bill and the second type of bill;

[0134] S4: Combine the first type of bill, the first bill signature, the first authorization voucher, the second type of bill, the in-band transmission ciphertext data, and the certification documents to obtain the transaction content.

[0135] In some embodiments, to construct the first bill private key for the first type of bill, specifically, the following steps may be included: Obtain the first bill public key of the first type of bill; Use the first bill public key, as well as the first observation private key and the first payment private key of the first user, to construct the first bill private key.

[0136] In some embodiments, similar to the second type of bill, which are all generated according to the same preset construction rules, the first type of bill also includes information such as the first bill public key and the first temporary public key corresponding to the first type of bill. Correspondingly, the first user terminal can obtain the first bill public key by parsing the first type of bill.

[0137] In some embodiments, specifically, based on the relevant characteristics of the preset construction rules, use the first bill public key, as well as the first observation private key and the first payment private key of the first user, to construct the first bill private key in the following manner:

[0138]

[0139] Where p1 is the first bill private key, R1 is the first bill public key, a1 is the first observation private key of the first user, and b1 is the first payment private key of the first user.

[0140] It should be noted that since the data structure of the second type of bill is the same as that of the first type of bill, after the second user obtains the above-mentioned second type of bill through transfer, the second user can use a similar method to obtain and use the second bill public key, as well as the second observation private key and the second payment private key of the second user, to construct the second bill private key for the second type of bill; and then use the second bill private key to sign the second type of bill to use the second type of bill obtained through transfer.

[0141] In some embodiments, the certification document includes a zero-knowledge proof document for proving that the resource value of the first type of bill is equal to the resource value of the second type of bill, and the resource value of the second type of bill meets the resource value range requirements. Among them, the above-mentioned resource value range requirements may specifically include: the resource value is greater than or equal to 0 and does not exceed the total sum of the resource values corresponding to the bills held by the first user.

[0142] In some embodiments, specifically, the above-mentioned zero-knowledge proof document can be generated according to the zero-knowledge proof algorithm.

[0143] In some embodiments, during specific implementation, the resource value of the second type of bill can be encrypted using the second observation public key of the second user to obtain the in-band transmission ciphertext data corresponding to the second type of bill. Correspondingly, after receiving the above transaction message, the second user terminal can decrypt the above in-band transmission ciphertext data using the held second observation private key to obtain the resource value corresponding to the second type of bill, so as to verify the resource data of the transfer initiated by the first user.

[0144] In some embodiments, the corresponding transaction content can be obtained by combining the first type of bill, the first bill signature, the first authorization certificate, the second type of bill, the in-band transmission ciphertext data, and the supporting document, and can be expressed in the following form: [the first type of bill, the first bill signature, the first authorization certificate, the second type of bill, the in-band transmission ciphertext data, the supporting document].

[0145] Furthermore, for a request involving multiple (e.g., m) first type of bills and multiple (e.g., n) second type of bills in a transaction, the above transaction content can be expressed in the following form: [m * the first type of bill, m * the first bill signature, m * the first authorization certificate, n * the second type of bill, n * the in-band transmission ciphertext data, the supporting document].

[0146] In some embodiments, after obtaining the transaction message, the transaction message can be uploaded to the blockchain deployed with the smart contract for persistent processing.

[0147] During specific implementation, refer to Figure 2 As shown, the first user terminal can send the transaction to the transaction server deployed with the smart contract. Correspondingly, the transaction server receives and obtains the transaction message.

[0148] The transaction server can first perform verification processing on the transaction message according to the corresponding protocol rules; in the case of determining that the transaction message passes the verification, then perform specific transaction data processing according to the transaction content in the transaction message.

[0149] In some embodiments, the above verification processing at least includes: verifying the validity of the first authorization certificate. Specifically, the transaction server can obtain the regulatory public key publicly disclosed by the regulatory server and use the regulatory public key to verify the validity of the first authorization certificate.

[0150] In some embodiments, the above verification processing may further include one or more of the following: verifying the validity of the first bill signature, verifying the validity of the supporting document, verifying the validity of the transaction signature, etc.

[0151] It should be noted that the verification processes listed above are merely illustrative and other related verification processes may be introduced during implementation depending on specific circumstances and security requirements.

[0152] In some embodiments, the transaction server determines that the transaction message has passed verification when it determines that all verification processes have passed verification.

[0153] In some embodiments, upon determining that the transaction message has passed verification, the aforementioned corresponding transaction data processing is performed based on the transaction message. Specifically, this may include: determining, based on the transaction message, the first-category bill to be consumed and the second-category bill to be validated; destroying the first-category bill stored in the smart contract; and storing the second-category bill in the smart contract, thereby completing the corresponding transaction data processing. Accordingly, the second user terminal may obtain and use the second-category bill through the smart contract.

[0154] As can be seen from the above, based on the transaction data processing method provided in the embodiments of this specification, when a first user holding a first user terminal needs to transfer money to a second user, the first user terminal can receive and respond to the transaction data processing request initiated by the first user to determine the first type of bill to be consumed, and create the second type of bill to be effective according to the corresponding rules; then, the first user terminal can first send the generated authorization request for the first type of bill to the supervision server; wherein the authorization request carries at least the first observation identifier of the observation key of the first user and the first type of bill; the supervision server performs a consistency check on the first type of bill carried in the authorization request according to the preset verification rules and the first observation identifier to verify the identity of the first user and make a record; If the consistency check is confirmed to have passed, the regulatory server generates and feeds back an authorization certificate for the first type of bill. Furthermore, the first user terminal can generate transaction content based on the first authorization certificate, the first type of bill, and the second type of bill. The transaction content is signed using the transaction private key for the transaction data processing request to obtain a corresponding transaction signature. The transaction content and the transaction signature are then combined to generate a transaction message. The transaction message is then sent to a transaction server deployed with a smart contract for processing. The transaction server can first verify the transaction message. If the verification is confirmed to have passed, specific transaction data processing can be performed based on the transaction message, such as destroying the first type of bill stored in the smart contract and storing the second type of bill in the smart contract. This allows for the introduction of regulation into a blockchain-based transaction system while effectively protecting the privacy of users participating in the transaction, as well as the privacy of resource values related to the transaction, preventing the leakage of relevant privacy data and better protecting data security during the transaction data processing process.

[0155] See Figure 6As shown, the embodiments of the present specification also provide a transaction data processing method. Specifically, this method is applied to the supervision server side. During specific implementation, it may include the following content.

[0156] S601: Receive and obtain a first observation identifier and a first type of bill according to an authorization request for the first type of bill.

[0157] S602: Perform consistency verification on the first type of bill according to a preset verification rule and the first observation identifier.

[0158] S603: Generate and feedback a first authorization voucher when it is determined that the consistency verification passes.

[0159] In some embodiments, after generating and feedbacking the first authorization voucher, during specific implementation of the method, it may further include the following content: Save the first observation identifier and the first type of bill in a first database.

[0160] In some embodiments, the corresponding relationship between the first observation identifier and the first type of bill may specifically be recorded in the first database.

[0161] In some embodiments, the above-mentioned performing consistency verification on the first type of bill according to a preset verification rule and the first observation identifier may specifically include the following content: Query a second database according to the first observation identifier to obtain a first observation private key; Obtain a first bill public key, a first temporary public key for the first type of bill, and a first payment public key of a first user; According to the preset verification rule, use the first temporary public key, the first observation private key, and the first payment public key to construct a verification public key; Compare the verification public key with the first bill public key to obtain a corresponding comparison result; Determine whether the first type of bill passes the consistency verification according to the comparison result.

[0162] In some embodiments, the above-mentioned constructing a verification public key according to a preset verification rule using the first temporary public key, the first observation private key, and the first payment public key may specifically include:

[0163] Construct the verification public key in the following manner:

[0164]

[0165] Where P1′ is the verification public key, R1 is the first temporary public key, a1 is the first observation private key, G is the base point on the elliptic curve group, and B1 is the first payment public key.

[0166] In some embodiments, the regulatory server may specifically use the held regulatory private key to sign the first type of bills that pass the consistency check, obtaining a first authorized signature corresponding to the first type of bills. Among them, the regulatory public key corresponding to the regulatory private key may be provided to the transaction server or made public.

[0167] In some embodiments, before receiving and processing the authorization request for the first type of bills, when the method is specifically implemented, it may further include: obtaining a first observation key provided by the first user terminal; saving the first observation key in a second database.

[0168] Specifically, the regulatory server may receive a registration request sent by the user terminal during registration; parse the registration request to obtain the observation key, and save the observation key in the second database.

[0169] In some embodiments, the above registration request may specifically further carry a user identifier of the user (for example, user information such as the user's username, user number, etc.); the above observation key may further include an observation identifier corresponding to the observation key.

[0170] Correspondingly, the regulatory server may further establish a correspondence between the user identifier and the observation identifier; and record the correspondence between the user identifier and the observation identifier in the second database.

[0171] In some embodiments, the method further includes: querying the smart contract to determine abnormal bills related to abnormal transactions; based on the abnormal bills, determining the initiator and / or recipient of the abnormal bills by querying the first database and / or the second database.

[0172] In some embodiments, when the regulatory server discovers an abnormal transaction, it may first query the smart contract to obtain an abnormal transaction message related to the abnormal transaction; then, by parsing the abnormal transaction message, determine the abnormal bills related to the abnormal transaction (including abnormal first type of bills and / or abnormal second type of bills); further, by querying the relevant data (including the correspondence between data) stored in the first database and / or the second database, determine the initiator and / or recipient of the abnormal bills as abnormal users. Furthermore, an abnormal risk label may be set for the above abnormal users; and targeted monitoring and tracking may be performed on the users with the set abnormal risk labels to achieve the supervision of on-chain transaction data and maintain the security of transaction data processing on the blockchain-based transaction system.

[0173] In addition, the regulatory server may also audit and verify the on-chain transaction data by using the data recorded in the first database and / or the second database.

[0174] Based on the transaction data processing method provided in the embodiments of this specification, the supervision server can effectively supervise the transaction data on the blockchain-based transaction system to protect the security of transaction data.

[0175] Refer to Figure 7 As shown, the embodiments of this specification also provide a transaction data processing method. Among them, this method is specifically applied to the transaction server side. When specifically implemented, it may include the following content.

[0176] S701: Obtain a transaction message;

[0177] S702: Perform verification processing on the transaction message; wherein, the verification processing at least includes: verifying the validity of the first authorization credential;

[0178] S703: When it is determined that the transaction message passes the verification, perform corresponding transaction data processing according to the transaction message.

[0179] In some embodiments, when it is determined that the transaction message passes the verification, the above-mentioned corresponding transaction data processing according to the transaction message, when specifically implemented, may include: determining the first type of bill to be consumed and the second type of bill to be effective according to the transaction message; destroying the first type of bill saved in the smart contract; and saving the second type of bill in the smart contract.

[0180] In some embodiments, the verification processing may specifically further include at least one of the following: verifying the validity of the first bill signature, verifying the validity of the supporting document, verifying the validity of the transaction signature, etc.

[0181] In some embodiments, when specifically implemented, the transaction server may obtain and use relevant publicly available public keys (for example, supervision public key, transaction public key, etc.) to perform corresponding verification processing on the transaction message.

[0182] Based on the transaction data processing method provided in the embodiments of this specification, the transaction server can safely and reliably complete the corresponding transaction data processing on the premise of being supervised by the supervision server.

[0183] Refer to Figure 8 As shown, the embodiments of this specification also provide a transaction data processing method. Among them, this method is specifically applied to the first user terminal side. When specifically implemented, it may include the following content.

[0184] S801: Respond to the transaction data processing request, determine the first type of bill to be consumed; and create the second type of bill to be effective; wherein, the second type of bill at least includes a second temporary public key, a second bill public key, and ciphertext data;

[0185] S802: Generate transaction content based on the first type of bills and the second type of bills; and sign the transaction content using the transaction private key to obtain the corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request.

[0186] S803: Combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request.

[0187] S804: Send the transaction message to the transaction server; wherein, the transaction server is deployed with a smart contract.

[0188] In some embodiments, the second temporary public key and the second bill public key are key data that have nothing to do with the first user and are only corresponding to the second type of bills. The transaction private key is one-time key data that has nothing to do with the first user and is only corresponding to this transaction or the transaction data processing request. Correspondingly, the first user terminal can complete the specific transaction data processing by using the above-mentioned second temporary public key, second bill public key, and the transaction private key which are key data unrelated to the first user, thereby avoiding the leakage of the first user's user privacy during the transaction data processing due to the use of key data related to the first user such as the first payment private key, and thus can better protect the user privacy of the parties participating in the transaction.

[0189] Based on the transaction data processing method provided by the embodiments of this specification, the first user terminal can smoothly complete the transaction data processing without supervision and avoid the leakage of the user's privacy data.

[0190] The embodiments of this specification further provide a server, including a processor and a memory for storing instructions executable by the processor. When specifically implemented, the processor can execute the following steps according to the instructions: Respond to a transaction data processing request, determine the first type of bills to be consumed; and create the second type of bills to be effective; generate an authorization request for the first type of bills and send the authorization request to the supervision server; wherein, the authorization request carries at least the first type of bills and the first observation identifier of the first observation private key of the first user; the supervision server performs consistency verification on the first type of bills according to the preset verification rules and the first observation identifier, and feedbacks the first authorization certificate for the first type of bills in the case of determining that the consistency verification passes; generate transaction content based on the first authorization certificate, the first type of bills, and the second type of bills; and sign the transaction content using the transaction private key to obtain the corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request; combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; send the transaction message to the transaction server; wherein, the transaction server is deployed with a smart contract.

[0191] In order to more accurately complete the above instructions, refer to Figure 9 As shown, the embodiment of the present specification also provides another specific server. Wherein, the server includes a network communication port 901, a processor 902, and a memory 903. The above structures are connected by internal cables so that each structure can perform specific data interactions.

[0192] Wherein, the network communication port 901 can specifically be used to obtain a transaction data processing request.

[0193] The processor 902 can specifically be used to respond to a transaction data processing request, determine the first type of bill to be consumed; create the second type of bill to be effective; generate an authorization request for the first type of bill, and send the authorization request to the supervision server; wherein, the authorization request at least carries the first type of bill and the first observation identifier of the first observation key of the first user; the supervision server performs a consistency check on the first type of bill according to a preset verification rule and the first observation identifier, and feeds back the first authorization certificate for the first type of bill when it is determined that the consistency check passes; generate a transaction content according to the first authorization certificate, the first type of bill, and the second type of bill; and sign the transaction content with a transaction private key to obtain a corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request; combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; send the transaction message to the transaction server; wherein, the transaction server deploys a smart contract.

[0194] The memory 903 can specifically be used to store the corresponding instruction program.

[0195] In this embodiment, the network communication port 901 can be bound to different communication protocols, so as to send or receive different data virtual ports. For example, the network communication port can be a port responsible for web data communication, can also be a port responsible for FTP data communication, and can also be a port responsible for email data communication. In addition, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM, CDMA, etc.; it can also be a Wifi chip; it can also be a Bluetooth chip.

[0196] In this embodiment, the processor 902 may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc. This specification does not make any limitations.

[0197] In this embodiment, the memory 903 may include multiple levels. In a digital system, anything that can store binary data can be a memory; in an integrated circuit, a circuit with a storage function without a physical form is also called a memory, such as RAM, FIFO, etc.; in a system, a storage device with a physical form is also called a memory, such as a memory module, a TF card, etc.

[0198] This specification embodiment also provides a server, including a processor and a memory for storing instructions executable by the processor. When specifically implemented, the processor may execute the following steps according to the instructions: receive and obtain a first observation identifier and a first type of bill according to an authorization request for the first type of bill; perform a consistency check on the first type of bill according to a preset check rule and the first observation identifier; and generate and feedback a first authorization certificate when it is determined that the consistency check passes.

[0199] This specification embodiment also provides a server, including a processor and a memory for storing instructions executable by the processor. When specifically implemented, the processor may execute the following steps according to the instructions: obtain a transaction message; perform verification processing on the transaction message; where the verification processing at least includes: verifying the validity of a first authorization certificate; and performing corresponding transaction data processing according to the transaction message when it is determined that the transaction message verification passes.

[0200] This specification embodiment also provides a server, including a processor and a memory for storing instructions executable by the processor. When specifically implemented, the processor may execute the following steps according to the instructions: respond to a transaction data processing request, determine a first type of bill to be consumed; and create a second type of bill to be effective; where the second type of bill at least includes a second temporary public key, a second bill public key, and ciphertext data; generate a transaction content according to the first type of bill and the second type of bill; and sign the transaction content with a transaction private key to obtain a corresponding transaction signature; where the transaction private key is generated for the transaction data processing request; combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; and send the transaction message to a transaction server; where the transaction server deploys a smart contract.

[0201] An embodiment of this specification also provides a computer storage medium based on the above transaction data processing method. The computer storage medium stores computer program instructions, which when executed, implement: responding to a transaction data processing request, determining a first type of bill to be consumed; and creating a second type of bill to be effective; generating an authorization request for the first type of bill and sending the authorization request to a supervision server; wherein the authorization request carries at least the first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server performs a consistency check on the first type of bill according to a preset verification rule and the first observation identifier, and feeds back a first authorization certificate for the first type of bill when it is determined that the consistency check passes; generating a transaction content according to the first authorization certificate, the first type of bill, and the second type of bill; and signing the transaction content with a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request; combining the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; and sending the transaction message to a transaction server; wherein the transaction server deploys a smart contract.

[0202] An embodiment of this specification also provides a computer storage medium based on the above transaction data processing method. The computer storage medium stores computer program instructions, which when executed, implement: receiving and obtaining a first observation identifier and a first type of bill according to an authorization request for the first type of bill; performing a consistency check on the first type of bill according to a preset verification rule and the first observation identifier; and generating and feeding back a first authorization certificate when it is determined that the consistency check passes.

[0203] An embodiment of this specification also provides a computer storage medium based on the above transaction data processing method. The computer storage medium stores computer program instructions, which when executed, implement: obtaining a transaction message; performing verification processing on the transaction message; wherein the verification processing at least includes: verifying the validity of the first authorization certificate; and performing corresponding transaction data processing according to the transaction message when it is determined that the transaction message passes the verification.

[0204] The embodiments of this specification also provide a computer storage medium based on the above transaction data processing method. The computer storage medium stores computer program instructions, which when executed, implement the following: in response to a transaction data processing request, determine the first type of bill to be consumed; and create a second type of bill to be effective; where the second type of bill at least includes a second temporary public key, a second bill public key, and ciphertext data; generate a transaction content based on the first type of bill and the second type of bill; and sign the transaction content with a transaction private key to obtain a corresponding transaction signature; where the transaction private key is generated for the transaction data processing request; combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; and send the transaction message to a transaction server; where the transaction server is deployed with a smart contract.

[0205] In this embodiment, the above storage medium includes, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a cache, a hard disk drive (HDD), or a memory card. The memory can be used to store computer program instructions. The network communication unit can be set according to the standards specified by the communication protocol and is used as an interface for network connection communication.

[0206] In this embodiment, the functions and effects specifically implemented by the program instructions stored in the computer storage medium can be explained in comparison with other embodiments and will not be elaborated here.

[0207] Refer to Figure 10 As shown, at the software level, the embodiments of this specification also provide a transaction data processing device, which is applied to a first user terminal. The device specifically may include the following structural modules:

[0208] A first processing module 1001, which specifically can be used to respond to a transaction data processing request, determine the first type of bill to be consumed; and create a second type of bill to be effective;

[0209] A request module 1002, which specifically can be used to generate an authorization request for the first type of bill and send the authorization request to a supervision server; where the authorization request at least carries the first type of bill and a first observation identifier of the first observation secret key of the first user; the supervision server performs a consistency check on the first type of bill according to a preset verification rule and the first observation identifier, and feeds back a first authorization certificate for the first type of bill when it is determined that the consistency check passes.

[0210] The second processing module 1003 can be specifically used to generate a transaction content based on the first authorization voucher, the first type of bill, and the second type of bill; and sign the transaction content with a transaction private key to obtain a corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request.

[0211] The combination module 1004 can be specifically used to combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request.

[0212] The sending module 1005 can be specifically used to send the transaction message to a transaction server; wherein, the transaction server is deployed with a smart contract.

[0213] In some embodiments, when the above-mentioned first processing module 1001 is specifically implemented, the second type of bill to be validated can be created in the following manner: determine the resource value of the second type of bill according to the transaction data processing request; obtain the second observation public key and the second payment public key of the second user; generate a second temporary public key and a second bill public key for the second type of bill according to the second observation public key and the second payment public key of the second user; generate ciphertext data about the second type of bill according to the resource value of the second type of bill; and construct the second type of bill by using the second temporary public key, the second bill public key, and the ciphertext data.

[0214] In some embodiments, when the above-mentioned first processing module 1001 is specifically implemented, the second temporary public key and the second bill public key for the second type of bill can be generated in the following manner according to the second observation public key and the second payment public key of the second user: obtain a random number as the second temporary private key for the second type of bill; generate a corresponding second temporary public key according to the second temporary private key; construct intermediate data by using the second observation public key and the second temporary private key of the second user based on a preset construction rule; and construct the second bill public key according to the intermediate data and the second payment public key.

[0215] In some embodiments, when the above-mentioned second processing module 1003 is specifically implemented, the transaction content can be generated in the following manner according to the first authorization voucher, the first type of bill, and the second type of bill: construct a first bill private key for the first type of bill; sign the first type of bill with the first bill private key to obtain a corresponding first bill signature; generate in-band transmission ciphertext data about the second type of bill, and a proof file about the first type of bill and the second type of bill; and combine the first type of bill, the first bill signature, the first authorization voucher, the second type of bill, the in-band transmission ciphertext data, and the proof file to obtain the transaction content.

[0216] In some embodiments, when the second processing module 1003 is specifically implemented, the first private key for the first type of bill can be constructed in the following manner: obtain the first public key of the first type of bill; use the first public key of the first bill, as well as the first observation private key and the first payment private key of the first user, to construct the first private key of the first bill.

[0217] In some embodiments, when the second processing module 1003 is specifically implemented, the first private key of the first bill can be constructed in the following manner:

[0218]

[0219] Where p1 is the first private key of the first bill, R1 is the first public key of the first bill, a1 is the first observation private key of the first user, and b1 is the first payment private key of the first user.

[0220] In some embodiments, the proof document may specifically include a zero-knowledge proof document for proving that the resource value of the first type of bill is equal to the resource value of the second type of bill and that the resource value of the second type of bill meets the resource value range requirements.

[0221] In some embodiments, when the above device is specifically implemented, it can also be used to receive and respond to an initialization request, generate a first observation key and a first payment key; where the first observation key includes a first observation private key and a first observation public key; the first payment key includes a first payment public key and a first payment private key; and provide the first observation key to the supervision server.

[0222] In some embodiments, the first type of bill may specifically include a bill based on the UTXO model.

[0223] Refer to Figure 11 As shown, at the software level, an embodiment of this specification also provides another transaction data processing device, which is applied to a supervision server. This device may specifically include the following structural modules:

[0224] An acquisition module 1101, which can specifically be used to receive and obtain a first observation identifier and a first type of bill according to an authorization request regarding the first type of bill;

[0225] A verification module 1102, which can specifically be used to perform consistency verification on the first type of bill according to a preset verification rule and the first observation identifier;

[0226] A generation module 1103, which can specifically be used to generate and feedback a first authorization certificate when it is determined that the consistency verification passes.

[0227] Refer to Figure 12As shown, at the software level, the embodiments of this specification also provide another transaction data processing device, which is applied to a transaction server deployed with a smart contract. The device may specifically include the following structural modules:

[0228] The acquisition module 1201 may be used to obtain transaction messages;

[0229] The verification module 1202 may be specifically configured to verify the transaction message; wherein the verification process may include at least: verifying the validity of the first authorization credential;

[0230] The processing module 1203 may be specifically configured to perform corresponding transaction data processing according to the transaction message when it is determined that the transaction message has passed verification.

[0231] See Figure 13 As shown, at the software level, the embodiments of this specification also provide another transaction data processing device, which is applied to the first user terminal. The device may specifically include the following structural modules:

[0232] The first processing module 1301 may be specifically configured to respond to a transaction data processing request, determine a first type of bill to be consumed, and create a second type of bill to be validated; wherein the second type of bill includes at least a second temporary public key, a second bill public key, and encrypted data;

[0233] The second processing module 1302 may be specifically configured to generate transaction content based on the first and second type bills; and to sign the transaction content using a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated in response to the transaction data processing request;

[0234] The combining module 1303 may be specifically configured to combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request;

[0235] The sending module 1304 may be specifically configured to send the transaction message to a transaction server, wherein the transaction server may be deployed with a smart contract.

[0236] It should be noted that the units, devices, modules, etc. illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. For the convenience of description, when describing the above devices, various modules are described separately according to their functions. Of course, when implementing this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the modules implementing the same function can be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

[0237] As can be seen from the above, based on the transaction data processing device provided in the embodiments of this specification, while introducing supervision in the blockchain-based transaction system, it can effectively protect the user privacy of the users participating in the transaction and the resource value privacy related to the transaction, avoid the leakage of relevant privacy data, and better protect the data security in the transaction data processing process.

[0238] Although this specification provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative means. The step sequences listed in the embodiments are only one of the execution sequences of numerous steps and do not represent the only execution sequence. When the actual device or client product executes, it can be executed in the method sequence shown in the embodiments or the drawings or executed in parallel (for example, in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment). The term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, product or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, product or device. Without further limitation, it does not exclude the existence of additional identical or equivalent elements in the process, method, product or device including the said elements. The words such as first, second, etc. are used to represent names and do not represent any specific order.

[0239] Those skilled in the art also know that, in addition to implementing the controller in the form of pure computer-readable program code, the method steps can be logically programmed to enable the controller to implement the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

[0240] This specification can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc. that perform specific tasks or implement specific abstract data types. This specification can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0241] From the description of the above embodiments, those skilled in the art can clearly understand that this specification can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solutions of this specification can essentially be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions for causing a computer device (which can be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this specification.

[0242] The various embodiments in this specification are described in a progressive manner. For the same or similar parts between the various embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. This specification can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and so on.

[0243] Although this specification is depicted through embodiments, those of ordinary skill in the art know that this specification has many variations and changes without departing from the spirit of this specification, and it is hoped that the appended claims will cover these variations and changes without departing from the spirit of this specification.

Claims

1. A method for processing transaction data, characterized in that, Applied to the first user terminal, including: Respond to a transaction data processing request, determine the first type of bill to be consumed; and create a second type of bill to be effective; Generate an authorization request for the first type of bill and send the authorization request to the supervision server; wherein, the authorization request carries at least the first type of bill and the first observation identifier of the first observation secret key of the first user; the supervision server performs a consistency check on the first type of bill according to the preset verification rules and the first observation identifier, and feeds back the first authorization certificate for the first type of bill when it is determined that the consistency check passes; Generate a transaction content based on the first authorization certificate, the first type of bill, and the second type of bill; and sign the transaction content with the transaction private key to obtain the corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request; Combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; Send the transaction message to the transaction server; wherein, the transaction server is deployed with a smart contract; Among them, performing a consistency check on the first type of bill according to the preset verification rules and the first observation identifier includes: querying the second database according to the first observation identifier to obtain the first observation private key; obtaining the first bill public key and the first temporary public key of the first type of bill, and the first payment public key of the first user; constructing a verification public key using the first temporary public key, the first observation private key, and the first payment public key according to the preset verification rules; comparing the verification public key with the first bill public key to obtain the corresponding comparison result; determining whether the first type of bill passes the consistency check according to the comparison result; Among them, the method further includes: generating a first observation secret key and a first payment secret key through an initialization operation, the first observation secret key is used to be provided to the supervision server for processing transaction data instead of the corresponding first payment secret key; the first observation secret key includes a first observation public key and a first observation private key; the first payment secret key includes a first payment private key and a first payment public key; the second database is used to store the first observation secret key; the first bill public key is the public key corresponding to the first type of bill.

2. The method according to claim 1, wherein Creating a second type of bill to be effective includes: Determine the resource value of the second type of bill according to the transaction data processing request; Obtain the second observation public key and the second payment public key of the second user; Generate a second temporary public key and a second bill public key for the second type of bill according to the second observation public key and the second payment public key of the second user; Generate ciphertext data for the second type of bill according to the resource value of the second type of bill; Construct the second type of bill using the second temporary public key, the second bill public key, and the ciphertext data.

3. The method according to claim 2, wherein Generating a second temporary public key and a second bill public key for the second type of bill according to the second observation public key and the second payment public key of the second user includes: Obtain a random number as the second temporary private key for the second type of bill; and generate the corresponding second temporary public key according to the second temporary private key; Construct intermediate data using the second observation public key and the second temporary private key of the second user based on the preset construction rules; Construct the second bill public key based on the intermediate data and the second payment public key.

4. The method according to claim 2, characterized in that, Generate transaction content based on the first authorization voucher, the first type of bill, and the second type of bill, including: Construct the first bill private key for the first type of bill; Sign the first type of bill with the first bill private key to obtain the corresponding first bill signature; Generate in-band transmission ciphertext data for the second type of bill, and proof documents for the first type of bill and the second type of bill; Combine the first type of bill, the first bill signature, the first authorization voucher, the second type of bill, the in-band transmission ciphertext data, and the proof documents to obtain the transaction content.

5. The method according to claim 4, wherein Construct the first bill private key for the first type of bill, including: Obtain the first bill public key of the first type of bill; Construct the first bill private key by using the first bill public key, the first observation private key, and the first payment private key of the first user.

6. The method according to claim 5, characterized in that, Construct the first bill private key by using the first bill public key, the first observation private key, and the first payment private key of the first user, including: Construct the first bill private key in the following manner: Among them, is the first bill private key, is the first bill public key, is the first observation private key of the first user, is the first payment private key of the first user.

7. The method according to claim 4, wherein The proof document includes a zero-knowledge proof document for proving that the resource value of the first type of bill is equal to the resource value of the second type of bill, and the resource value of the second type of bill meets the resource value range requirements.

8. The method according to claim 1, characterized in that, The first type of bill includes a bill based on the UTXO model.

9. A transaction data processing method, characterized in that, Applied to a supervision server, including: Receive and obtain the first observation identifier and the first type of bill according to the authorization request for the first type of bill; wherein, the authorization request carries at least the first type of bill and the first observation identifier of the first observation secret key of the first user; Perform consistency verification on the first type of bill according to the preset verification rules and the first observation identifier; Generate and feedback the first authorization voucher when it is determined that the consistency verification passes; Among them, performing consistency verification on the first type of bill according to the preset verification rules and the first observation identifier includes: querying the second database according to the first observation identifier to obtain the first observation private key; obtaining the first bill public key and the first temporary public key for the first type of bill, and the first payment public key of the first user; constructing a verification public key by using the first temporary public key, the first observation private key, and the first payment public key according to the preset verification rules; comparing the verification public key and the first bill public key to obtain the corresponding comparison result; determining whether the first type of bill passes the consistency verification according to the comparison result; Among them, the first observation secret key is generated by the first user terminal through an initialization operation. The first user terminal also generates a first payment secret key through the initialization operation. The first observation secret key is used to be provided to the supervision server for processing transaction data instead of the corresponding first payment secret key; the first observation secret key includes a first observation public key and a first observation private key; the first payment secret key includes a first payment private key and a first payment public key; the second database is used to store the first observation secret key; the first bill public key is the public key corresponding to the first type of bill.

10. The method according to claim 9, wherein After generating and feedbacking the first authorization voucher, the method further includes: Save the first observation identifier and the first type of bill in the first database.

11. The method according to claim 9, wherein According to the preset verification rules, a verification public key is constructed by using the first temporary public key, the first observation private key, and the first payment public key, including: Construct the verification public key in the following manner: Among them, is the verification public key, is the first temporary public key, is the first observation private key, and G is the base point on the elliptic curve group, is the first payment public key.

12. The method according to claim 9, characterized in that, Before receiving and according to the authorization request for the first type of bill, the method further includes: Obtain the first observation secret key provided by the first user terminal; Save the first observation secret key in the second database.

13. The method according to claim 12, wherein The method further includes: Query the smart contract to determine the abnormal bill related to the abnormal transaction; According to the abnormal bill, determine the initiator and / or recipient of the abnormal bill by querying the first database and / or the second database.

14. A method for processing transaction data, characterized in that, Applied to the first user terminal, including: Respond to the transaction data processing request, determine the first type of bill to be consumed; and create the second type of bill to be effective; wherein, the second type of bill at least includes a second temporary public key, a second bill public key, and ciphertext data; Generate the transaction content according to the first type of bill and the second type of bill; and sign the transaction content with the transaction private key to obtain the corresponding transaction signature; wherein, the transaction private key is generated for the transaction data processing request; Combine the transaction content and the transaction signature to obtain the transaction message for the transaction data processing request; Send the transaction message to the transaction server; wherein, the transaction server deploys a smart contract; Among them, creating the second type of bill to be effective includes: determining the resource value of the second type of bill according to the transaction data processing request; obtaining the second observation public key and the second payment public key of the second user; generating the second temporary public key and the second bill public key for the second type of bill according to the second observation public key and the second payment public key of the second user; generating the ciphertext data for the second type of bill according to the resource value of the second type of bill; constructing the second type of bill by using the second temporary public key, the second bill public key, and the ciphertext data; Among them, generating the second temporary public key and the second bill public key for the second type of bill according to the second observation public key and the second payment public key of the second user includes: obtaining a random number as the second temporary private key for the second type of bill; and generating the corresponding second temporary public key according to the second temporary private key; constructing intermediate data by using the second observation public key and the second temporary private key of the second user based on the preset construction rules; constructing the second bill public key according to the intermediate data and the second payment public key.

15. A transaction data processing device, characterized in that, Applied to the first user terminal, including: The first processing module is used to respond to the transaction data processing request, determine the first type of bill to be consumed; and create the second type of bill to be effective; The request module is used to generate an authorization request for the first type of bill and send the authorization request to the supervision server; wherein, the authorization request at least carries the first type of bill and the first observation identifier of the first observation secret key of the first user; the supervision server performs consistency verification on the first type of bill according to the preset verification rules and the first observation identifier, and feedbacks the first authorization certificate for the first type of bill when it is determined that the consistency verification passes; A second processing module, configured to generate transaction content according to the first authorization certificate, the first type of bill, and the second type of bill; and sign the transaction content with a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request; A combination module, configured to combine the transaction content and the transaction signature to obtain a transaction message for the transaction data processing request; A sending module, configured to send the transaction message to a transaction server; wherein the transaction server is deployed with a smart contract; Among them, performing consistency verification on the first type of bill according to a preset verification rule and a first observation identifier includes: querying a second database according to the first observation identifier to obtain a first observation private key; obtaining a first bill public key, a first temporary public key for the first type of bill, and a first payment public key of a first user; constructing a verification public key by using the first temporary public key, the first observation private key, and the first payment public key according to the preset verification rule; comparing the verification public key with the first bill public key to obtain a corresponding comparison result; and determining whether the first type of bill passes the consistency verification according to the comparison result; Among them, the device is further configured to: generate a first observation secret key and a first payment secret key through an initialization operation, where the first observation secret key is provided to a supervision server for processing transaction data instead of the corresponding first payment secret key; the first observation secret key includes a first observation public key and a first observation private key; the first payment secret key includes a first payment private key and a first payment public key; the second database is used to store the first observation secret key; and the first bill public key is a public key corresponding to the first type of bill.

16. A transaction data processing device, characterized in that, Applied to a supervision server, including: An acquisition module, configured to receive and acquire a first observation identifier and a first type of bill according to an authorization request for the first type of bill; wherein the authorization request carries at least the first type of bill and the first observation identifier of the first observation secret key of a first user; A verification module, configured to perform consistency verification on the first type of bill according to a preset verification rule and a first observation identifier; A generation module, configured to generate and feedback a first authorization certificate when it is determined that the consistency verification passes; Among them, the verification module is specifically configured to: query a second database according to the first observation identifier to obtain a first observation private key; obtain a first bill public key, a first temporary public key for the first type of bill, and a first payment public key of a first user; construct a verification public key by using the first temporary public key, the first observation private key, and the first payment public key according to the preset verification rule; compare the verification public key with the first bill public key to obtain a corresponding comparison result; and determine whether the first type of bill passes the consistency verification according to the comparison result; Among them, the first observation key is generated by the first user terminal through an initialization operation. The first user terminal also generates a first payment key through the initialization operation. The first observation key is used to be provided to the supervision server for processing transaction data in place of the corresponding first payment key. The first observation key includes a first observation public key and a first observation private key. The first payment key includes a first payment private key and a first payment public key. The second database is used to store the first observation key. The first bill public key is the public key corresponding to the first type of bill.

17. A server, characterized in that, It includes a processor and a memory for storing instructions executable by the processor. When the processor executes the instructions, the steps of the method according to any one of claims 1 to 14 are implemented.

18. A computer-readable storage medium, characterized in that, Computer instructions are stored thereon. When the instructions are executed by the processor, the steps of the method according to any one of claims 1 to 14 are implemented.

Images