CN114742649A - Transaction data processing method and device and server - Google Patents

Transaction data processing method and device and server Download PDF

Info

Publication number
CN114742649A
CN114742649A CN202210267859.3A CN202210267859A CN114742649A CN 114742649 A CN114742649 A CN 114742649A CN 202210267859 A CN202210267859 A CN 202210267859A CN 114742649 A CN114742649 A CN 114742649A
Authority
CN
China
Prior art keywords
transaction
type
bill
public key
observation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210267859.3A
Other languages
Chinese (zh)
Inventor
夏伏彪
宋旭阳
谢翔
李升林
孙立林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Qianfang Technology Co ltd
Original Assignee
Shanghai Qianfang Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Qianfang Technology Co ltd filed Critical Shanghai Qianfang Technology Co ltd
Priority to CN202210267859.3A priority Critical patent/CN114742649A/en
Publication of CN114742649A publication Critical patent/CN114742649A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Abstract

The specification provides a transaction data processing method, a transaction data processing device and a transaction data processing server. Based on the method, after responding to the transaction data processing request, the first user terminal determines a first type of bill to be consumed and creates a second type of bill to be validated according to a corresponding rule, an authorization request about the first type of bill can be sent to the supervision server; the supervision server carries out consistency check on the first type of bills carried by the authorization request, and generates and feeds back an authorization voucher aiming at the first type of bills under the condition that the consistency check is passed; the first user terminal generates transaction content according to the first authorization voucher, the first type of bill and the second type of bill; the transaction private key generated aiming at the transaction data processing request is used for signing to obtain a transaction signature; then combining the transaction content and the transaction signature to obtain a transaction message; and sending the transaction message to a transaction server deployed with an intelligent contract to perform specific transaction data processing.

Description

Transaction data processing method and device and server
Technical Field
The specification belongs to the technical field of internet, and particularly relates to a transaction data processing method, a transaction data processing device and a transaction data processing server.
Background
The existing block chain transaction system often cannot support supervision and effectively protect related data privacy in a transaction data processing process.
No effective solution to the above problems has been proposed.
Disclosure of Invention
The specification provides a transaction data processing method, a transaction data processing device and a server, which can effectively protect the user privacy of users participating in transactions and the resource value data privacy related to the transactions while introducing supervision in a transaction system based on a block chain, avoid the leakage of related privacy data, and better protect the data security in the transaction data processing process.
An embodiment of the present specification provides a transaction data processing method, which is applied to a first user terminal, and includes: responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated; generating an authorization request about the first type of ticket and sending the authorization request to a supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed; generating transaction content according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request; sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
In one embodiment, creating a ticket of a second type to be validated comprises: determining a resource value of the second type of bill according to the transaction data processing request; acquiring 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 aiming at a second type of bill according to a second observation public key and a second payment public key of the second user; generating confidential state data about 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 secret data.
In one embodiment, generating a second temporary public key and a second ticket public key for a second type of ticket according to a second observation public key and a second payment public key of the second user includes: acquiring a random number as a second temporary private key for the second type of bill; generating a corresponding second temporary public key according to the second temporary private key; based on a preset construction rule, constructing intermediate data by using a second observation public key and a second temporary private key of a second user; and constructing the second bill public key according to the intermediate data and the second payment public key.
In one embodiment, generating transaction content according to the first authorization ticket, the first type of ticket and the second type of ticket comprises: constructing a first bill private key aiming at the first type of bills; signing the first type of bill by using a first bill private key to obtain a corresponding first bill signature; generating in-band transmission ciphertext data about the second type of ticket, and a certification document about the first type of ticket and the second type of ticket; and 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 certification file to obtain the transaction content.
In one embodiment, constructing a first ticket private key for a first type of ticket includes: acquiring a first bill public key of a first type of bill; and constructing and obtaining a first bill private key by using the first bill public key, a first observation private key and a first payment private key of the first user.
In one embodiment, the constructing the first ticket private key by using the first ticket public key and the first observation private key and the first payment private key of the first user comprises:
the first ticket private key is constructed as follows:
Figure BDA0003553106020000021
wherein p is1Is the first ticket private key, R1Is the public key of the first ticket, a1Is a first observation private key of a first user, b1A first private payment key for the first user.
In one embodiment, the certification file includes a zero knowledge certification file for certifying that the resource value of the first type of ticket is equal to the resource value of the second type of ticket, and that the resource value of the second type of ticket meets the requirement of the resource value range.
In one embodiment, the method further comprises: receiving and responding to an initialization request, and generating a first observation secret key and a first payment secret key; wherein the first observation key comprises a first observation private key and a first observation public key; the first payment secret key comprises a first public payment key and a first private payment key; providing the first observation key to an administration server.
In one embodiment, the first type of ticket comprises a ticket based on a UTXO model.
An embodiment of the present specification further provides a transaction data processing method, applied to a monitoring server, including: receiving and acquiring a first observation identifier and a first type of bill according to an authorization request about the first type of bill; according to a preset check rule and a first observation identifier, carrying out consistency check on the first type of bills; and generating and feeding back the first authorization certificate under the condition that the consistency check is determined to pass.
In one embodiment, after generating and feeding back the first authorization credential, the method further comprises: and storing the first observation identification and the first type of bill in a first database.
In one embodiment, the consistency check of the first type of ticket is performed according to a preset check rule and a first observation identifier, and the consistency check includes: inquiring a second database according to the first observation identifier to obtain a first observation private key; acquiring a first bill public key and a first temporary public key aiming at a first type of bill and a first payment public key of a first user; according to a preset verification rule, a first temporary public key, a first observation private key and a first payment public key are utilized to construct a verification public key; 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 check according to the comparison result.
In one embodiment, according to a preset verification rule, constructing a verification public key by using a first temporary public key, a first observation private key and a first payment public key, including:
the verification public key is constructed in the following way:
Figure BDA0003553106020000031
wherein, P'1For verifying public keys, R1Is a first temporary public key, a1Is a first observation private key, G is a base point on the elliptic curve group, B1The first public key is paid.
In one embodiment, prior to receiving and pursuant to the authorization request with respect to the first type of ticket, the method further comprises: acquiring a first observation secret key provided by a first user terminal; and saving the first observation key in a second database.
In one embodiment, the method further comprises: inquiring the intelligent contract and determining an abnormal bill related to the abnormal transaction; and according to the abnormal bill, determining an initiator and/or a receiver of the abnormal bill by querying the first database and/or the second database.
An embodiment of the present specification further provides a transaction data processing method, which is applied to a transaction server deployed with an intelligent contract, and includes: acquiring a transaction message; verifying the transaction message; wherein the verification process comprises at least: verifying the validity of the first authorization credential; and under the condition that the transaction message is confirmed to pass the verification, carrying out corresponding transaction data processing according to the transaction message.
In one embodiment, in a case that 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 validated according to the transaction message; destroying the first type of bills stored in the intelligent contract; and the second type of bill is stored in the intelligent contract.
In one embodiment, the verification process further comprises at least one of: verifying the validity of the first ticket signature, verifying the validity of the proof document, and verifying the validity of the transaction signature.
An embodiment of the present specification further provides a transaction data processing method, which is applied to a first user terminal, and includes: responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated; the second type bill at least comprises a second temporary public key, a second bill public key and secret data; generating transaction content according to the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request; sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
An embodiment of the present specification further provides a transaction data processing apparatus, which is applied to a first user terminal, and includes: the first processing module is used for responding to the transaction data processing request and determining a first type of bill to be consumed; creating a second type of ticket to be validated; the second processing module is used for generating an authorization request about the first type of bill and sending the authorization request to the supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed; the third processing module is used for generating transaction contents according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request; the combination module is used for combining the transaction content and the transaction signature to obtain a transaction message aiming at the transaction data processing request; the sending module is used for sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
An embodiment of the present specification further provides a transaction data processing apparatus, which is applied to a monitoring server, and includes: the acquisition module is used for receiving and acquiring a first observation identifier and a first type of bill according to an authorization request about the first type of bill; the checking module is used for carrying out consistency checking on the first type of bills according to a preset checking rule and the first observation identifier; and the generating module is used for generating and feeding back the first authorization certificate under the condition that the consistency check is determined to pass.
An embodiment of the present specification further provides a transaction data processing apparatus, which is applied to a transaction server deployed with an intelligent contract, and includes: the acquisition module is used for acquiring a transaction message; the verification module is used for verifying the transaction message; wherein the verification process comprises at least: verifying the validity of the first authorization credential; and the processing module is used for carrying out corresponding transaction data processing according to the transaction message under the condition of determining that the transaction message passes the verification.
Embodiments of the present specification also provide a server comprising a processor and a memory for storing processor-executable instructions, the processor implementing the steps of the transaction data processing method when executing the instructions.
The present specification also provides a computer readable storage medium, on which computer instructions are stored, the instructions implementing the steps of the transaction data processing method when executed by a processor.
Based on the transaction data processing method, the transaction data processing device and the server provided by the specification, when a first user holding a first user terminal needs to perform account transfer transaction to a second user terminal held by a second user, the first user terminal can receive and respond to a transaction data processing request initiated by the first user, determine a first type of bill to be consumed, and create a second type of bill to be validated according to a corresponding rule; then, the first user terminal may first send the generated authorization request for the first type of ticket to the monitoring server; the authorization request at least carries a first observation identifier of an observation secret key of a first user and a first type of bill; the supervision server carries out consistency verification on the first type of bills carried by the authorization request according to a preset verification rule and a first observation identifier so as to verify and record the user information of the first user; under the condition that the consistency check is determined to pass, the supervision server generates and feeds back an authorization voucher aiming at the first type of bill; furthermore, the first user terminal can generate transaction content according to the first authorization voucher, the first type of bill and the second type of bill; the transaction private key generated aiming at the transaction data processing request is used for signing the transaction content to obtain a corresponding transaction signature; then combining the transaction content and the transaction signature to generate a transaction message; sending the transaction message to a transaction server with an intelligent contract for processing; the transaction server can firstly verify the transaction message; and under the condition that the verification is determined to be passed, performing specific transaction data processing according to the transaction message, for example, destroying the first type of bill stored in the intelligent contract, and/or storing the second type of bill into the intelligent contract, and the like. Therefore, when supervision is introduced into the transaction system based on the block chain, the user privacy of users participating in transaction and the data privacy of resource values related to the transaction are effectively protected, the privacy data related to the transaction are prevented from being leaked, and the data security of the transaction data processing process can be well protected.
Drawings
In order to more clearly illustrate the embodiments of the present specification, the drawings needed to be used in the embodiments will be briefly described below, and the drawings in the following description are only some of the embodiments described in the specification, and it is obvious to those skilled in the art that other drawings can be obtained based on the drawings without any inventive work.
FIG. 1 is a schematic flow diagram of a transaction data processing method provided by one embodiment of the present description;
FIG. 2 is a schematic diagram illustrating an embodiment of a transaction data processing method as provided by an embodiment of the present specification, in one example scenario;
FIG. 3 is a schematic diagram illustrating an embodiment of a transaction data processing method according to an embodiment of the present disclosure;
FIG. 4 is a schematic diagram illustrating an embodiment of a transaction data processing method according to an embodiment of the present disclosure;
FIG. 5 is a schematic diagram illustrating an embodiment of a transaction data processing method according to an embodiment of the present disclosure;
FIG. 6 is a flow diagram of a transaction data processing method provided by one embodiment of the present description;
FIG. 7 is a flow diagram of a transaction data processing method provided by one embodiment of the present description;
FIG. 8 is a flow diagram of a transaction data processing method provided by one embodiment of the present description;
FIG. 9 is a schematic structural component diagram of a server provided in an embodiment of the present description;
fig. 10 is a schematic structural component diagram of a transaction data processing device provided in an embodiment of the present specification;
fig. 11 is a schematic structural component diagram of a transaction data processing device provided in an embodiment of the present specification;
fig. 12 is a schematic structural component diagram of a transaction data processing device provided in an embodiment of the present specification;
fig. 13 is a schematic structural component diagram of a transaction data processing device according to an embodiment of the present specification.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.
Referring to fig. 1, an embodiment of the present disclosure provides a transaction data processing method, where the method is specifically applied to a first user terminal side. In particular implementations, the method may include the following.
S101: responding to a transaction data processing request, and determining a first type of bill to be consumed; creating a second type of ticket to be validated;
s102: generating an authorization request about the first type of ticket and sending the authorization request to a supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed;
s103: generating transaction content according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request;
s104: combining the transaction content and the transaction signature to obtain a transaction message aiming at the transaction data processing request;
s105: sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
In some embodiments, the first user terminal may specifically be a terminal device held by the first user. As can be seen in fig. 2. The first user may be understood as an initiator or a payer.
The current first user wants to transfer resource data of a corresponding resource value to a second user; it is also desirable to securely complete transaction data processing for transfers with supervision and without revealing relevant private data.
Accordingly, the second user may be understood as a receiving party or a receiving party. The second user may specifically hold a second user terminal.
In some embodiments, the first user terminal and the second user terminal may specifically include a client deployed at the first user side and the second user side and capable of implementing functions such as data acquisition and data transmission. Specifically, the first user terminal and the second user terminal may be, for example, electronic devices such as a desktop computer, a tablet computer, a notebook computer, and a smart phone. Alternatively, the first user terminal and the second user terminal may be software applications that can be run in the electronic device. For example, it may be some transaction APP running on a smartphone, etc.
In some embodiments, referring to fig. 2, in the blockchain-based transaction system to which the transaction data processing method provided by the present description is applied, a supervision server and a transaction server are further included.
The supervision server may be specifically understood as a server deployed on the side of the supervisor. The monitoring party is particularly responsible for monitoring and auditing related transaction data on the blockchain so as to protect the safety and compliance of the transaction data on the chain.
The transaction server is specifically understood to be a node server on the block chain which is responsible for specific transaction data processing. The transaction server is deployed with corresponding intelligent contracts. The Smart Contract (Smart Contract) described above is understood in particular as a computer protocol with non-tamper-able properties intended to propagate, verify or execute in an informative manner a Contract for a certain specific data processing. Based on the intelligent contract, trusted transaction data processing may be allowed without third party, decentralized processing.
In this embodiment, the monitoring server and the transaction server may specifically include a background server capable of implementing functions such as data transmission and data processing. Specifically, the supervision server and the transaction server may be, for example, an electronic device having data operation, storage function and network interaction function. Alternatively, the supervision server and the transaction server may also be software programs running in the electronic device and providing support for data processing, storage and network interaction. In this embodiment, the number of servers included in the supervision server and the transaction server is not particularly limited. The supervision server and the transaction server may be specifically one server, or several servers, or a server cluster formed by a plurality of servers.
In some embodiments, before the implementation, the first user terminal and the second user terminal may perform initialization data processing. Specifically, the method may further include the following: receiving and responding to an initialization request, and generating a first observation secret key and a first payment secret key; wherein the first observation key comprises a first observation private key and a first observation public key; the first payment secret key comprises a first public payment key and a first private payment key; providing the first observation key to an administration server.
In some embodiments, the providing of the first observation key to the supervising server may be implemented as follows: generating a registration request; wherein the registration request comprises a first observation key; and sending the registration request to a supervision server.
In some embodiments, before the implementation, the first user may use the first user terminal to perform an initialization operation to initiate the initialization request. Accordingly, the first user terminal may receive and respond to the initialization request to generate a first observation key and a first payment key.
The first observation key and the first payment key correspond to a first user (or an account of the first user).
It should be noted that, based on the existing method, the transaction data is often processed directly by using the first payment key. However, since the first payment key corresponds to the first user, other data parties can easily obtain and track the related information of the first user of the initiator of the transaction according to the first payment key used by the first user when processing transaction data, thereby causing the user privacy of the first user to be revealed. The transaction data processing method provided in the embodiment of the present specification can effectively avoid disclosure of user privacy because the first payment key is not directly used for processing the transaction data, and will be described in detail later. Furthermore, based on the existing method, the first user does not generate and use the observation key either.
Specifically, for example, the first user terminal may generate the random number a first1As a first private view key (private viewing key); then, the first observation private key is utilized according to the following formula to generate a corresponding first observation public key (public viewing key) A1：A1＝a1G, where G is a base point on the elliptic curve group, and a first observation key (or first observation key pair) is obtained: (a)1，A1). The first user terminal may also generate a first observation identifier (viewing key ID) corresponding to the first observation key, while generating the first observation private key and the first observation public key.
Similarly, the first user terminal may generate the random number b first1As a first private payment key; then, the first payment private key is utilized according to the following formula to generate a corresponding first payment public key B1：B1＝b1G, where G is a base point on the elliptic curve group, obtaining a first payment key: (b)1，B1)。
The first user terminal may disclose the first observation public key and the first payment public key to the outside, but not the held first observation private key and the first payment private key.
Further, the first user terminal may provide the first observation key to the monitoring server. The first observation key provided to the monitoring server may further include a first observation identifier corresponding to the first observation key.
Specifically, when registering with the monitoring server, the first user terminal may provide the first observation key to the monitoring server by, for example, sending an email or sending a registration request, thereby completing the initialized data processing.
Accordingly, the supervision server receives the first observation key and saves the first observation key in the second database.
Similarly, the second user terminal may generate a second observation key (a) in response to the initialization request2，A2) A second payment key (b)2，B2) (ii) a Then externally disclosing second observation public key A2And a second public payment key B2And providing the second observation key to the supervision server to complete the initialized data processing. Accordingly, the administrative server receives the second observation key and saves the second observation key in the second database.
In some embodiments, when the first user needs to initiate a transfer to the second user, for example, the first user terminal may perform a corresponding operation to initiate a transaction data processing request regarding the transfer. Accordingly, the first user terminal may generate and obtain the transaction data processing request.
In some embodiments, the first type of ticket may be specifically understood as a ticket (which may also be referred to as an input ticket) currently held by the first user to be consumed. The second type of ticket may be understood as a ticket to be validated (also referred to as an output ticket) that is currently transferred to a second user.
In some embodiments, the first type of ticket may specifically include a ticket based on a UTXO model, or the like. Correspondingly, the second type of ticket specifically may also include a ticket based on the UTXO model, and the like.
The UTXO (unused Transaction output) model may be specifically understood as a Transaction record model in a blockchain network, which is different from an account model used in a conventional method.
Based on the UTXO model, each transaction costs the outcome of a previous transaction (e.g., an existing bill, ticket, etc.) and generates a new outcome that may be consumed in the future by the transaction, and all unconsumed outcomes are separately maintained in a plurality of different nodes (e.g., sub-accounts, etc.) 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 may record the resource data held by the user by accumulating the outcomes saved in the associated nodes. Meanwhile, specific transactions can be carried out by using the output stored in the associated node, and the output stored in each node can be used only once.
Specifically, as shown in fig. 3, each Transaction (Transaction) consumes the UTXO (input ticket) generated by the previous Transaction and then generates a new UTXO (output ticket); the balance of the account is the unconsumed UTXO set belonging to the address; while the transaction may be understood as a change to the UTXO set, the concept of the corresponding account and balance may be an abstraction over the UTXO set. For example, referring to FIG. 3, the inputs for Transaction 3(Transaction3) are the two outputs (UTXO) for Transaction 1(Transaction1) and Transaction 2(Transaction 2).
It should be noted that the above listed tickets based on the UTXO model are only an illustrative example. In specific implementation, the first type of ticket and the second type of ticket may also include other types of tickets according to specific application scenarios and transaction requirements. The present specification is not limited to these.
In some embodiments, after obtaining the transaction data processing request, the first user terminal may first determine, by performing parsing processing in response to the transaction data processing request, a resource value of resource data to be transferred by the first user to the second user.
The first user terminal can search the valid tickets currently held by the first user according to the resource values, and find out one or more tickets with the sum of the resource values equal to the resource value from the valid tickets as the first type tickets to be consumed. Meanwhile, one or more second-type tickets to be validated can be created according to the corresponding protocol rules.
And the sum of the resource values corresponding to the first type of bill is equal to the sum of the resource values corresponding to the second type of bill. And the resource value corresponding to each first type bill and the resource value corresponding to each second type bill should accord with the value that the resource value is greater than 0.
Specifically, for example, referring to fig. 4, the resource data may be token data, and the resource value determined based on the transaction data processing request may be 4 BTC. The first user terminal finds two bills through searching, wherein the two bills are respectively: the bill 1 corresponding to the resource value of 2BTC and the bill 2 corresponding to the resource value of 3BTC are two first-type bills. Further, the first user terminal may newly create two tickets according to the corresponding protocol rules: the bill 3 corresponding to the resource value of 4BTC and the bill 4 corresponding to the resource value of 1BTC are taken as two second-type bills. Note 1 and note 2 may be referred to as a first type of note to be consumed (or referred to as input note), and note 3 and note 4 may be referred to as a second type of note to be validated (or referred to as output note).
It should be noted that the above listed token data is only an exemplary illustration. The resource data may also include other types of data, such as operation resource data, information resource data, and the like, according to a specific application scenario and a processing requirement.
In some embodiments, the creating of the second type of ticket to be validated may include the following steps:
s1: determining a resource value of the second type of bill according to the transaction data processing request;
s2: acquiring a second observation public key and a second payment public key of a second user;
s3: generating a second temporary public key and a second bill public key aiming at a second type of bill according to a second observation public key and a second payment public key of the second user;
s4: generating confidential data about the second type of bill according to the resource value of the second type of bill;
s5: and constructing the second type of bill by using the second temporary public key, the second bill public key and the secret data.
The 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. Therefore, the user information of the participant can not be revealed when the second temporary public key and the second bill public key are subsequently used, and the user privacy of the participant can be better protected.
In some embodiments, the first user terminal may obtain, by querying on the blockchain, a second observation public key and a second payment public key that are externally published by the second user terminal according to identification information (e.g., a user name of the second user, a second observation identifier, and the like) related to the second user.
In some embodiments, in order to better protect data privacy of the participating parties, in particular, the first user terminal may generate a second temporary public key and a second ticket public key for the second type of ticket by using the second observation public key and the second payment public key of the second user based on a covert address algorithm.
In some embodiments, in a specific implementation, the first user terminal may further generate a second temporary public key and a second ticket public key for the second type of ticket according to the second observation public key and the second payment public key of the second user as follows:
s1: acquiring a random number as a second temporary private key for the second type of bill; generating a corresponding second temporary public key according to the second temporary private key;
s2: constructing intermediate data by using a second observation public key and a second temporary private key of a second user based on a preset construction rule;
s3: and constructing the second bill public key according to the intermediate data and the second payment public key.
In some embodiments, for example, the first user terminal may first derive the parametersCollection ZpA random number r is randomly extracted as a second temporary private key corresponding to a second type of ticket. Wherein r is2∈Zp. Then, the first user terminal may generate a corresponding second temporary public key R using the second temporary private key according to the following equation2：R2＝r2G. Wherein G is a base point on the elliptic curve group.
Then, the first user terminal may construct the intermediate data c according to a preset construction rule by using the second observation public key and the second temporary private key according to the following equation2：
Figure BDA0003553106020000111
Wherein H represents a hash operation, A2Is a second observation public key, r2Is the second temporary public key corresponding to the second type of ticket.
Finally, the first user terminal can use the second temporary public key and the second payment public key to construct and obtain a corresponding second bill public key P according to the following formula2：P2＝B2+c2G. Wherein, B2Is the second public payment key.
In some embodiments, each secret data corresponds to a second type of ticket, and the resource values of all corresponding second type of tickets are hidden. The generating of the confidential data about the second type of ticket according to the resource value of the second type of ticket may include: and generating confidential data about the second type of bill according to the corresponding resource value of the second type of bill by adopting a cryptography commitment algorithm (commit) or an encryption algorithm (encryption).
In some embodiments, referring to fig. 5, the second temporary public key, the second ticket public key, and the secret data may be combined to construct a corresponding second type ticket. Further, the second type of ticket may further include a ticket identifier of the second type of ticket. Accordingly, the second type of ticket can be represented in the form: [ note identifier, secret data, second temporary public key, second note public key of note of second type ]. The above note identifier may be specifically understood as identification information that is not related to a participant and can be in one-to-one correspondence with a note, for example, a serial number of a note, a note number, and the like.
The first type bill and the second type bill have the same form structure, and can be expressed as follows: note identification, secret data, first temporary public key, first note public key of note of first type.
In some embodiments, unlike the existing method, the first user terminal further needs to apply an authorization credential for the first type of ticket (i.e. an authorization credential for using the first type of ticket) to the administrative server before generating the transaction message using the first type of ticket to be consumed. According to the corresponding protocol rule, the first user terminal can normally use the first type of bill to generate a corresponding transaction message under the condition of obtaining the authorization certificate generated by the supervision server.
In some embodiments, when embodied, the first user terminal may generate an authorization request for a first type of ticket to be consumed; the authorization request at least carries a first observation identifier of a first user and a first type of bill.
Further, when the first user terminal needs to use a plurality of first-type tickets, the first user terminal can also apply for the plurality of first-type tickets in batches, and correspondingly, the authorization request sent to the supervision server can carry the plurality of first-type tickets at one time.
In some embodiments, the monitoring server may first receive and obtain the first observation identifier and the first type of ticket according to the authorization request; then, according to a preset check rule and a first observation identifier, carrying out consistency check on the first type of bills; and under the condition that the consistency check is determined to pass, generating and feeding back the first authorization certificate to the first user terminal. Wherein a first authorization ticket corresponds to a first type of ticket.
In some embodiments, after the first authorization credential is generated and fed back after the consistency check is passed, the monitoring server may further store the first observation identifier and the first type of ticket in a first database, so as to perform a backtracking query in a subsequent abnormal transaction processing. The first database may specifically store a corresponding relationship between the first observation identifier and the first type of ticket.
In some embodiments, the performing consistency check on the first type of ticket according to the preset check rule and the first observation identifier may include the following steps:
s1: inquiring a second database according to the first observation identifier to obtain a first observation private key;
s2: acquiring a first bill public key and a first temporary public key aiming at a first type of bill and a first payment public key of a first user;
s3: according to a preset verification rule, a first temporary public key, a first observation private key and a first payment public key are utilized to construct a verification public key;
s4: comparing the verification public key with the first bill public key to obtain a corresponding comparison result;
s5: and determining whether the first type of bill passes the consistency check according to the comparison result.
In some embodiments, in implementation, the monitoring server may find the first observation key matching the first observation identifier by querying the second database, and obtain the first observation private key a from the first observation key1。
In some embodiments, the monitoring server may obtain the first ticket public key P corresponding to the first type ticket by parsing the first type ticket1And a first temporary public key R1(ii) a Meanwhile, a first payment public key B corresponding to the first user is obtained through inquiry1。
In some embodiments, according to a preset verification rule, the verification public key is constructed by using the first temporary public key, the first observation private key, and the first payment public key, and in specific implementation, the following contents may be included:
the verification public key is constructed in the following way:
Figure BDA0003553106020000121
wherein, P'1For verificationPublic key, R1Is a first temporary public key, a1Is a first observation private key, G is a base point on the elliptic curve group, B1The first public key is paid.
In some embodiments, the supervisory server may verify the public key P'1With the first note public key P1Comparing to obtain a corresponding comparison result; according to the comparison result, under the condition that the verification public key is the same as the first bill public key, the first bill consistency verification can be determined to pass, the first bill is determined to be a credible bill generated according to the corresponding protocol rule, meanwhile, the first user using the first bill can be determined, and then the first authorization certificate corresponding to the first bill can be generated and fed back to the first user terminal.
Specifically, the supervision server may sign the first type of ticket with a held supervision private key to obtain a corresponding first authorization credential.
On the contrary, when the verification public key and the first bill public key are determined to be different, the first bill consistency verification can be determined not to pass, and then the first authorization voucher aiming at the first bill can not be generated. Further, the supervision server can also generate and feed back an error prompt about the first type of bill to the first user terminal, so that the first user terminal can reselect the first type of bill which meets the requirement.
In some embodiments, the first user terminal may generate the transaction content of the transaction message by using the first authorization ticket, the first type of ticket and the second type of ticket after receiving the first authorization ticket about the first type of ticket; meanwhile, a one-time transaction key aiming at the transaction (or the transaction data processing request) can be generated; the transaction secret key can be further used for signing the transaction content to obtain a corresponding transaction signature; and then combining the transaction signature and the transaction content to obtain a corresponding transaction message.
It should be noted that the transaction key is key data corresponding to the transaction (or the transaction data processing request), and other data parties cannot track the first user based on the transaction key. In this embodiment, the first user uses the transaction key to perform signature instead of the first payment key corresponding to the first user, so that the user information of the first user can be better hidden, and the user data privacy of the first user can be effectively protected.
In some embodiments, the generating of the transaction content according to the first authorization ticket, the first type of ticket, and the second type of ticket may include the following steps:
s1: constructing a first bill private key for a first type of bill;
s2: signing the first type of bill by using a first bill private key to obtain a corresponding first bill signature;
s3: generating in-band transmission ciphertext data about the second type of ticket, and a certification document about the first type of ticket and the second type of ticket;
s4: and 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 certification file to obtain the transaction content.
In some embodiments, constructing the first ticket private key for the first type of ticket may include the following: acquiring a first bill public key of a first type of bill; and constructing and obtaining a first bill private key by using the first bill public key, a first observation private key and a first payment private key of the first user.
In some embodiments, similar to the second type of ticket, the second type of ticket is generated according to the same preset construction rule, and the first type of ticket also includes information such as a first ticket public key and a first temporary public key corresponding to the first type of ticket. Correspondingly, the first user terminal can obtain the first bill public key by analyzing the first type of bill.
In some embodiments, in a specific implementation, the first ticket private key may be constructed and obtained by using the first ticket public key, and the first observation private key and the first payment private key of the first user, based on a relevant characteristic of a preset construction rule, in the following manner:
Figure BDA0003553106020000131
wherein p is1Is the first ticket private key, R1Is the first ticket public key, a1A first observation private key for a first user, b1A first private payment key for the first user.
It should be noted that, because 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 second type of bill through account transfer, the second user can obtain and utilize the second bill public key, the second observation private key and the second payment private key of the second user in a similar manner to construct and obtain the second bill private key for the second type of bill; and then the second type of bill obtained through the transfer is used by using a second bill private key to sign the second type of bill.
In some embodiments, the proof file includes a zero knowledge proof file for proving that the resource value of the first type of ticket is equal to the resource value of the second type of ticket, and that the resource value of the second type of ticket meets the requirement of the resource value range. The resource value range requirement may specifically include: the resource value is greater than or equal to 0 and does not exceed the sum of the resource values corresponding to the bills held by the first user.
In some embodiments, the zero knowledge proof file may be generated according to a zero knowledge proof algorithm.
In some embodiments, in implementation, the resource value of the second type of ticket may be encrypted by using a second observation public key of a second user, so as to obtain the in-band transmission ciphertext data corresponding to the second type of ticket. Correspondingly, after receiving the transaction message, the second user terminal may decrypt the in-band transmission ciphertext data by using the held second observation private key to obtain a resource value corresponding to the second type of ticket, so as to verify the resource data of the account transfer initiated by the first user.
In some embodiments, the first type of ticket, the first ticket signature, the first authorization ticket, the second type of ticket, the in-band transmission ciphertext data, and the certification document may be combined to obtain the corresponding transaction content, which may be represented as follows: first type bill, first bill signature, first authorization certificate, second type bill, in-band transmission ciphertext data and certificate document.
Further, for a request involving a plurality (e.g., m) of first-type instruments and a plurality (e.g., n) of second-type instruments in a transaction, the transaction contents may be expressed in the form of: [ m is the first type of bill, m is the first bill signature, m is the first authorization voucher, n is the second type of bill, n is the intraband transmission ciphertext data, certificate document ].
In some embodiments, after obtaining the transaction message, the transaction message may be uploaded to a blockchain to which an intelligent contract is deployed for persistent processing.
In particular, and with reference to FIG. 2, the first user terminal may send the transaction to a transaction server deployed with the smart contract. Correspondingly, the transaction server receives and acquires the transaction message.
The transaction server can firstly verify the transaction message according to the corresponding protocol rule; and under the condition that the transaction message passes the verification, carrying out specific transaction data processing according to the transaction content in the transaction message.
In some embodiments, the verification process includes at least: verifying the validity of the first authorization ticket. Specifically, the transaction server may obtain a public supervision key externally disclosed by the supervision server, and verify the validity of the first authorization credential by using the public supervision key.
In some embodiments, the verification process may further include one or more of the following: verifying the validity of the first ticket signature, verifying the validity of the proof document, verifying the validity of the transaction signature, etc.
It should be noted that the above listed verification process is only an exemplary one. In specific implementation, other related verification processes can be introduced according to specific situations and security requirements.
In some embodiments, the transaction server determines that the transaction message is validated upon determining that all validation processes are validated.
In some embodiments, in the case that it is determined that the transaction packet is verified, the corresponding transaction data processing is performed according to the transaction packet, and the specific implementation may include the following contents: determining a first type of bill to be consumed and a second type of bill to be validated according to the transaction message; destroying the first type of bills stored in the intelligent contract; and storing the second type of bill in the intelligent contract, thereby completing corresponding transaction data processing. Correspondingly, the second user terminal can acquire and use the second type of ticket through the intelligent contract.
As can be seen from the above, according to the transaction data processing method provided in the embodiments of the present specification, when a first user holding a first user terminal needs to transfer money to a second user, the first user terminal may receive and respond to a transaction data processing request initiated by the first user to determine a first type of ticket to be consumed, and create a second type of ticket to be validated according to a corresponding rule; then, the first user terminal may first send the generated authorization request for the first type of ticket to the monitoring server; the authorization request at least carries a first observation identifier of an observation secret key of a first user and a first type of bill; the supervision server carries out consistency verification on the first type of bills carried by the authorization request according to a preset verification rule and a first observation identifier so as to verify the identity of the first user and record the identity of the first user; under the condition that the consistency check is determined to pass, the supervision server generates and feeds back an authorization voucher aiming at the first type of bill; furthermore, the first user terminal can generate transaction content according to the first authorization voucher, the first type of bill and the second type of bill; the transaction private key aiming at the transaction data processing request is used for signing the transaction content to obtain a corresponding transaction signature; then combining the transaction content and the transaction signature to generate a transaction message; sending the transaction message to a transaction server with an intelligent contract for processing; the transaction server can firstly verify the transaction message; and under the condition that the verification is determined to be passed, performing specific transaction data processing according to the transaction message, for example, destroying the first type of bill stored in the intelligent contract, storing the second type of bill in the intelligent contract, and the like. Therefore, while supervision is introduced into the transaction system based on the block chain, the user privacy of users participating in transaction and the privacy of resource values related to transaction are effectively protected, related privacy data are prevented from being revealed, and data safety in the transaction data processing process is well protected.
Referring to fig. 6, an embodiment of the present disclosure further provides a transaction data processing method. The method is specifically applied to the side of the monitoring server, and when the method is specifically implemented, the following contents can be included.
S601: receiving and acquiring a first observation identifier and a first type of bill according to an authorization request about the first type of bill;
s602: according to a preset check rule and a first observation identifier, carrying out consistency check on the first type of bills;
s603: and generating and feeding back the first authorization certificate under the condition that the consistency check is determined to pass.
In some embodiments, after generating and feeding back the first authorization ticket, when the method is implemented, the following may be further included: and storing the first observation identification and the first type of bill in a first database.
In some embodiments, the correspondence between the first observation identifier and the first type of ticket may be recorded in the first database.
In some embodiments, the performing consistency check on the first type of ticket according to the preset check rule and the first observation identifier may include the following steps: querying a second database according to the first observation identifier to obtain a first observation private key; acquiring a first bill public key and a first temporary public key aiming at a first type of bill and a first payment public key of a first user; according to a preset verification rule, a first temporary public key, a first observation private key and a first payment public key are utilized to construct a verification public key; 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 check according to the comparison result.
In some embodiments, the constructing a verification public key according to a preset verification rule by using the first temporary public key, the first observation private key, and the first payment public key may include:
the verification public key is constructed in the following way:
Figure BDA0003553106020000161
wherein, P1' as a check public key, R1Is a first temporary public key, a1Is a first observation private key, G is a base point on the elliptic curve group, B1The first public key is paid.
In some embodiments, the monitoring server may specifically use the held monitoring private key to sign the first type of ticket that passes the consistency check, and obtain a first authorized signature corresponding to the first type of ticket. Wherein, the supervision public key corresponding to the supervision private key can be provided to the transaction server or be disclosed to the outside.
In some embodiments, before receiving and according to the authorization request for the first type ticket, the method, when embodied, may further include: acquiring a first observation secret key provided by a first user terminal; and saving the first observation key in a second database.
Specifically, the monitoring server may receive a registration request sent by the user terminal during registration; and analyzing the registration request, acquiring an observation secret key, and storing the observation secret key in a second database.
In some embodiments, the registration request may also specifically carry a user identifier of the user (e.g., user information such as a user name and a user number of the user); the observation key may further include an observation identifier corresponding to the observation key.
Correspondingly, the supervision server can also establish the corresponding relation between the user identification and the observation identification; and recording the corresponding relation between the user identification and the observation identification in a second database.
In some embodiments, the method further comprises: inquiring the intelligent contract and determining abnormal bills related to abnormal transactions; and according to the abnormal bill, determining an initiator and/or a receiver of the abnormal bill by querying the first database and/or the second database.
In some embodiments, when an abnormal transaction is found, the monitoring server may first obtain an abnormal transaction message related to the abnormal transaction by querying an intelligent contract; then, abnormal bills (including abnormal first bills and/or abnormal second bills) related to the abnormal transactions are determined by analyzing the abnormal transaction message; further, the initiator and/or the receiver of the abnormal bill can be determined as the abnormal user by querying the related data (including the corresponding relation between the data) stored in the first database and/or the second database. Furthermore, an abnormal risk label can be set for the abnormal user; and the users with the set abnormal risk labels are monitored and tracked in a targeted manner, so that the supervision of transaction data on the chain is realized, and the transaction data processing safety on the transaction system based on the block chain is maintained.
In addition, the supervision server can audit and verify the transaction data on the chain by utilizing the data recorded by the first database and/or the second database.
Based on the transaction data processing method provided by the embodiment of the specification, the supervision server can effectively supervise the transaction data on the transaction system based on the block chain so as to protect the security of the transaction data.
Referring to fig. 7, an embodiment of the present disclosure further provides a transaction data processing method. The method is specifically applied to the transaction server side, and when the method is specifically implemented, the following contents can be included.
S701: acquiring a transaction message;
s702: verifying the transaction message; wherein the verification process comprises at least: verifying the validity of the first authorization credential;
s703: and under the condition that the transaction message is confirmed to pass the verification, carrying out corresponding transaction data processing according to the transaction message.
In some embodiments, in the case that it is determined that the transaction packet passes the verification, the performing, according to the transaction packet, corresponding transaction data processing may include: determining a first type of bill to be consumed and a second type of bill to be validated according to the transaction message; destroying the first type of bills stored in the intelligent contract; and the second type of bill is stored in the intelligent contract.
In some embodiments, the verification process may specifically further include at least one of: verifying the validity of the first ticket signature, verifying the validity of the proof document, verifying the validity of the transaction signature, etc.
In some embodiments, in specific implementation, the transaction server may obtain and perform corresponding verification processing on the transaction message by using a related public key (e.g., a supervision public key, a transaction public key, etc.) that is disclosed externally.
Based on the transaction data processing method provided by the embodiment of the specification, the transaction server can safely and reliably complete corresponding transaction data processing on the premise of supervision by the supervision server.
Referring to fig. 8, an embodiment of the present disclosure further provides a transaction data processing method. The method is specifically applied to the first user terminal side, and when the method is specifically implemented, the following contents may be included.
S801: responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated; the second bill at least comprises a second temporary public key, a second bill public key and secret data;
s802: generating transaction content according to the first type of bill and the second type of bill; signing the transaction content by using a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request;
s803: combining the transaction content and the transaction signature to obtain a transaction message aiming at the transaction data processing request;
s804: sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
In some embodiments, the second temporary public key and the second ticket public key are key data that is independent of the first user and only corresponds to the second type of ticket. The transaction private key is one-time private key data which is irrelevant to the first user and only corresponds to the transaction or the transaction data processing request. Accordingly, the first user terminal can complete specific transaction data processing by using the second temporary public key, the second bill public key and the transaction private key which are equal to the key data irrelevant to the first user, so that the user privacy of the first user can be prevented from being revealed in the transaction data processing process due to the fact that the key data relevant to the first user such as the first payment key are used, and the user privacy of the participator participating in the transaction can be well protected.
Based on the transaction data processing method provided by the embodiment of the specification, the first user terminal can smoothly complete transaction data processing on the premise of no supervision, and privacy data of a user are prevented from being leaked.
Embodiments of the present specification further provide a server, including a processor and a memory for storing processor-executable instructions, where the processor, when implemented, may perform the following steps according to the instructions: responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated; generating an authorization request about the first type of ticket and sending the authorization request to a supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed; generating transaction content according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request; sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
In order to more accurately complete the above instructions, referring to fig. 9, another specific server is provided in the embodiments of the present specification, where the server includes a network communication port 901, a processor 902, and a memory 903, and the above structures are connected by an internal cable, so that the structures may perform specific data interaction.
The network communication port 901 may be specifically configured to obtain a transaction data processing request.
The processor 902 may be specifically configured to respond to a transaction data processing request, and determine a first type of ticket to be consumed; creating a second type of ticket to be validated; generating an authorization request about the first type of ticket and sending the authorization request to a supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed; generating transaction content according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request; sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
The memory 903 may be specifically configured to store a corresponding instruction program.
In this embodiment, the network communication port 901 may be a virtual port that is bound to different communication protocols, so that different data can be sent or received. For example, the network communication port may be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for mail data communication. In addition, the network communication port can also be a communication interface or a communication chip of an entity. For example, it may be a wireless mobile network communication chip, such as GSM, CDMA, etc.; it can also be a Wifi chip; it may also be a bluetooth chip.
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 processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, an embedded microcontroller, and so forth. The description is not intended to be limiting.
In this embodiment, the memory 903 may include multiple layers, and in a digital system, the memory may be any memory as long as binary data can be stored; in an integrated circuit, a circuit without a real form and with a storage function is also called a memory, such as a RAM, a FIFO and the like; in the system, the storage device in physical form is also called a memory, such as a memory bank, a TF card and the like.
Embodiments of the present specification further provide a server, including a processor and a memory for storing processor-executable instructions, where the processor, when implemented specifically, may perform the following steps according to the instructions: receiving and acquiring a first observation identifier and a first type of bill according to an authorization request about the first type of bill; according to a preset check rule and a first observation identifier, carrying out consistency check on the first type of bills; and generating and feeding back the first authorization certificate under the condition that the consistency check is determined to pass.
Embodiments of the present specification further provide a server, including a processor and a memory for storing processor-executable instructions, where the processor, when implemented, may perform the following steps according to the instructions: acquiring a transaction message; verifying the transaction message; wherein the verification process comprises at least: verifying the validity of the first authorization credential; and under the condition that the transaction message is confirmed to pass the verification, carrying out corresponding transaction data processing according to the transaction message.
Embodiments of the present specification further provide a server, including a processor and a memory for storing processor-executable instructions, where the processor, when implemented, may perform the following steps according to the instructions: responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated; the second type bill at least comprises a second temporary public key, a second bill public key and secret data; generating transaction content according to the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request; sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
The embodiment of the present specification further provides a computer storage medium based on the above transaction data processing method, where the computer storage medium stores computer program instructions, and when the computer program instructions are executed, the computer storage medium implements: responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated; generating an authorization request for the first type of ticket and sending the authorization request to a supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed; generating transaction content according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request; sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
The present specification further provides a computer storage medium based on the above transaction data processing method, where the computer storage medium stores computer program instructions, and when the computer program instructions are executed, the computer program instructions implement: receiving and acquiring a first observation identifier and a first type of bill according to an authorization request about the first type of bill; according to a preset check rule and a first observation identifier, carrying out consistency check on the first type of bills; and generating and feeding back the first authorization certificate under the condition that the consistency check is determined to pass.
The embodiment of the present specification further provides a computer storage medium based on the above transaction data processing method, where the computer storage medium stores computer program instructions, and when the computer program instructions are executed, the computer storage medium implements: acquiring a transaction message; verifying the transaction message; wherein the verification process comprises at least: verifying the validity of the first authorization credential; and under the condition that the transaction message is confirmed to pass the verification, carrying out corresponding transaction data processing according to the transaction message.
The embodiment of the present specification further provides a computer storage medium based on the above transaction data processing method, where the computer storage medium stores computer program instructions, and when the computer program instructions are executed, the computer storage medium implements: responding to a transaction data processing request, and determining a first type of bill to be consumed; creating a second type of ticket to be validated; the second bill at least comprises a second temporary public key, a second bill public key and secret data; generating transaction content according to the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request; sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
In this embodiment, the storage medium includes, but is not limited to, a Random Access Memory (RAM), a Read-Only Memory (ROM), a Cache (Cache), a Hard Disk Drive (HDD), or a Memory Card (Memory Card). The memory may be used to store computer program instructions. The network communication unit may be an interface for performing network connection communication, which is set in accordance with a standard prescribed by a communication protocol.
In this embodiment, the functions and effects specifically realized by the program instructions stored in the computer storage medium can be explained by comparing with other embodiments, and are not described herein again.
Referring to fig. 10, in a software aspect, an embodiment of the present disclosure further provides a transaction data processing apparatus applied to a first user terminal, where the apparatus may specifically include the following structural modules:
the first processing module 1001 may be specifically configured to determine a first type of ticket to be consumed in response to the transaction data processing request; and creating a second type of ticket to be validated;
the request module 1002 may be specifically configured to generate an authorization request for a first type of ticket, and send the authorization request to the monitoring server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed;
the second processing module 1003 may specifically be configured to generate transaction contents according to the first authorization ticket, the first type of ticket, and the second type of ticket; signing the transaction content by using a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request;
the combining module 1004 may be specifically configured to combine the transaction content and the transaction signature to obtain a transaction packet for the transaction data processing request;
a sending module 1005, specifically configured to send the transaction packet to a transaction server; wherein the transaction server is deployed with an intelligent contract.
In some embodiments, when the first processing module 1001 is implemented, the second type of ticket to be validated may be created as follows: determining a resource value of the second type of bill according to the transaction data processing request; acquiring 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 a second type of bills according to a second observation public key and a second payment public key of the second user; generating confidential state data about 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 secret data.
In some embodiments, when the first processing module 1001 is implemented specifically, the second temporary public key and the second ticket public key for the second type of ticket may be generated according to the second observation public key and the second payment public key of the second user as follows: acquiring a random number as a second temporary private key for the second type of bill; generating a corresponding second temporary public key according to the second temporary private key; based on a preset construction rule, constructing intermediate data by using a second observation public key and a second temporary private key of a second user; and constructing the second bill public key according to the intermediate data and the second payment public key.
In some embodiments, when the second processing module 1003 is implemented, the transaction content may be generated according to the first authorization ticket, the first type of ticket, and the second type of ticket as follows: constructing a first bill private key for a first type of bill; signing the first type of bill by using a first bill private key to obtain a corresponding first bill signature; generating in-band transmission ciphertext data about the second type of ticket and a certificate about the first type of ticket and the second type of ticket; and 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 certification file to obtain the transaction content.
In some embodiments, when the second processing module 1003 is implemented, the first ticket private key for the first type of ticket may be constructed as follows: acquiring a first bill public key of a first type of bill; and constructing and obtaining a first bill private key by using the first bill public key, a first observation private key and a first payment private key of the first user.
In some embodiments, when the second processing module 1003 is implemented, the first ticket private key may be constructed in the following manner:
Figure BDA0003553106020000221
wherein p is1Is the first ticket private key, R1Is the first ticket public key, a1Is a first observation private key of a first user, b1A first private payment key for the first user.
In some embodiments, the certification file may specifically include a zero knowledge certification file for certifying that the resource value of the first type of ticket is equal to the resource value of the second type of ticket, and the resource value of the second type of ticket meets the requirement of the resource value range.
In some embodiments, the apparatus, when implemented, may be further configured to receive and respond to the initialization request to generate a first observation key and a first payment key; wherein the first observation key comprises a first observation private key and a first observation public key; the first payment secret key comprises a first public payment key and a first private payment key; providing the first observation key to an administration server.
In some embodiments, the first type of ticket may specifically include a ticket based on a UTXO model.
Referring to fig. 11, in a software level, the embodiment of the present specification further provides another transaction data processing apparatus, which is applied to a monitoring server, and the apparatus may specifically include the following structural modules:
the obtaining module 1101 may be specifically configured to receive and obtain, according to an authorization request regarding a first type of ticket, a first observation identifier and the first type of ticket;
the verification module 1102 may be specifically configured to perform consistency verification on the first type of ticket according to a preset verification rule and the first observation identifier;
the generating module 1103 may be specifically configured to generate and feed back the first authorization credential when it is determined that the consistency check passes.
Referring to fig. 12, on a software level, the embodiment of the present specification further provides another transaction data processing apparatus, which is applied to a transaction server deployed with an intelligent contract, and the apparatus may specifically include the following structural modules:
the obtaining module 1201 may be specifically configured to obtain a transaction message;
the verification module 1202 may be specifically configured to perform verification processing on the transaction packet; wherein the verification process comprises at least: verifying the validity of the first authorization credential;
the processing module 1203 may be specifically configured to, under the condition that it is determined that the transaction packet passes verification, perform corresponding transaction data processing according to the transaction packet.
Referring to fig. 13, in a software aspect, the embodiment of the present specification further provides another transaction data processing apparatus, which is applied to a first user terminal, and the apparatus may specifically include the following structural modules:
the first processing module 1301 may be specifically configured to respond to a transaction data processing request, and determine a first type of ticket to be consumed; and creating a second type of ticket to be validated; the second type bill at least comprises a second temporary public key, a second bill public key and secret data;
the second processing module 1302 may be specifically configured to generate transaction content according to the first type of ticket and the second type of ticket; signing the transaction content by using a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request;
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;
a sending module 1304, which may be specifically configured to send the transaction packet to a transaction server; wherein the transaction server is deployed with an intelligent contract.
It should be noted that, the units, devices, modules, etc. illustrated in the above embodiments may be implemented by a computer chip or an entity, or implemented by a product with certain functions. For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. It is to be understood that, in implementing the present specification, functions of each module may be implemented in one or more pieces of software and/or hardware, or a module that implements the same function may be implemented by a combination of a plurality of sub-modules or sub-units, or the like. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
Therefore, the transaction data processing device provided based on the embodiment of the specification can effectively protect the user privacy of the users participating in the transaction and the privacy of the resource values related to the transaction while introducing supervision in the transaction system based on the block chain, so that the related privacy data are prevented from being leaked, and the data security in the transaction data processing process is well protected.
Although the present specification provides method steps as described in the examples or flowcharts, additional or fewer steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an apparatus or client product in practice executes, it may execute sequentially or in parallel (e.g., in a parallel processor or multithreaded processing environment, or even in a distributed data processing environment) according to the embodiments or methods shown in the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. The terms first, second, etc. are used to denote names, but not any particular order.
Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may therefore be considered as a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, classes, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
From the above description of the embodiments, it is clear to those skilled in the art that the present specification can be implemented by software plus necessary general hardware platform. With this understanding, the technical solutions in the present specification may be essentially embodied in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a mobile terminal, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments in the present specification.
The embodiments in the present specification are described in a progressive manner, and the same or similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. The description is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
While the specification has been described with examples, those skilled in the art will appreciate that there are numerous variations and permutations of the specification that do not depart from the spirit of the specification, and it is intended that the appended claims include such variations and modifications that do not depart from the spirit of the specification.

Claims (24)

1. A transaction data processing method is applied to a first user terminal and comprises the following steps:
responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated;
generating an authorization request about the first type of ticket and sending the authorization request to a supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition that the consistency verification is passed;
generating transaction content according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request;
sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
2. The method of claim 1, wherein creating a ticket of a second type to be validated comprises:
determining a resource value of the second type of bill according to the transaction data processing request;
acquiring 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 aiming at a second type of bill according to a second observation public key and a second payment public key of the second user;
generating confidential state data about 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 secret data.
3. The method of claim 2, wherein generating a second ephemeral public key and a second instrument public key for a second class of instruments from a second observation public key and a second payment public key of the second user comprises:
acquiring a random number as a second temporary private key for the second type of bill; generating a corresponding second temporary public key according to the second temporary private key;
based on a preset construction rule, constructing intermediate data by using a second observation public key and a second temporary private key of a second user;
and constructing the second bill public key according to the intermediate data and the second payment public key.
4. The method of claim 2, wherein generating transaction content based on the first authorization ticket, the first type of ticket, and the second type of ticket comprises:
constructing a first bill private key aiming at the first type of bills;
signing the first type of bills by using a first bill private key to obtain a corresponding first bill signature;
generating in-band transmission ciphertext data about the second type of ticket, and a certification document about the first type of ticket and the second type of ticket;
and 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 certification file to obtain the transaction content.
5. The method of claim 4, wherein constructing a first ticket private key for a first type of ticket comprises:
acquiring a first bill public key of a first type of bill;
and constructing and obtaining a first bill private key by using the first bill public key, a first observation private key and a first payment private key of the first user.
6. The method of claim 5, wherein constructing the first ticket private key using the first ticket public key and the first observation private key and the first payment private key of the first user comprises:
constructing a first ticket private key as follows:
Figure FDA0003553106010000021
wherein p is1Is as followsA private key of the bill R1Is the first ticket public key, a1Is a first observation private key of a first user, b1A first payment private key for the first user.
7. The method of claim 4, wherein the certification document includes a zero knowledge certification document for certifying that the resource value of the first type of ticket is equal to the resource value of the second type of ticket, and the resource value of the second type of ticket meets the requirement of the resource value range.
8. The method of claim 1, further comprising:
receiving and responding to an initialization request, and generating a first observation secret key and a first payment secret key; wherein the first observation key comprises a first observation private key and a first observation public key; the first payment secret key comprises a first public payment key and a first private payment key;
providing the first observation key to an administration server.
9. The method of claim 1 wherein the first type of ticket comprises a ticket based on a UTXO model.
10. A transaction data processing method is applied to a supervision server and comprises the following steps:
receiving and acquiring a first observation identifier and a first type of bill according to an authorization request about the first type of bill;
according to a preset verification rule and a first observation identifier, performing consistency verification on the first type of bills;
and generating and feeding back the first authorization certificate under the condition that the consistency check is determined to pass.
11. The method of claim 10, wherein after generating and feeding back the first authorization credential, the method further comprises:
and storing the first observation identification and the first type of bill in a first database.
12. The method of claim 11, wherein the performing consistency check on the first type of ticket according to the preset check rule and the first observation identifier comprises:
inquiring a second database according to the first observation identifier to obtain a first observation private key;
acquiring a first bill public key and a first temporary public key aiming at a first type of bill and a first payment public key of a first user;
according to a preset verification rule, a first temporary public key, a first observation private key and a first payment public key are utilized to construct a verification public key;
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 check according to the comparison result.
13. The method of claim 12, wherein constructing the verification public key according to a preset verification rule by using the first temporary public key, the first observation private key, and the first payment public key comprises:
the verification public key is constructed in the following way:
Figure FDA0003553106010000031
wherein, P1' as a check public key, R1Is a first temporary public key, a1Is a first observation private key, G is a base point on the elliptic curve group, B1The first public key is paid.
14. The method of claim 12, wherein prior to receiving and pursuant to the authorization request for the ticket of the first type, the method further comprises:
acquiring a first observation secret key provided by a first user terminal;
and saving the first observation key in a second database.
15. The method of claim 14, further comprising:
inquiring the intelligent contract and determining an abnormal bill related to the abnormal transaction;
and according to the abnormal bill, determining an initiator and/or a receiver of the abnormal bill by querying the first database and/or the second database.
16. A transaction data processing method is applied to a transaction server deployed with an intelligent contract and comprises the following steps:
acquiring a transaction message;
verifying the transaction message; wherein the verification process comprises at least: verifying the validity of the first authorization credential;
and under the condition that the transaction message is confirmed to pass the verification, carrying out corresponding transaction data processing according to the transaction message.
17. The method according to claim 16, wherein performing corresponding transaction data processing according to the transaction message comprises:
determining a first type of bill to be consumed and a second type of bill to be validated according to the transaction message;
destroying the first type of bills stored in the intelligent contract; and the second type of bill is stored in the intelligent contract.
18. The method of claim 16, wherein the verification process further comprises at least one of: verifying the validity of the first ticket signature, verifying the validity of the proof document, and verifying the validity of the transaction signature.
19. A transaction data processing method is applied to a first user terminal and comprises the following steps:
responding to a transaction data processing request, and determining a first type of bill to be consumed; and creating a second type of ticket to be validated; the second type bill at least comprises a second temporary public key, a second bill public key and secret data;
generating transaction content according to the first type of bill and the second type of bill; signing the transaction content by using 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 aiming at the transaction data processing request;
sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
20. A transaction data processing apparatus, applied to a first user terminal, comprising:
the first processing module is used for responding to the transaction data processing request and determining a first type of bill to be consumed; and creating a second type of ticket to be validated;
the request module is used for generating an authorization request about the first type of bill and sending the authorization request to the supervision server; the authorization request at least carries a first type of bill and a first observation identifier of a first observation secret key of a first user; the supervision server carries out consistency verification on the first type of bills according to a preset verification rule and a first observation identifier, and feeds back a first authorization voucher aiming at the first type of bills under the condition of determining that the consistency verification is passed;
the second processing module is used for generating transaction contents according to the first authorization voucher, the first type of bill and the second type of bill; signing the transaction content by using a transaction private key to obtain a corresponding transaction signature; wherein the transaction private key is generated for the transaction data processing request;
the combination module is used for combining the transaction content and the transaction signature to obtain a transaction message aiming at the transaction data processing request;
the sending module is used for sending the transaction message to a transaction server; wherein the transaction server is deployed with an intelligent contract.
21. A transaction data processing device applied to a supervision server comprises:
the acquisition module is used for receiving and acquiring a first observation identifier and a first type of bill according to an authorization request about the first type of bill;
the checking module is used for carrying out consistency checking on the first type of bills according to a preset checking rule and the first observation identifier;
and the generating module is used for generating and feeding back the first authorization certificate under the condition that the consistency check is determined to pass.
22. A transaction data processing device is applied to a transaction server deployed with intelligent contracts, and comprises the following components:
the acquisition module is used for acquiring a transaction message;
the verification module is used for verifying the transaction message; wherein the verification process comprises at least: verifying the validity of the first authorization credential;
and the processing module is used for carrying out corresponding transaction data processing according to the transaction message under the condition of determining that the transaction message passes the verification.
23. A server comprising a processor and a memory for storing processor-executable instructions which, when executed by the processor, implement the steps of the method of any one of claims 1 to 9, or 10 to 15, or 16 to 18, or 19.
24. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method of any of claims 1 to 9, or 10 to 15, or 16 to 18, or 19.
CN202210267859.3A 2022-03-18 2022-03-18 Transaction data processing method and device and server Pending CN114742649A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210267859.3A CN114742649A (en) 2022-03-18 2022-03-18 Transaction data processing method and device and server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210267859.3A CN114742649A (en) 2022-03-18 2022-03-18 Transaction data processing method and device and server

Publications (1)

Publication Number Publication Date
CN114742649A true CN114742649A (en) 2022-07-12

Family

ID=82276645

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210267859.3A Pending CN114742649A (en) 2022-03-18 2022-03-18 Transaction data processing method and device and server

Country Status (1)

Country Link
CN (1) CN114742649A (en)

Similar Documents

Publication Publication Date Title
CN111859348B (en) Identity authentication method and device based on user identification module and block chain technology
US11212081B2 (en) Method for signing a new block in a decentralized blockchain consensus network
RU2747947C2 (en) Systems and methods of personal identification and verification
CN111680324B (en) Credential verification method, management method and issuing method for blockchain
CN111080295B (en) Electronic contract processing method and device based on blockchain
EP3114602B1 (en) Method and apparatus for verifying processed data
EP3509006A1 (en) Information sharing system
CN112507363A (en) Data supervision method, device and equipment based on block chain and storage medium
CN112215608A (en) Data processing method and device
CN107493291A (en) A kind of identity identifying method and device based on safety element SE
CN111460457A (en) Real estate property registration supervision method, device, electronic equipment and storage medium
CN111818186B (en) Information sharing method and system
CN113822675A (en) Block chain based message processing method, device, equipment and storage medium
CN111314066B (en) Block chain-based data transfer method, terminal and computer-readable storage medium
Tan et al. Challenges of post-quantum digital signing in real-world applications: A survey
Sathya et al. A comprehensive study of blockchain services: future of cryptography
CN113328854B (en) Service processing method and system based on block chain
CN112600830B (en) Service data processing method and device, electronic equipment and storage medium
Huang et al. zkChain: A privacy‐preserving model based on zk‐SNARKs and hash chain for efficient transfer of assets
CN113434882A (en) Communication protection method and device of application program, computer equipment and storage medium
Wu et al. The survey on the development of secure multi-party computing in the blockchain
US20180218363A1 (en) Payment instrument management with key tokenization
CN115409511B (en) Personal information protection system based on block chain
Khanji et al. Boosting iot efficiency and security through blockchain: blockchain-based car insurance process-a case study
CN111814193B (en) Information sharing method, device and equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination