WO2020172760A1

WO2020172760A1 - Method, server, client and system for processing digital currency transaction data

Info

Publication number: WO2020172760A1
Application number: PCT/CN2019/076017
Authority: WO
Inventors: 陈岱; 谢翔; 傅志敬; 孙立林
Original assignee: 云图有限公司
Priority date: 2019-02-25
Filing date: 2019-02-25
Publication date: 2020-09-03

Abstract

A method, a server, a client and a system for processing digital currency transaction data. A private key of a transaction account is divided into different private key components respectively possessed by different secret key service clients corresponding to digital currency transactions, namely different users. Execution of a digital currency transaction requires agreement of the respective secret key service clients on a transfer transaction, and then the private key components stored in the respective secret key service clients are used to perform signature computation to obtain signed data for validation of transfer information. A sum of the private key components stored in the respective secret key service clients is the private key of the transaction account. The signed data is obtained by using the private key of the transaction account to affix a signature, thereby completing a signed transfer associated with the transaction account. Since private key components of a transaction account are separately stored, completion of a transfer transaction requires a signature formed from the private key components stored in multiple secret key service clients, thereby ensuring secure digital currency transactions.

Description

Digital currency transaction data processing method, server, client and system

Technical field

This manual belongs to the field of digital currency technology, and in particular relates to a digital currency transaction data processing method, server, client and system.

Background technique

Digital currency refers to the digitization of currency, which can be understood as an alternative currency in the form of electronic currency. Electronic currency can be understood as an encrypted sequence number representing cash, which can be used to represent the currency value of various amounts in reality. Both digital gold coins and cryptocurrencies belong to digital currencies. Digital currency is different from virtual currency in the virtual world because it can be used for real goods and service transactions, not limited to online games.

Digital currency transactions can include: digital currency buying or selling, digital currency withdrawal, digital currency asset management, digital currency hot and cold wallet transfers, etc., data currency transactions can be through digital currency trading platforms (such as: Exchange). How to ensure the security of users' transactions during digital currency transactions and ensure the security of users or exchange assets is a technical problem that needs to be solved urgently in this field.

Summary of the invention

The purpose of the embodiments of this specification is to provide a digital currency transaction data processing method, server, client and system to improve transaction security.

In the first aspect, the embodiments of this specification provide a digital currency transaction data processing method, including:

Receiving transaction request data sent by the first secret key service client, where the transaction request data includes data to be signed;

Sending the data to be signed to the second secret key service client;

According to the first private key component saved by the first secret key service client and the second private key component saved by the second secret key service client, the data to be signed is signed to obtain the signature data, wherein: The sum of the first private key component and the second private key component is the private key of the transaction account;

The signature data is sent to the first secret key service client, so that the first secret key service client performs transaction transfer processing.

In the second aspect, this manual provides a digital currency transaction data processing server, including:

A transaction request receiving module, configured to receive transaction request data sent by the first secret key service client, where the transaction request data includes data to be signed;

A signed data forwarding module, configured to send the data to be signed to the second secret key service client;

The first signature module is configured to sign the data to be signed according to the first private key component saved by the first secret key service client and the second private key component saved by the second secret key service client , Obtain the signature data, wherein the sum of the first private key component and the second private key component is the private key of the transaction account;

The first transfer processing module is configured to send the signature data to the first secret key service client, so that the first secret key service client performs transaction transfer processing.

In the third aspect, this manual provides a digital currency transaction data processing method, including:

Sending transaction request data to the secret key management server, so that the secret key management server sends transaction request data to the second secret key service client, where the transaction request data includes data to be signed;

Receiving the second private key component saved by the second key service client and sent by the key management server;

According to the first private key component stored by itself and the received second private key component, the data to be signed is signed to obtain signature data, wherein the first private key component and the second private key The sum of the weights is the private key of the trading account;

Perform transaction transfer processing according to the signature data.

In the fourth aspect, this manual provides a digital currency transaction data processing client, including:

The transaction request sending module is configured to send transaction request data to the secret key management server, so that the secret key management server sends the transaction request data to the second secret key service client, and the transaction request data includes the data to be signed;

A secret key receiving module, configured to receive the second private key component saved by the second secret key service client and sent by the secret key management server;

The second signature module is configured to sign the data to be signed according to the first private key component stored by itself and the received second private key component to obtain signature data, wherein the first private key component The sum of the second private key component is the private key of the transaction account;

The second transfer processing module is used to perform transaction transfer processing according to the signature data.

In the fifth aspect, this manual provides a digital currency transaction data processing method, including:

Receiving transaction request data sent by the secret key management server, the transaction request data being sent by the first secret key service client, and the transaction request data including data to be signed;

Return confirmation signature information to the key management server, and send the second private key component stored by itself to the key management server, so that the key management server and the first key service client The second private key component and the first private key component saved by the first secret key service client sign the data to be signed to obtain the signature data, and the first secret key service client is based on The signature data is processed for transaction transfer;

Wherein, the sum of the first private key component and the second private key component is the private key of the transaction account.

In the sixth aspect, this manual provides a digital currency transaction data processing terminal, including:

The transaction request query module is configured to receive transaction request data sent by the secret key management server, the transaction request data is sent by the first secret key service client, and the transaction request data includes data to be signed;

The signature confirmation module is used to return confirmation signature information to the secret key management server, and send the second private key component stored by itself to the secret key management server, so that the secret key management server and the first The secret key service client signs the data to be signed according to the second private key component and the first private key component saved by the first secret key service client to obtain signature data, and the The secret key service client performs transaction transfer processing according to the signature data;

In a seventh aspect, this specification provides a digital currency transaction data processing device, including: at least one processor and a memory for storing processor-executable instructions. The processor implements the first aspect or The method of the third or fifth aspect.

In an eighth aspect, this specification provides a computer-readable storage medium on which computer instructions are stored, and when executed, the instructions implement the method described in the first aspect, the third aspect, or the fifth aspect.

In a ninth aspect, this specification provides a digital currency transaction data processing system, including: a secret key management server, a first secret key service client, and a second secret key service client;

The digital currency transaction data processing system is used to perform at least one of the buying and selling of digital currency, the withdrawal of digital currency, the cold wallet transfer of digital currency in the exchange system, and the investment management of digital currency. The secret key The management server is configured to execute the method described in the first aspect, the first secret key service client is configured to execute the method described in the second aspect, and the second secret key service client is configured to execute the third aspect. The method described in the aspect;

Wherein, if the digital currency transaction data processing system is used for buying and selling digital currency, the first secret key service client is a buyer user transaction client or a seller user transaction client, and the second secret The key service client is the exchange client;

If the digital currency transaction data processing system is used to withdraw digital currency, the first secret key service client is a withdrawal user client, and the second secret key service client is an exchange client, Wherein, if the withdrawal of the digital currency is an exchange withdrawal, the second secret key service client includes one or more;

If the digital currency transaction data processing system is used for cold wallet transfer of digital currency of the exchange system, the first secret key service client and the second secret key service client are both exchange clients, where , The second secret key service client includes one or more;

If the digital currency transaction data processing system is used for digital currency investment management, the first secret key service client is a wealth management user client, and the second secret key service client is an asset management client.

The digital currency transaction data processing method, server, client, terminal, processing equipment, and system provided in this manual split the private key of the transaction account into different private key components, which are stored in different secret keys corresponding to the digital currency transaction. The service client is in the hands of different users. When a digital currency transaction is required, after each secret key service client agrees to the transaction transfer, the private key component saved by each secret key service client is used for signature calculation to obtain the signature data, and the transfer information can take effect. The sum of the private key components saved by each secret key service client is the private key of the transaction account. The signature data is essentially obtained by signing with the private key of the transaction account to complete the signature transfer of the transaction account. By separately storing the private key components of the transaction account, when transferring funds, the private key components of multiple secret key service clients need to be signed together to complete the transaction, which ensures the security of digital currency transactions.

Description of the drawings

In order to more clearly explain the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only These are some embodiments described in this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative labor.

FIG. 1 is a schematic diagram of a transaction flow of buying and selling digital currency in an embodiment of this specification;

FIG. 2 is a schematic diagram of a process of a user withdrawing digital currency in an embodiment of this specification;

FIG. 3 is a schematic diagram of a flow of digital currency withdrawal performed by an exchange in an embodiment of this specification;

FIG. 4 is a schematic diagram of the creation process of a cold wallet of an exchange in an embodiment of this specification;

FIG. 5 is a schematic diagram of a flow of creating a wealth management account in an embodiment of this specification;

FIG. 6 is a schematic flowchart of a method for processing digital currency transaction data in an embodiment of this specification;

FIG. 7 is a schematic flowchart of a method for processing digital currency transaction data in another embodiment of this specification;

FIG. 8 is a schematic flowchart of a method for processing digital currency transaction data in another embodiment of this specification;

FIG. 9 is a schematic diagram of the data processing flow of transferring funds from the exchange cold wallet to the hot wallet in an embodiment of this specification;

10 is a schematic diagram of the data processing flow of digital currency buying or digital currency selling or user withdrawal in the embodiment of this specification;

FIG. 11 is a schematic diagram of a processing flow of digital currency investment management data in an embodiment of this specification;

FIG. 12 is a schematic diagram of a data processing flow of digital currency withdrawal performed by an exchange in an embodiment of this specification;

Figure 13 is a schematic diagram of the module structure of an embodiment of the digital currency transaction data processing server provided in this specification;

14 is a schematic diagram of the structure of a digital currency transaction data processing client in an embodiment of this specification;

15 is a schematic diagram of the structure of a digital currency transaction data processing terminal in an embodiment of this specification;

16 is a block diagram of the hardware structure of the server applying the digital currency transaction data processing method in the embodiment of this specification.

detailed description

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

With the transition from a paper-based economy to a digital economy, electronic cash will become the mainstream, an alternative currency in the form of electronic money. Nowadays, there are more and more application scenarios for digital currency transactions through exchanges. Exchanges can be understood as a network platform for managing data currency transactions.

The transaction of digital currency in the embodiment of this specification may include: buying and selling of digital currency, withdrawal of digital currency (including user withdrawal and exchange withdrawal), cold wallet transfer of exchange digital currency, and digital currency investment Management, etc., of course, other digital currency transactions can also be conducted according to actual needs, and the embodiments of this specification do not specifically limit it.

Figure 1 is a schematic diagram of the transaction flow of digital currency buying and selling in an embodiment of this specification. The numbers on the lines in Figure 1 can indicate the steps of digital currency buying and selling. As shown in Figure 1, the digital currency buying and selling The export process can include the following:

1. A buying order user submits a buying order commission, which can indicate a buying order initiated by the user, such as buying digital currency.

2. After receiving the commission, the exchange system can perform operations such as authentication, risk control, and freezing of account balances. If there is no corresponding matching sell order, the exchange system can entrust the buy order to the market. Among them, authentication can refer to judging whether the user has the right to operate, and risk control can refer to judging the risk probability of the current digital currency transaction, and freezing the account balance for subsequent corresponding operations on the user's account.

3. A sell order user initiates a sell order commission, which can indicate a sell order initiated by the user, such as selling digital currency.

4. After receiving the commission, the exchange system can perform operations such as authentication, risk control, and freezing of account balances. If there is a corresponding matching buy order, a transaction record will be generated.

5. The user of the buy and sell order can inquire whether his entrusted record is executed. After the transaction is completed, users (including users who buy orders and users who sell orders) and the exchange can perform transaction settlement, that is, transfer. In the embodiments of this specification, the private key corresponding to the user account can be divided into a first private key component and a second private key component. It is kept by the user and the exchange respectively, and the buying and selling of digital currency requires the user and the exchange to sign together. In the embodiment of this specification, the key management server (kms, Key Management Service) can also be used to manage and use the secret key. The process of transferring can refer to the process of the digital currency transaction data processing method in the embodiment of this specification to complete the digital currency transaction. Buy and sell.

Figure 2 is a schematic diagram of the user's digital currency withdrawal process in an embodiment of this specification. The numbers on the lines in Figure 2 can indicate the steps of the user's digital currency withdrawal. As shown in Figure 2, the user performs digital currency withdrawal The transaction can include the following processes:

1. The withdrawal user initiates a withdrawal application.

2. After receiving the application, the exchange system can perform operations such as authentication, risk control, and freezing of account balances.

3. Withdrawal users can query the audit results. After the review is passed, the withdrawal user and the exchange can perform the withdrawal operation. In the embodiment of this manual, the private key corresponding to the user account can be divided into the first private key component and the second private key component, which are respectively saved by the user and the exchange , When the user withdraws money, the user and the exchange must sign together to achieve it. In the embodiment of this specification, the key management server (kms, Key Management Service) can also be used to manage and use the key, and the process of withdrawing money can refer to the process of the digital currency transaction data processing method in the embodiment of this specification.

Fig. 3 is a schematic diagram of the process of digital currency withdrawal performed by the exchange in an embodiment of this specification. The numbers on the lines in Fig. 3 can indicate the steps of the exchange’s digital currency withdrawal. As shown in Fig. 3, the exchange performs digital currency withdrawal. The withdrawal of coins can include the following processes:

1. The operator initiates a withdrawal application. Operators can be understood as financial administrators or other staff of the exchange.

2. After receiving the application, the exchange system can perform authentication, risk control, and freeze account balances. After the review is passed, the administrator of the exchange can perform coin withdrawal operations. In the embodiment of this manual, the private key corresponding to the exchange account can be divided into the first private key component and the second private key component, which are managed by the exchange separately When the exchange performs the withdrawal, multiple administrators of the exchange need to sign together to realize the withdrawal. The process of withdrawal can refer to the process of the digital currency transaction data processing method in the embodiment of this specification.

In the internal digital currency management of the exchange, it is generally divided into hot and cold wallets, cold wallets for offline storage, and hot wallets online to process user withdrawals. When an exchange transfers funds from a cold wallet to a hot wallet, the transfer amount usually involved is relatively large. Under normal circumstances, the exchange will have multiple management users, similar to the shareholders or managers of the company. In the embodiment of this manual, the private key of the cold wallet corresponding to the exchange can be split into multiple private key components, which are stored in different Of administrative users. In the embodiments of the present specification, the management and use of the secret key can also be performed through a secret key management server (kms, Key Management Service). When a cold wallet is required to transfer money to a hot wallet, the secret key management server is used to obtain the information that each management user agrees to the transfer, and the private key component in the hands of each management user is used to sign, then the transfer process from the cold wallet to the hot wallet can be realized.

Some embodiments of this specification also provide a method for creating a cold wallet of an exchange. FIG. 4 is a schematic diagram of the creation process of a cold wallet of an exchange in an embodiment of this specification. As shown in FIG. 4, a transaction in an embodiment of this specification It can include 2 administrators, each administrator corresponds to a key service client, the key service client corresponding to administrator 1 can be called the first key service client, and the key service corresponding to administrator 2 The client can represent the second key service client, and the numbers on the lines in the figure can represent the steps of cold wallet creation. As shown in Figure 4, the process of creating a cold wallet can include the following processes:

1. Administrator 1 can use the first secret key service client to locally generate the private key component and the public key sk1+pk1 corresponding to the private key component: (sk1 represents the private key component generated by administrator 1, and pk1 represents the private key of administrator 1. The public key corresponding to the key component), and obtain the pk2 of administrator 2 offline (pk2 represents the public key corresponding to the private key component of administrator 2), call kms to create the wallet interface, and act as a participant of the wallet.

2. The administrator 2 can use the second secret key service client to locally generate the private key component and the public key corresponding to the private key component: sk2+pk2 (sk2 represents the private key component generated by the administrator 2, and pk2 represents the private key of the administrator 2. The public key corresponding to the key component), then split sk2 into 2 parts sk2=sk2-1+sk2-2 (where sk2-2 is encrypted by pk1), and call kms's wallet join interface as a participant of the wallet .

3. Administrator 1 obtains partial private key fragments sk2-2 of administrator 2 through kms, and decrypts them with sk1.

4. Administrator 1 and kms perform an MPC (Secure Muti-Party Computation) calculation to generate the public key of the cold wallet. When performing MPC calculation, administrator 1 provides sk1+sk2-2, and kms provides sk2-1.

5. Obtaining the public key means that the cold wallet is successfully created, and each administrator and the secret key management server will not hold the complete secret key, which can ensure the security of the cold wallet digital currency transaction management.

The digital currency transactions in the embodiments of this specification can also include digital currency investment management. The investment process can be expressed in the digital asset management system. The user first needs to register a wealth management user and then purchase wealth management products. Figure 5 is a schematic diagram of the process of creating a wealth management account in an embodiment of this specification. The numbers on the lines in Figure 5 can indicate the steps of creating a wealth management account. As shown in Figure 5, the process of creating a wealth management account can include:

1. Wealth management users can use the first secret key service client to locally generate the private key component and the public key sk1+pk1 corresponding to the private key component (sk1 represents the private key component generated by the wealth management user, and pk1 represents the corresponding private key component generated by the wealth management user Public key) and through the pk2 of the asset manager obtained offline (pk2 represents the public key corresponding to the private key component of the wealth management user), call kms to create the wallet interface and act as a participant of the wallet. Financial users can represent investors.

2. The asset manager can use the second secret key service client to locally generate the private key component sk2+pk2 (sk2 represents the private key component generated by the asset manager, and pk2 represents the public key corresponding to the asset manager’s private key component). Split sk2 into 2 parts sk2=sk2-1+sk2-2 (sk2-2 is encrypted by pk1), and call kms's wallet join interface as a participant of the wallet. The asset manager may refer to an institution that provides investment management services.

3. The wealth management user obtains part of the private key fragment sk2-2 of the asset manager through kms, and decrypts it with sk1.

4. Wealth management users and kms do an MPC calculation to generate the public key of the financial user account. Wealth management users provide sk1+sk2-2, and kms provides sk2-1.

5. Obtain the public key, which represents the successful creation of the account wallet of the wealth management user, and each user and the secret key management server will not hold the complete secret key, which can ensure the security of the digital currency transaction management of the wealth management user. After the wealth management user account is created, you can use the wealth management account to buy wealth management products. The purchase of the wealth management product requires the wealth management user and the asset manager to use the private key components of their respective wealth management accounts to perform signature calculations. The process of buying wealth management products You can refer to the process of the digital currency transaction data processing method in the embodiment of this specification.

The embodiment of this specification provides a method for processing digital currency transaction data. By dividing the private key of the transaction account into a first private key component and a second private key component, they are stored in different secret key service clients. When performing digital currency transaction transfers, the private key components stored in each secret key service client are used to sign the transferred data. Each secret key service client agrees to sign and agree to transfer to realize transaction transfer, which ensures the security of exchange digital currency transactions.

The digital currency transaction data processing method in this manual can be applied to the client or server. The client can be a smart phone, a tablet computer, a smart wearable device (smart watch, virtual reality glasses, virtual reality helmet, etc.), smart car equipment, etc. Electronic equipment.

Specifically, FIG. 6 is a schematic flow diagram of a digital currency transaction data processing method in an embodiment of this specification. The digital currency transaction data processing method in this embodiment of this specification may represent a transaction management process performed on the key management server side. As shown in Figure 6, the overall process of the digital currency transaction data processing method provided in an embodiment of this specification may include:

Step 602: Receive transaction request data sent by the first secret key service client, where the transaction request data includes data to be signed.

The first key service client can be understood as a user's client in the digital currency transaction process. For example, if the digital currency is purchased, the first key service client can represent the buyer's client; For the sale of digital currency, the first key service client can represent the client of the seller user; if the user withdraws the digital currency, the first key service client can represent the client of the withdrawing user; For the withdrawal of digital currency, the first secret key service client can represent the client of the administrator who made the withdrawal request in the exchange; if the exchange cold wallet transfer transaction is performed, the first secret key service client can Represents the client of the administrator who requested the cold wallet transfer. For example, the client corresponding to the administrator 1 in Figure 4 can be called the first secret key service client; if the investment management of digital currency is performed, the first secret The key service client can represent the client of a wealth management user.

In some embodiments of this specification, the transaction request data may include at least one of digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, exchange withdrawal request data, and wealth management request data. When conducting digital currency transactions, users can send transaction request data to the key management server through the first secret key service client, such as: request data for buying digital currency, request data for selling digital currency, and user withdrawal Request data, request data of exchange currency withdrawal, cold wallet transfer request data, or purchase request data of wealth management products, etc. Among them, the transaction request data can include data to be signed, and the data to be signed can indicate the specific information of the transaction request, such as: the amount of currency bought, the amount of currency sold, the amount of money withdrawn, the amount of cold wallet transfer, and the amount of money purchased And type.

Step 604: Send the data to be signed to the second secret key service client.

After receiving the transaction request data sent by the first key management client, the key management server may send the data to be signed to the second key service client, and the second key service client will confirm whether the transfer is allowed. Among them, the second secret key service client can represent the client corresponding to the other user of the digital currency transaction. For example, if the digital currency is sold, the second secret key service client can represent the exchange client. The client can be understood as an exchange system or an exchange platform, or as a client corresponding to the management personnel designated by the exchange; if the user withdraws digital currency, the second secret key service client can represent the exchange customer End; if the exchange performs digital currency withdrawals, the second secret key service client can represent the clients of other administrators in the exchange excluding the first secret key service client. The number can be one or more, according to The actual setting is required, and the embodiment of this specification does not make specific restrictions; if the exchange cold wallet transfer transaction is performed, the second secret key service client can represent the clients other than the administrator of the first secret key service client, and the number can be One or more, set according to actual needs, the embodiment of this specification does not specifically limit; if the investment management of digital currency, the second secret key service client can represent the client corresponding to the asset manager, which can be understood as asset management Managed system or organization.

After the second key service client receives the data to be signed, the user corresponding to the second key service client can judge whether the transaction is completed according to the data to be signed. If the transaction is completed, it can return signature confirmation information to the key management server. If there is no transaction, you can return the rejection signature information.

Step 606: Sign the data to be signed according to the first private key component saved by the first secret key service client and the second private key component saved by the second secret key service client to obtain signature data , Wherein the sum of the first private key component and the second private key component is the private key of the transaction account.

In a specific implementation process, the first secret key service client and the second secret key service client in the embodiment of this specification may respectively store the first private key component and the second private key component, where the first private key component The sum of the components of the second private key can be the private key of the transaction account. The transaction account can represent the account that needs to be transferred in the current digital currency transaction, such as a user account or an exchange account. For digital currency trading, user withdrawal transactions, digital currency investment management, etc., the sum of the first private key component and the second private key component can be the private key of the user account; if the cold wallet transfer of the exchange is performed, Then the sum of the first private key component and the second private key component can be the private key of the exchange cold wallet; if the exchange is withdrawn, the sum of the first private key component and the second private key component can be the exchange account The corresponding private key.

After the first secret key service client and the second secret key service client both agree to conduct digital currency transactions, the secret key management server and the first secret key service client can be based on the first private key component and the second private key component. Perform signature calculation, sign the data to be signed, and obtain the signature data. The sum of the private key components saved by each secret key service client is the private key of the transaction account, and the signature data is essentially obtained by signing the private key of the transaction account, completing the secure transaction of digital currency. The signature data can indicate that digital currency transactions are allowed, such as the purchase of digital currency, the signature data can indicate the amount of digital currency that needs to be paid for the buyer user’s account and the amount of digital currency purchased, so as to be transferred from the buyer user’s account Corresponding digital currency, and transfer the amount of digital currency purchased.

In the embodiment of this specification, when signing data to be signed, secure multi-party calculation can be used, that is, the first secret key service client and the key management server respectively provide part of the private key components to perform signature calculation on the data to be signed to obtain the signature data. Improve the security of digital currency transactions. Of course, other signature methods can also be used according to actual needs, and the embodiment of this specification does not specifically limit it.

Step 608: Send the signature data to the first secret key service client, so that the first secret key service client performs transaction transfer processing.

After obtaining the signature data, the key management server can return the signature data to the first key service client, and the first key service client can send the signature data to the blockchain for transfer processing of digital currency transactions. Blockchain is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.

For example: User A needs to buy digital currency. User A sends digital currency buying request data to the key management server through his client, the first key service client, and the key management server will buy digital currency request data Sent to the exchange, the second secret key service client, when there is a corresponding matching sell order, the exchange confirms that the transaction can be carried out, and can return the confirmation signature information. The key management server can obtain the second private key component corresponding to the account of user A stored in the exchange, and perform signature calculation with the first key management client. Wherein, the first secret key service client stores the first private key component of the user A account, and uses the first private key component and the second private key component to perform signature calculation to obtain signature data. The first secret key service client sends the signature data to the blockchain, and the blockchain can be used to perform corresponding transfer processing to user A’s account, such as the amount of digital currency bought and the corresponding amount of digital currency that needs to be paid. Such as: the amount of bitcoin to buy, the amount of ether that needs to be paid, etc.

Other digital currency transactions such as: digital currency sales, users' digital currency withdrawals, exchange withdrawals, exchange cold wallet transfers, digital currency investment management transactions and other digital currency transaction processes, you can refer to digital currency buying The transaction processing process is not repeated here.

For the digital currency transaction process in some embodiments of this specification, the second secret key service client can be multiple, for example: exchange cold wallet transfer transaction, exchange currency withdrawal transaction, take the exchange cold wallet transfer transaction as an example, When there are two second key service clients, the data processing process of digital currency transactions can be referred to as follows:

Suppose that the exchange includes three administrators: administrator 1, administrator 2, administrator 3, administrator 1 is responsible for the financial management of the exchange, administrator 2 is the boss, administrator 3 is the shareholder, and the client corresponding to administrator 1 It can represent the first key service client, and the clients corresponding to the administrator 2 and administrator 3 can represent the second key service client. Administrator 1, administrator 2, and administrator 3 respectively store the private key components sk1, sk2, and sk3 of the private key of the cold wallet corresponding to the exchange. Among them, the private keys saved by administrator 1, administrator 2, and administrator 3 The sum of the components is equal to the private key of the cold wallet, that is, sk1+sk2+sk3=the private key of the cold wallet. When the exchange needs to transfer money from a cold wallet to a hot wallet, the administrator 1 can send a cold wallet transfer request to the key management server through its first key service client. After the key management server receives the request, it can The request is sent to the second key service client corresponding to the administrator 2 and the administrator 3, and the administrator 2 and the administrator 3 confirm whether to approve the transfer. If both the administrator 2 and the administrator 3 agree to the transfer, the confirmation signature information can be returned through the corresponding second key service client. After the key management server receives the confirmation signature information returned by the administrator 2 and the administrator 3, it can obtain the private key components saved by the administrator 2 and the administrator 3, and then use each of the administrator 1, administrator 2, and administrator 3. The saved private key component signs the data to be signed in the cold wallet transfer request and obtains the signature data, indicating that the exchange agrees to the transfer information. The key management server can also return the obtained signature data to the first key service client, such as sending it to the administrator 1, and the administrator 1 can send the signature data to the blockchain, and the blockchain will perform the transfer processing.

It should be noted that the private key components of each secret key service client in the embodiments of this specification can be generated when the trading account is created. Modular addition and subtraction algorithms can be used to split the private key corresponding to the account into different The private key component is then saved to each secret key service client. For details, refer to the method of generating the private key component in the process of creating the exchange cold wallet or wealth management account in Figure 4 and Figure 5. Of course, other methods can also be used to split and combine the private keys of the cold wallet, which is not specifically limited in the embodiment of this specification.

The digital currency transaction data processing method provided by the embodiment of this specification splits the private key of the transaction account into different private key components, which are respectively stored in the hands of different secret key service clients corresponding to the digital currency transaction, that is, different users. When a digital currency transaction is required, after each secret key service client agrees to the transaction transfer, the private key component saved by each secret key service client is used for signature calculation to obtain the signature data, and the transfer information can take effect. The sum of the private key components saved by each secret key service client is the private key of the transaction account. The signature data is essentially obtained by signing with the private key of the transaction account to complete the signature transfer of the transaction account. By separately storing the private key components of the transaction account, when transferring funds, the private key components of multiple secret key service clients need to be signed together to complete the transaction, which ensures the security of digital currency transactions.

On the basis of the foregoing embodiment, in an embodiment of this specification, the second private key component includes a first private key fragment and a second private key fragment;

Correspondingly, the said data to be signed is signed according to the first private key component saved by the first secret key service client and the second private key component saved by the second secret key service client to obtain Signature data, including:

Acquiring the first private key fragment, and sending the second private key fragment to the first secret key service client;

According to the first private key shard, pair with the first private key component stored in the first secret key service client and the second private key shard received by the first secret key service client The data to be signed is signed to obtain the signature data.

In the specific implementation process, the second secret key service client can split the second private key component stored by itself into the first private key fragment and the second private key fragment. The split of the secret key component can also be adopted The mode of addition and subtraction is not specifically limited in the embodiment of this specification. When the key management server receives the confirmation signature information returned by the second key service client, it can obtain the first private key fragments saved by the second key service client, and divide the second key management service client's second The private key fragments are sent to the first key service client. The key management server can use the obtained first private key fragment, combined with the first private key component and the second private key fragment saved by the first secret key service client to sign the signature data, obtain the signature data, and perform Transfer processing.

In an embodiment of this specification, a secure multi-party computing mpc may be used to sign the data to be signed to obtain the signature data. mpc is mainly aimed at the problem of how to safely calculate an agreed function without a trusted third party. The mpc can include multiple parties that hold their own private data to jointly execute a calculation logic (eg, maximum calculation) and obtain the calculation result, but in the process, each party participating in the calculation will not leak their data.

In an embodiment of this specification, the MPC calculation is generally two parties participating. When using the MPC calculation to sign data, the key management server can provide the acquired second secret key service client's first private key fragment and For the data to be signed, the first private key component saved by the first secret key service client, the second private key fragments saved by the second secret key service client obtained, and the data to be signed are provided to ensure the signature data safety.

For example: the first secret key service client stores the private key component sk1 of the transaction account, the second secret key service client stores the private key component sk2 of the transaction account, and the second secret key service client splits sk2 into The first private key fragment sk2-1 and the second private key fragment sk2-2. When performing digital currency transactions, after receiving the confirmation signature information returned by the second secret key service client, the secret key management server can obtain the first private key of the second secret key service client to slice sk2-1 and divide the second The second private key fragment sk2-2 of the key service client is sent to the first key service client. The first secret key service client and the secret key management server can use mpc to sign the data to be signed. During the signature calculation, the secret key management server can provide data including: sk2-1 and the data to be signed, the first secret key service The data that the client can provide includes: sk1, sk2-2, and data to be signed. Among them, sk1+sk2-1+sk2-2=the private key of the transaction account, which realizes the signature confirmation transfer of the transaction account.

In the embodiment of this specification, the private key component of the second secret key service client is split into two parts, one part is sent to the secret key management server, and the other part is sent to the first secret key service client. The secret key management server and the first The key service client uses the corresponding private key component to sign data. No party has obtained the complete private key of the transaction account, ensuring the security of the transaction. Moreover, compared with the prior art multi-signature relies on the characteristics of the underlying chain, different chains have different ways and increase the complexity of the code. The embodiment of this specification utilizes the signature transmission technology of the secret key management server kms, which can quickly realize the signature of the transaction data, the method is simple, and the data processing speed is improved.

On the basis of the foregoing embodiment, in an embodiment of this specification, the first private key component corresponds to a public key, and the second private key segment is encrypted using the public key corresponding to the first private key component;

Correspondingly, the sending the second private key fragments to the first secret key service client includes:

Receiving the signature confirmation information of the second secret key service client, and obtaining the first private key fragment and the encrypted second private key fragment;

The encrypted second private key fragments are sent to the first secret key service client, so that the first secret key service client uses the first private key component to decrypt to obtain the second private key Key fragmentation.

In the specific implementation process, the first private key component in the first secret key service client corresponds to a public key. The public key can be calculated based on the private key, and the second secret key service client can obtain the first secret key service client. The public key of the first private key component of the end. And use the public key to encrypt the second private key fragments. When the key management server receives the confirmation signature information returned by the second key service client, it can obtain the second private key component in the second key service client. However, due to the The second private key component is split into the first private key fragment and the second private key fragment, and the second private key fragment is encrypted with the public key of the private key component of the first secret key service client, and the secret key management server Only the first private key fragment in the second secret key service client can be obtained, and the encrypted second private key fragment cannot be decrypted. The key management server can send the encrypted second private key fragments to the first key service client, and the first key service client can use the first private key component stored by itself to perform the encrypted second private key. The key fragment is decrypted to obtain the second private key fragment of the second secret key service client. The secret key management server and the first secret key service client can use the private key component of the transaction account obtained or saved by each to sign the signature data and perform transaction processing.

In the embodiment of this specification, the private key component in the second secret key service client is split, and the split second private key is divided into the first private key component saved by the first secret key service client. The public key is encrypted. As a result, the key management server cannot obtain the complete private key component of the second key service client, and further cannot obtain the complete private key of the transaction account. During the entire signing process, no one party can obtain all the private keys of the transaction account, and the transaction process needs to be completed by multiple parties, which improves the security of digital currency transactions.

The various embodiments of the above methods in this specification are described in a progressive manner, and the steps indicate a strict sequence, and the sequence of the steps can be adjusted according to actual needs. The same and similar parts between the various embodiments can be mutually participated, and each embodiment focuses on the differences from other embodiments. Part of the description of the method embodiment can be used for relevant points.

Some embodiments of this specification also provide a digital currency transaction data processing method based on the first secret key service client. Figure 7 is a schematic flow diagram of the digital currency transaction data processing method in another embodiment of this specification, as shown in Figure 7. As shown, the flow of the digital currency transaction data processing method executed by the first secret key service client provided in the embodiment of this specification may include:

Step 702: Send transaction request data to the secret key management server, so that the secret key management server sends transaction request data to the second secret key service client, where the transaction request data includes data to be signed.

In the specific implementation process, the digital currency transaction data processing method in the embodiment of this specification can be executed in the first secret key service client, for example, it can be a user who conducts digital currency trading, digital currency financial management, and digital currency withdrawal Client, or the client of the administrator responsible for financial management in the exchange system. When a digital currency transaction is required, the first secret key service client can locally generate a transaction message according to the specific information of the digital currency transaction, hash the transaction message to obtain the data to be signed, and send it to the secret key management server Send transaction request data, the transaction request data includes the data to be signed. The key management server may send the transaction request data to the second key service client, so that the second key service client confirms whether to agree to the transfer.

In some embodiments of this specification, the transaction request data may include at least one of digital currency trading transaction request data, user withdrawal request data, cold wallet transfer request data, exchange withdrawal request data, and wealth management request data. That is, the digital currency transaction data processing method in the embodiment of this specification can be applied to a variety of digital currency transaction scenarios. When performing digital currency transactions, the user can send transaction request data to the secret key management server through the first secret key service client. , Such as: request data for buying digital currency, request data for selling digital currency, request data for user withdrawal, request data for exchange withdrawal, request data for cold wallet transfer or request data for buying wealth management products, etc.

It should be noted that the first secret key service client and the second secret key service client in the embodiment of this specification are both clients corresponding to users of both parties to the transaction, and the difference may lie in different specific functions. For details, reference may be made to the record in the foregoing embodiment, which will not be repeated here. For example, when conducting cold wallet transfers or exchange withdrawals, the first secret key service client can be understood as a client responsible for financial management and actively initiate transaction requests, and the second secret key service client can be understood as a transaction Clients of other administrators except the first key management client. Generally, the number of the first secret key service client is one, and the number of the second secret key service client may be one or more, which can be specifically set according to actual conditions, which is not specifically limited in the embodiment of this specification.

Step 704: Receive the second private key component saved by the second key service client and sent by the key management server.

When the key management server receives the confirmation signature information returned by the second key service client, the key management server can obtain the second private key component of the transaction account saved by the second key service client, and can transfer the second The private key component is sent to the first key service client.

In an embodiment of this specification, when the transaction account is created, the first secret key service client and the second secret key service client can respectively generate the corresponding private key components of the transaction account according to the private key of the transaction account. The private key component generated by the key service client can be called the first private key component, and the private key component generated by the second key service client private key component can be called the second private key component. The sum of the second private key components is the private key of the transaction account. The private key component can be generated by the algorithm of modular addition and subtraction, or generated in other ways, and the embodiment of this specification does not specifically limit it.

Step 706: Sign the data to be signed according to the first private key component stored by itself and the received second private key component to obtain signature data, wherein the first private key component and the second private key component The sum of the two private key components is the private key of the transaction account.

After the first key service client receives the second private key component saved by the second key service client sent by the key management server, it can use the first private key component stored by itself and the received second private key The component, together with the secret key management server, signs the data to be signed to obtain signature data. The signature data includes information such as the transaction amount.

Step 708: Perform transaction transfer processing according to the signature data.

After obtaining the signature data, the first secret key service client can perform cold wallet transfer processing based on the signature data. For example, the first secret key service client can send the signature data to the blockchain for transaction transfer processing. For the specific transfer processing method, please refer to the record in the foregoing embodiment, which will not be repeated here.

The digital currency transaction data processing method provided in the embodiment of this specification splits the private key of the transaction account into different private key components, which are respectively stored in the hands of different secret key service clients, that is, users. When digital currency transactions are required, after each secret key service client agrees to transfer, the private key component of the cold wallet stored by each secret key service client is used for signature calculation to obtain the signature data, and the transfer information can take effect. The sum of the private key components of the cold wallet stored by each secret key service client is the private key of the transaction account. The signature data is essentially obtained by signing the transaction account's private key to complete the signature transfer of the transaction account. By separately storing the private key components of the transaction account, when transferring funds, the private key components of multiple secret key service clients need to be signed together to complete the transaction, ensuring the security of the transaction.

On the basis of the above-mentioned embodiment, in an embodiment of this specification, the second private key component includes: a first private key fragment, a second private key fragment, and the second private key fragment uses the first private key fragment. A public key corresponding to a private key component is encrypted;

Correspondingly, the receiving the second private key component saved by the second key service client sent by the key management server includes:

Receive the encrypted second private key segment sent by the key management server, and use the first private key component to decrypt the encrypted second private key segment to obtain the second private key Fragmentation;

Correspondingly, the signing the data to be signed to obtain the signature data includes:

Sign the data to be signed according to the first private key component, the obtained second private key fragment, and the first private key fragment obtained by the key management server to obtain signature data.

In the specific implementation process, the second secret key service client can split the second private key component stored by itself into the first private key fragment and the second private key fragment. The split of the secret key component can also be adopted The mode of addition and subtraction is not specifically limited in the embodiment of this specification. The first private key component in the first secret key service client corresponds to a public key, and the public key can be calculated based on the private key. The second secret key service client may obtain the public key of the first private key component of the first secret key service client to encrypt the second private key segment.

When receiving the confirmation signature information returned by the second secret key service client, the secret key management server may obtain the second private key component in the second secret key service client. However, since the private key component in the second secret key service client is split into the first private key fragment and the second private key fragment, and the second private key fragment uses the first private key of the first secret key service client The public key of the key component is encrypted, and the key management server can only obtain the first private key fragment in the second secret key service client, and cannot decrypt the encrypted second private key fragment. The key management server can send the encrypted second private key fragments to the first key service client, and the first key service client can use its own first private key component to encrypt the second private key The fragments are decrypted to obtain the second private key fragments of the second secret key service client. The secret key management server and the first secret key service client can use the private key components obtained or saved respectively to sign the data to be signed, and then perform transaction processing.

In an embodiment of this specification, secure multi-party computing mpc may be used to sign the data to be signed to obtain the signature data. In an embodiment of this specification, the MPC calculation is generally two parties participating. When using the MPC calculation to sign data, the key management server can provide the acquired second secret key service client's first private key fragment and For the data to be signed, the first private key component saved by the first secret key service client, the second private key fragments saved by the second secret key service client obtained, and the data to be signed are provided to ensure the signature data safety.

For example: the first secret key service client stores the first private key component sk1 of the transaction account, the second secret key service client stores the private key component sk2 of the transaction account, and the second secret key service client splits sk2 It becomes the first private key segment sk2-1 and the second private key segment sk2-2, where the second private key segment sk2-2 is encrypted using the public key pk1 of the first private key component sk1. When performing digital currency transactions, after receiving the confirmation signature information returned by the second secret key service client, the secret key management server can obtain the first private key of the second secret key service client to slice sk2-1 and divide the second The encrypted second private key segment sk2-2 of the key service client is sent to the first key service client. The first key service client can use sk1 to decrypt the encrypted sk2-2 to obtain sk2-2. The first secret key service client and secret key management server can use mpc to perform signature calculation on the data to be signed. When performing signature calculation, the key management server can provide data including: sk2-1 and the data to be signed, the first secret key The data that the service client can provide includes: sk1, sk2-2, and data to be signed. Among them, sk1+sk2-1+sk2-2=the private key of the transaction account, which realizes the signature confirmation of the transaction account, and can further process the transaction transfer according to the signature data.

In the embodiment of this specification, the private key component in the second secret key service client is split, and the split second private key fragments are encrypted with the public key of the private key component of the first secret key service client . As a result, the key management server cannot obtain the complete private key component of the second key service client, and further cannot obtain the complete private key of the transaction account. During the entire signing process, no one party can obtain all the private keys of the transaction account, and the transaction process needs to be completed by multiple parties, which improves the security of the transaction.

On the basis of the foregoing embodiment, in an embodiment of this specification, the method for generating the first private key component and the second private key component may include:

If the transaction request data is the digital currency transaction request data or the user withdrawal request data or the wealth management request data, when the user account is created, the private key corresponding to the user account will be The second secret key service client generates respective first private key components and second private key components;

If the transaction request data is the cold wallet transfer request data or the exchange currency withdrawal request data, when the exchange account is created, according to the private key of the exchange account, serve the customer with the second secret key The terminals respectively generate their first private key component and second private key component.

In the specific implementation process, the first private key component and the second private key component can be generated when the transaction account is created. For example, when the user account is created, the first secret key service client and the second secret key service client can The first private key component and the second private key component are generated according to the private key corresponding to the user account. The sum of the first private key component and the second private key component may be the private key corresponding to the user account. The private key component can be generated by the algorithm of modular addition and subtraction of the private key of the user account to generate the private key component, or it can be generated in other ways, which is not specifically limited in the embodiment of this specification. Wherein, the first secret key service client may be a client corresponding to the user and store the first private key component, and the second secret key service client may be an exchange client and store the second private key component. When a user needs to conduct transactions such as buying, selling, and withdrawing digital currency, the user and the exchange are required to jointly sign and confirm before the transaction can be transferred, which improves the security of user assets.

When the user's financial account is created, the first secret key service client and the second secret key service client can use the same method to generate the first private key component and the second private key component. The sum of the first private key component and the second private key component may be the private key corresponding to the wealth management account. At this time, the first secret key service client may refer to the client of a wealth management user who needs to conduct financial management, and the second secret key service client may refer to the client of an asset management party that is an institution that conducts asset management. When a user needs to make a financial investment, both the financial user and the asset party need to agree, that is, the first secret key service client and the second secret key service client jointly sign and confirm, then the transaction transfer can be processed, which improves the exchange asset safety.

When the cold wallet of the exchange is created, the first secret key service client and the second secret key service client can use the same method to generate the first private key component and the second private key component. The sum of the first private key component and the second private key component may be the private key corresponding to the cold wallet. At this time, the first key service client can represent the client corresponding to the financial administrator of the exchange, the second key service client can represent the clients of other administrators, and the second key service client can have Multiple such as: clients corresponding to all shareholders of the exchange. When it is necessary to transfer from a cold wallet to a hot wallet, all administrators who have the private key component of the cold wallet must agree, that is, the first secret key service client and the second secret key service client jointly sign and confirm it before proceeding. Transaction transfer processing improves the security of user investment and financial management.

Similarly, when the exchange account is created, the first secret key service client and the second secret key service client can use the same method to generate the first private key component and the second private key component. The sum of the first private key component and the second private key component may be the private key corresponding to the exchange account. At this time, the first key service client can represent the client of the exchange system or the financial administrator of the exchange or other designated administrators, and the second key service client can represent the clients of other administrators, and The second secret key service client can have multiple clients, such as clients corresponding to all shareholders of the exchange. When it is necessary to withdraw money from the exchange, all administrators who have the private key component of the exchange account must agree, that is, the first secret key service client and the second secret key service client jointly sign and confirm before the transaction can be carried out. Transfer processing improves the security of exchange assets.

Some embodiments of this specification also provide a digital currency transaction data processing method based on a second secret key service client. FIG. 8 is a schematic flowchart of a digital currency transaction data processing method in another embodiment of this specification, as shown in FIG. 8 As shown, the process of the digital currency transaction data processing method executed by the second secret key service client provided in the embodiment of this specification may include:

Step 802: Receive transaction request data sent by the key management server, where the transaction request data is sent by the first key service client, and the transaction request data includes data to be signed.

In the specific implementation process, the digital currency transaction data processing method in the embodiment of this specification can be executed in the second secret key service client, for example, it can be the exchange system, the client corresponding to the asset manager, and the exchange’s The client corresponding to the administrator, etc. When a digital currency transaction is required, the first secret key service client can generate a transaction message locally according to the specific information of the digital currency transaction, hash the transaction message to obtain the data to be signed, and send it to the secret key management server Send transaction request data, the transaction request data includes the data to be signed. The key management server can send the transaction request data to the second key service client, and the second key service client can receive the transaction request data sent by the key management server.

In some embodiments of this specification, the transaction request data may include at least one of digital currency trading transaction request data, user withdrawal request data, cold wallet transfer request data, exchange withdrawal request data, and wealth management request data. That is, the digital currency transaction data processing method in the embodiment of this specification can be applied to a variety of digital currency transaction scenarios. When performing digital currency transactions, the user can send transaction request data to the secret key management server through the first secret key service client. , Such as: request data for buying digital currency, request data for selling digital currency, request data for user withdrawal, request data for exchange withdrawal, request data for cold wallet transfer or request data for buying wealth management products, etc. For the specific meaning of the transaction request data, reference may be made to the record in the foregoing embodiment, which will not be repeated here.

Step 804: Return the confirmation signature information to the key management server, and send the second private key component saved by itself to the key management server, so that the key management server and the first key service The client signs the data to be signed according to the second private key component and the first private key component saved by the first secret key service client to obtain signature data, which is served by the first secret key The client terminal performs transaction transfer processing according to the signature data;

In the specific implementation process, after the second secret key service client receives the transaction request data sent by the secret key management server, it can judge whether the transaction request is passed, that is, whether the transaction is completed, if the transaction is completed, it can report to the key management The server returns confirmation signature information. After the second key service client confirms the signature, it can send the second private key component saved by itself to the key management server, and the key management server can obtain the second private key component of the transaction account saved by the second key service client , And can send the second private key component to the first key service client.

On the basis of the above-mentioned embodiments, some embodiments of this specification provide methods for generating private key components. The methods for generating the first private key component and the second private key component may include:

If the transaction request data is the digital currency transaction request data or the user withdrawal request data or the wealth management request data, when the user account is created, the private key corresponding to the user account will be The first secret key service client generates respective second private key components and first private key components;

If the transaction request data is the cold wallet transfer request data or the exchange currency withdrawal request data, when the exchange account is created, according to the private key of the exchange account, serve the customer with the first secret key The terminals respectively generate their second private key component and first private key component.

In the specific implementation process, according to the private key of the transaction account, the first secret key service client and the second secret key service client can respectively generate the private key components of the corresponding transaction account when the transaction account is created. The private key component generated by the key service client can be called the first private key component, and the private key component generated by the second key service client private key component can be called the second private key component. The sum of the second private key components is the private key of the transaction account. For the specific creation process of the private key component, reference may be made to the record in the foregoing embodiment, which will not be repeated here. For example, the private key component can be generated through the algorithm of modular addition and subtraction, or generated in other ways, which is not specifically limited in the embodiment of this specification.

On the basis of the foregoing embodiment, in an embodiment of this specification, the sending the first private key component stored by itself to the secret key management server includes:

Split the second private key component into a first private key fragment and a second private key fragment, and encrypt the second private key fragment by using a public key corresponding to the first private key component;

Sending the first private key fragment and the encrypted second private key fragment to the secret key management server;

Correspondingly, the secret key management server and the first secret key service client perform the signature on the to-be-signed according to the second private key component and the first private key component stored by the first secret key service client Data is signed, including:

The key management server sends the encrypted second private key fragments to the first key service client;

The first secret key service client uses the first private key component to decrypt the encrypted second private key fragment to obtain the second private key fragment;

Based on the first private key fragment, the first private key component, and the second private key fragment, the key management server and the first key service client use secure multi-party computing to compare the data to be signed Sign and obtain the signature data.

When the key management server receives the confirmation signature information returned by the second key service client, it can obtain the second private key component in the second key service client, and send the second private key component to the first signature Service client. The key management server and the first key service client can use the private key components obtained or saved by each to sign the data to be signed, and then perform transaction processing. For the specific signature calculation process, please refer to the record in the above-mentioned embodiment. Repeat.

In the embodiment of this specification, the second private key component is split in the second secret key service client, and the split second private key is divided into pieces using the public key of the private key component of the first secret key service client. encryption. As a result, the key management server cannot obtain the complete private key component of the second key service client, and further cannot obtain the complete private key of the transaction account. During the entire signing process, no one party can obtain all the private keys of the transaction account, and the transaction process needs to be completed by multiple parties, which improves the security of the transaction.

Figure 9 is a schematic diagram of the data processing flow of the exchange’s cold wallet transfer to the hot wallet in an embodiment of this specification. The numbers on the lines in the figure can indicate the steps of the cold wallet transfer, as shown in Figure 9, when you create it with reference to Figure 4 above After the cold wallet of the exchange, the process of transferring the cold wallet of the exchange in an embodiment of this specification may include:

1. Administrator 1 generates transaction messages locally through the first secret key service client, hashes the transaction messages to obtain the data to be signed, and calls kms to initiate the signature interface. The parameter is pk1 (pk1 is the administrator The public key corresponding to the first private key component of the cold wallet stored in 1) + data to be signed.

2. The administrator 2 can query the data to be signed through the second secret key service client.

3. After administrator 2 agrees, split sk2 (sk2 represents the second private key component of the cold wallet saved by administrator 2) into 2 parts sk2=sk2-1+sk2-2 (sk2-2 is encrypted by pk1), Call the signature confirmation interface of kms.

4. The administrator 1 obtains the partial private key fragment sk2-2 of the administrator 2 through kms, and decrypts it with sk1 (sk1 represents the first private key component of the cold wallet saved by the administrator 1).

5. Administrator 1 and kms do an MPC calculation to generate signature data. Administrator 1 provides sk1+sk2-2+ data to be signed, and kms provides sk2-1+ data to be signed.

6. The administrator 1 sends the data to be signed to the blockchain to perform the transfer.

It should be noted that in practical applications, there can be multiple administrators 2. When there are multiple administrators 2, all administrators store the private key component of the cold wallet, and the private key components of all administrators And is the private key of the cold wallet.

Keep the private key of the cold wallet in multiple people. When transferring money, multiple people need to sign together to complete the transaction, which ensures the security of exchange assets. Moreover, the traditional multi-signature depends on the characteristics of the underlying chain, different ways of different chains, and increased code complexity. The signature method in the embodiment of this specification is simple and easy to use.

Figure 10 is a schematic diagram of the data processing flow of digital currency buying or digital currency selling or user withdrawal in the embodiment of this specification. The numbers on the lines in the figure can indicate the steps of the transaction. Refer to Figure 1 or Figure 3 above. After the transaction is completed or the digital currency withdrawal submitted by the user is approved, as shown in Figure 10, the following methods can be used to perform digital currency transaction transfers:

1. The user generates the transaction message locally through the first secret key service client, hashes the transaction message to obtain the data to be signed, and calls the interface of kms to initiate the signature. The parameter is pk1 (pk1 is the saved in the user The public key corresponding to the first private key component of the user account) + data to be signed.

Among them, the user may be a user who purchases digital currency. At this time, the transaction message submitted by the user may be a digital currency purchase order commission. The user can also be a user who sells digital currency. At this time, the transaction message submitted by the user can be a digital currency sell order commission. The user may also be a user who performs digital currency withdrawal. At this time, the transaction message data submitted by the user may be a withdrawal request.

That is, the client corresponding to the buying user stores the first private key component of the buying user account, the client corresponding to the selling user stores the first private key component of the selling user, and the second secret key service client is the exchange The second private key component for buying the user account and the second private key component for selling the user account are stored.

2. The exchange can query the data to be signed through the second secret key service client.

3. After the exchange agrees, split sk2 (sk2 represents the second private key component of the cold wallet saved by the exchange) into 2 parts sk2=sk2-1+sk2-2 (sk2-2 is encrypted by pk1), call kms The signature confirmation interface.

4. The user obtains partial private key fragments sk2-2 of the exchange through kms, and decrypts them with sk1 (sk1 represents the first private key component of the cold wallet saved by the user).

5. The user and kms do an MPC calculation to generate signature data. The user provides sk1+sk2-2+ data to be signed, and kms provides sk2-1+ data to be signed.

6. The user sends the data to be signed to the blockchain to perform the transfer. The client corresponding to the buying user or the client corresponding to the selling user performs transaction transfer processing according to the signature data.

It should be noted that the method for generating the first private key component and the second private key component can be generated with reference to the above-mentioned methods of FIG. 4 and FIG. 5 when the user account is created.

The user and the exchange each hold a private key component. When withdrawing coins or buying and selling digital currencies, the operation of the account requires two people to complete together, ensuring the security of user assets.

Figure 11 is a schematic diagram of the digital currency investment management data processing flow diagram in an embodiment of this specification. The numbers on the lines in the figure can indicate the steps of digital currency investment management. As shown in Figure 11, when referring to Figure 5 above, a wealth management account is created Later, the data processing process for users buying wealth management products can refer to the following:

1. Wealth management users generate transaction messages locally through the first secret key service client, hash the transaction messages to obtain the data to be signed, call kms to initiate the signature interface, the parameter is pk1 (pk1 is the wealth management user The public key corresponding to the first private key component of the saved wealth management account) + data to be signed.

2. The asset management party can query the data to be signed through the second secret key service client.

3. After the asset manager agrees, split sk2 (sk2 represents the second private key component of the cold wallet stored by the asset manager) into 2 parts sk2=sk2-1+sk2-2 (sk2-2 is encrypted by pk1), Call the signature confirmation interface of kms.

4. The wealth management user obtains part of the exchange's private key fragment sk2-2 through kms, and decrypts it with sk1 (sk1 represents the first private key component of the cold wallet saved by the wealth management user).

5. Wealth management users and kms do an MPC calculation to generate signature data. Wealth management users provide sk1+sk2-2+ data to be signed, and kms provides sk2-1+ data to be signed.

6. The user sends the data to be signed to the blockchain to perform the transfer.

The wealth management user and the asset management party each hold a private key component, and the user's purchase of the wealth management product requires two individuals to complete it, ensuring the security of the user's assets. In addition, user assets are stored on the chain, so it is safe and account flow is transparent, ensuring the transparency of the use of user assets.

Figure 12 is a schematic diagram of the data processing flow of digital currency withdrawals performed by the exchange in an embodiment of this specification. The numbers on the lines in the figure can indicate the steps of the exchange withdrawing coins. As shown in Figure 12, when referring to the above figure 3, the transaction After the submitted withdrawal application is approved, the data processing process of the exchange withdrawal can be referred to as follows:

1. After the withdrawal is approved, the exchange will generate transaction messages locally through the first secret key service client, hash the transaction messages to obtain the data to be signed, call kms to initiate the signature interface, the parameter is pk1 (pk1 is the public key corresponding to the first private key component of the cold wallet saved in the administrator 1) + data to be signed. An exchange can represent an exchange system or an exchange platform, and can be managed by an administrator of the exchange.

2. The administrator can query the data to be signed through the second secret key service client.

3. After the administrator agrees, split sk2 (sk2 represents the second private key component of the cold wallet saved by the administrator) into 2 parts sk2=sk2-1+sk2-2 (sk2-2 is encrypted by pk1), call kms The signature confirmation interface.

4. The exchange obtains partial private key sk2-2 of the administrator through kms, and decrypts it with sk1 (sk1 represents the first private key component of the exchange account saved by the exchange).

5. The exchange and kms do an MPC calculation to generate signature data. The exchange provides sk1+sk2-2+ data to be signed, and kms provides sk2-1+ data to be signed.

6. The exchange sends the data to be signed to the blockchain to perform the transfer.

It should be noted that in practical applications, there can be multiple administrators. When there are multiple administrators, all administrators and exchanges store the private key component of the exchange account, and the private keys of all administrators The sum of the weights is the private key of the exchange account.

The private key of the exchange account is stored in multiple managers. When transferring funds, multiple people need to sign together to complete the transaction, ensuring the security of the exchange's assets.

It should be noted that the signature calculation process in the embodiments of this specification uses mpc calculation. The mpc calculation method can be integrated in the key management server or the first key service client, or it can be integrated in the signature calculation module separately. The embodiments are not specifically limited.

Based on the digital currency transaction data processing method described above, one or more embodiments of this specification also provide a digital currency transaction data processing server, a digital currency transaction data processing client, and a digital currency transaction data processing terminal. The servers, clients, and terminals may include systems (including distributed systems), software (applications), modules, components, servers, clients, etc. that use the methods described in the embodiments of this specification, combined with necessary implementation hardware Device. Based on the same innovative concept, the server in one or more embodiments provided in the embodiments of this specification is as described in the following embodiments. Since the implementation scheme and method of the server to solve the problem are similar, the specific implementation of the server, client, and terminal in the embodiment of this specification can participate in the implementation of the foregoing method, and the repetition will not be repeated. As used below, the term "unit" or "module" can be a combination of software and/or hardware that implements predetermined functions. Although the devices described in the following embodiments are preferably implemented by software, hardware or a combination of software and hardware is also possible and conceived.

Specifically, FIG. 13 is a schematic diagram of the module structure of an embodiment of the digital currency transaction data processing server provided in this specification. As shown in FIG. 13, the digital currency transaction data processing server provided in this specification can be understood as the secret in the above embodiment. The key management server may include: a transaction request receiving module 131, a signature data forwarding module 132, a first signature module 133, and a first transfer processing module 134, where:

The transaction request receiving module 131 may be used to receive transaction request data sent by the first secret key service client, where the transaction request data includes data to be signed;

The signed data forwarding module 132 may be used to send the data to be signed to the second secret key service client;

The first signature module 133 may be used to perform a signature on the data to be signed according to the first private key component stored by the first secret key service client and the second private key component stored by the second secret key service client. Sign to obtain signature data, wherein the sum of the first private key component and the second private key component is the private key of the transaction account;

The first transfer processing module 134 may be configured to send the signature data to the first secret key service client, so that the first secret key service client performs transaction transfer processing.

The digital currency transaction data processing server provided by the embodiment of this specification splits the private key of the transaction account into different private key components, which are respectively stored in the hands of different secret key service clients corresponding to the digital currency transaction, that is, different users. When a digital currency transaction is required, after each secret key service client agrees to the transaction transfer, the private key component saved by each secret key service client is used for signature calculation to obtain the signature data, and the transfer information can take effect. The sum of the private key components saved by each secret key service client is the private key of the transaction account. The signature data is essentially obtained by signing with the private key of the transaction account to complete the signature transfer of the transaction account. By separately storing the private key components of the transaction account, when transferring funds, the private key components of multiple secret key service clients are required to sign together to complete the transaction, ensuring the security of digital currency transactions.

On the basis of the foregoing embodiment, the second private key component includes a first private key fragment and a second private key fragment;

Correspondingly, the first signature module is specifically used for:

The digital currency transaction data processing server provided by the embodiment of this specification splits the private key component of the second secret key service client into two parts, one part is sent to the secret key management server, and the other part is sent to the first secret key service client. The key management server and the first key service client use the corresponding private key component to sign data. No party has obtained the complete private key of the transaction account, ensuring the security of the transaction. Moreover, compared with the prior art multi-signature relies on the characteristics of the underlying chain, different chains have different ways and increase the complexity of the code. The embodiment of this specification utilizes the signature transmission technology of the secret key management server kms, which can quickly realize the signature of the transaction data, the method is simple, and the data processing speed is improved.

On the basis of the foregoing embodiment, the first private key component corresponds to a public key, and the second private key segment is encrypted using the public key corresponding to the first private key component;

Correspondingly, the first signature module is specifically used for:

The digital currency transaction data processing server provided by the embodiment of this specification splits the private key component in the second secret key service client, and uses the first secret key service client to slice the split second private key The public key of the stored first private key component is encrypted. As a result, the key management server cannot obtain the complete private key component of the second key service client, and further cannot obtain the complete private key of the transaction account. During the entire signing process, no one party can obtain all the private keys of the transaction account, and the transaction process needs to be completed by multiple parties, which improves the security of digital currency transactions.

On the basis of the foregoing embodiment, the first signature module is specifically configured to:

According to the first private key component and the second private key component, and the first secret key service client, use secure multi-party computing to sign the data to be signed to obtain the signature data.

The digital currency transaction data processing server provided by the embodiment of this specification separately stores the private key components of the transaction account in different clients, and uses multi-party secure calculation to perform signature calculation to ensure the security of the signature data.

On the basis of the foregoing embodiment, the transaction request data received by the transaction request receiving module includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, exchange withdrawal request data, At least one of financial request data.

The digital currency transaction data processing server provided in the embodiments of this specification provides security guarantees for digital currency transactions in different scenarios, and ensures the security of user assets or exchange assets.

It should be noted that the foregoing server may also include other implementation manners according to the description of the method embodiment. For a specific implementation manner, reference may be made to the description of the method embodiment executed by the key manager, which will not be repeated here.

The embodiment of this specification also provides a digital currency transaction data processing client, that is, the first secret key service client in the above embodiment. FIG. 14 is a schematic diagram of the structure of the digital currency transaction data processing client in the embodiment of this specification. As shown in FIG. 14, the digital currency transaction data processing client in the embodiment of this specification can execute the data processing process corresponding to the first secret key service client in the above embodiment, and may include: a transaction request sending module 141, a secret key receiving module 142. The second signature module 143 and the second transfer processing module 144, wherein:

The transaction request sending module 141 may be used to send transaction request data to the secret key management server, so that the secret key management server sends transaction request data to the second secret key service client, where the transaction request data includes data to be signed;

The secret key receiving module 142 may be configured to receive the second private key component saved by the second secret key service client and sent by the secret key management server;

The second signature module 143 can be used to sign the data to be signed according to the first private key component stored by itself and the received second private key component to obtain signature data, wherein the first private key component The sum of the key component and the second private key component is the private key of the transaction account;

The second transfer processing module 144 may be used to perform transaction transfer processing according to the signature data.

The digital currency transaction data processing client provided by the embodiment of this specification splits the private key of the transaction account into different private key components, which are respectively stored in the hands of different secret key service clients, that is, the user. When digital currency transactions are required, after each secret key service client agrees to transfer, the private key component of the cold wallet stored by each secret key service client is used for signature calculation to obtain the signature data, and the transfer information can take effect. The sum of the private key components of the cold wallet stored by each secret key service client is the private key of the transaction account. The signature data is essentially obtained by signing the transaction account's private key to complete the signature transfer of the transaction account. By separately storing the private key components of the transaction account, when transferring funds, the private key components of multiple secret key service clients need to be signed together to complete the transaction, ensuring the security of the transaction.

Correspondingly, the secret key receiving module is specifically used for:

Correspondingly, the second signature module is specifically used for:

The digital currency transaction data processing client provided by the embodiment of this specification splits the private key component in the second secret key service client, and uses the split second private key to serve the client with the first secret key. The public key of the private key component of the end is encrypted. As a result, the key management server cannot obtain the complete private key component of the second key service client, and further cannot obtain the complete private key of the transaction account. During the entire signing process, no one party can obtain all the private keys of the transaction account, and the transaction process needs to be completed by multiple parties, which improves the security of the transaction.

On the basis of the foregoing embodiment, in an embodiment of this specification, the second signature module is specifically used for:

According to the first private key component and the second private key component, and the key management server, use secure multi-party computing to sign the data to be signed to obtain the signature data.

The digital currency transaction data processing client provided by the embodiment of this specification separately stores the private key components of the transaction account in different clients, and uses multi-party secure calculation to perform signature calculation to ensure the security of the signature data.

On the basis of the above-mentioned embodiment, in an embodiment of this specification, the transaction request data sent by the transaction request sending module includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, transaction At least one of the withdrawal request data and the financial management request data.

The digital currency transaction data processing client provided in the embodiments of this specification provides security guarantees for digital currency transactions in different scenarios, and ensures the security of user assets or exchange assets.

On the basis of the foregoing embodiment, in an embodiment of this specification, the client further includes a first private key component generating module, configured to:

In the digital currency transaction data processing client provided by the embodiment of this specification, when a transaction account is created, multiple private key components are generated according to the private key of the transaction account. The private key components are stored by multiple users, which provides a secure transaction for subsequent digital currency transactions. Data basis.

It should be noted that the foregoing description of the client according to the method embodiment may also include other implementation manners. For the specific implementation manner, refer to the description of the method embodiment executed by the first secret key service client, which will not be repeated here.

The embodiment of this specification also provides a digital currency transaction data processing terminal, that is, the second secret key service client in the above embodiment. FIG. 15 is a schematic diagram of the structure of the digital currency transaction data processing terminal in the embodiment of this specification, as shown in FIG. As shown in 15, the digital currency transaction data processing terminal in the embodiment of this specification can execute the data processing process corresponding to the second secret key service client in the above embodiment, and can include: a transaction request query module 151 and a signature confirmation module 152. :

The transaction request query module 151 may be used to receive transaction request data sent by the key management server, the transaction request data being sent by the first key service client, and the transaction request data including data to be signed;

The signature confirmation module 152 may be used to return confirmation signature information to the key management server, and send the second private key component stored by itself to the key management server, so that the secret key management server and the The first secret key service client signs the data to be signed according to the second private key component and the first private key component saved by the first secret key service client to obtain the signature data, and the The first secret key service client performs transaction transfer processing according to the signature data;

The digital currency transaction data processing terminal provided by the embodiment of this specification splits the private key of the transaction account into different private key components, which are respectively stored in the hands of different secret key service clients, that is, users. When digital currency transactions are required, after each secret key service client agrees to transfer, the private key component of the cold wallet stored by each secret key service client is used for signature calculation to obtain the signature data, and the transfer information can take effect. The sum of the private key components of the cold wallet stored by each secret key service client is the private key of the transaction account. The signature data is essentially obtained by signing the transaction account's private key to complete the signature transfer of the transaction account. By separately storing the private key components of the transaction account, when transferring funds, the private key components of multiple secret key service clients need to be signed together to complete the transaction, ensuring the security of the transaction.

On the basis of the foregoing embodiment, in an embodiment of this specification, the signature confirmation module is specifically used for:

In the digital currency transaction data processing terminal provided by the embodiment of this specification, the second private key component is split in the second secret key service client, and the split second private key is used to serve the client with the first secret key. The public key of the private key component of the end is encrypted. As a result, the key management server cannot obtain the complete private key component of the second key service client, and further cannot obtain the complete private key of the transaction account. During the entire signing process, no one party can obtain all the private keys of the transaction account, and the transaction process needs to be completed by multiple parties, which improves the security of the transaction.

Based on the foregoing embodiment, in an embodiment of this specification, the transaction request data received by the transaction request query module includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, At least one of exchange withdrawal request data and wealth management request data.

The digital currency transaction data processing terminal provided in the embodiments of this specification provides security guarantees for digital currency transactions in different scenarios, and ensures the security of user assets or exchange assets.

On the basis of the foregoing embodiment, in an embodiment of this specification, the terminal further includes a second private key component generating module, configured to:

The digital currency transaction data processing terminal provided by the embodiment of this specification generates multiple private key components according to the private key of the transaction account during transaction account creation. The private key components are stored by multiple users and provide data for subsequent secure transactions of digital currency basis.

It should be noted that the foregoing terminal may also include other implementation manners according to the description of the method embodiment. For the specific implementation manner, reference may be made to the description of the method embodiment executed by the second secret key service client, which is not repeated here.

The embodiment of the present specification also provides a digital currency transaction data processing device, including: at least one processor and a memory for storing processor-executable instructions, and the processor implements the digital currency transaction of the foregoing embodiment when the processor executes the instructions Data processing methods, such as:

Sending the data to be signed to the second secret key service client;

or,

Perform transaction transfer processing according to the signature data.

or,

On the basis of the above-mentioned embodiment, an embodiment of this specification may also provide a computer-readable storage medium on which computer instructions are stored, which when executed, realize the digital currency transaction data processing method of the above-mentioned embodiment, such as :

Sending the data to be signed to the second secret key service client;

or,

Perform transaction transfer processing according to the signature data.

or,

The storage medium may include a physical device for storing information, and usually the information is digitized and then stored in an electric, magnetic, or optical medium. The storage medium may include: devices that use electrical energy to store information, such as various types of memory, such as RAM, ROM, etc.; devices that use magnetic energy to store information, such as hard disks, floppy disks, magnetic tapes, magnetic core memory, bubble memory, U disk; a device that uses optical means to store information, such as CD or DVD. Of course, there are other ways of readable storage media, such as quantum memory, graphene memory, and so on.

It should be noted that the above-mentioned processing device and computer-readable storage medium may further include other implementation manners according to the description of the method embodiment. For specific implementation manners, reference may be made to the description of the related method embodiments, which will not be repeated here.

On the basis of the foregoing embodiment, an embodiment of this specification may also provide a digital currency transaction data processing system, which may include: a secret key management server, a first secret key service client, and a second secret key service client;

The digital currency transaction data processing system is used to perform at least one of the buying and selling of digital currency, the withdrawal of digital currency, the cold wallet transfer of digital currency in the exchange system, and the investment management of digital currency. The secret key The management server, the first secret key service client, and the second secret key service client execute the corresponding methods in the foregoing embodiments.

As shown in Figures 9-12, when the digital currency transaction data processing system in the embodiment of this specification performs digital currency transactions in different scenarios, the first secret key service client and the second secret key service client correspond to different Terminal, such as:

If the digital currency transaction data processing system is used for buying and selling digital currency, the first secret key service client is a buyer user transaction client or a seller user transaction client, and the second secret key service The client is the exchange client, that is, the exchange.

If the digital currency transaction data processing system is used to withdraw digital currency, the first secret key service client is a withdrawal user client, and the second secret key service client is an exchange client. Wherein, if the withdrawal of the digital currency is an exchange withdrawal, the first secret key service client may be the client where the administrator responsible for submitting the withdrawal application in the exchange is located, and the second secret key serves the customer The client includes one or more, which can be the client corresponding to other administrators in the exchange. If the user withdraws coins, the first secret key service client may be the client corresponding to the user who submitted the withdrawal application, and the second secret key service client is the exchange.

If the digital currency transaction data processing system is used for cold wallet transfer of digital currency of the exchange system, the first secret key service client and the second secret key service client are both exchange clients, that is, the transaction The client corresponding to the administrator, wherein the second secret key service client includes one or more.

For clients corresponding to different application scenarios, reference may be made to the records in the foregoing embodiment, which will not be repeated here.

The method embodiments provided in the embodiments of this specification can be executed in a mobile terminal, a computer terminal, a server or a similar computing device. Take running on a server as an example. Figure 16 is a hardware structural block diagram of the server applying the digital currency transaction data processing method in the embodiment of this specification. Figure 16 can show the structural block diagram of the secret key management server or the first secret key service. The structure diagram of the client and the second key service client. As shown in FIG. 16, the server 10 may include one or more (only one is shown in the figure) processor 100 (the processor 100 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), The memory 200 for storing data, and the transmission module 300 for communication functions. Those of ordinary skill in the art can understand that the structure shown in FIG. 16 is only for illustration, and it does not limit the structure of the above electronic device. For example, the server 10 may also include more or fewer components than those shown in FIG. 16, for example, may also include other processing hardware, such as a database or multi-level cache, GPU, or have a configuration different from that shown in FIG.

The memory 200 can be used to store software programs and modules of application software, such as the program instructions/modules corresponding to the digital currency transaction data processing method in the embodiment of this specification. The processor 100 runs the software programs and modules stored in the memory 200, thereby Perform various functional applications and data processing. The memory 200 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 200 may further include a memory remotely provided with respect to the processor 100, and these remote memories may be connected to a computer terminal through a network. Examples of the aforementioned networks include but are not limited to the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission module 300 is used to receive or send data via a network. The foregoing specific examples of the network may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission module 300 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station to communicate with the Internet. In an example, the transmission module 300 may be a radio frequency (RF) module, which is used to communicate with the Internet in a wireless manner.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

The methods or devices described in the above-mentioned embodiments provided in this specification can implement business logic through computer programs and are recorded on a storage medium, and the storage medium can be read and executed by a computer to achieve the effects of the solutions described in the embodiments of this specification.

The above-mentioned digital currency transaction data processing method or device provided by the embodiments of this specification can be implemented in a computer by a processor executing corresponding program instructions, such as using the c++ language of the windows operating system on the PC side, linux system implementation, or other examples Use android, iOS system programming language to realize in intelligent terminal, and realize the processing logic based on quantum computer, etc.

It should be noted that the device, computer storage medium, and system described above in the specification may also include other implementation manners according to the description of the related method embodiments. For specific implementation manners, please refer to the description of the corresponding method embodiments, which will not be repeated here. .

The various embodiments in this specification are described in a progressive manner, and the same and similar parts between the various embodiments can participate in each other, and each embodiment focuses on the differences from other embodiments. In particular, for the hardware + program embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant points can be part of the description of the method embodiment.

The embodiments of this specification are not limited to the conditions described in one or more embodiments of this specification that must comply with industry communication standards, standard computer data processing and data storage rules. Certain industry standards or implementations described in custom methods or examples with slight modifications can also achieve the same, equivalent or similar implementation effects of the foregoing examples, or predictable implementation effects after modification. Examples obtained by applying these modified or deformed data acquisition, storage, judgment, processing methods, etc., may still fall within the scope of the optional implementation solutions of the examples of this specification.

In the 1990s, the improvement of a technology can be clearly distinguished between hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method flow). However, with the development of technology, the improvement of many methods and processes of today can be regarded as a direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware entity modules. For example, a programmable logic device (Programmable Logic Device, PLD) (for example, a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user's programming of the device. It is programmed by the designer to "integrate" a digital system on a PLD without requiring the chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly realized by "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and there is not only one type of HDL, but many types, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description), etc., currently most commonly used It is VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that just a little bit of logic programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain the hardware circuit that implements the logic method flow.

The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program codes (such as software or firmware) executable by the (micro)processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as a part of the memory control logic. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, it is entirely possible to program the method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded The same function can be realized in the form of a microcontroller, etc. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for implementing various functions can also be regarded as a structure within the hardware component. Or even, the device for realizing various functions can be regarded as both a software module for realizing the method and a structure within a hardware component.

The systems, devices, modules, or units illustrated in the above embodiments may be specifically implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, and a tablet. Computers, wearable devices, or any combination of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, conventional or non-inventive means may include more or fewer operation steps. The sequence of steps listed in the embodiment is only one way of the execution sequence of the steps, and does not represent the only execution sequence. When an actual device or terminal product is executed, it can be executed sequentially or in parallel according to the methods shown in the embodiments or drawings (for example, a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product, or device that includes a series of elements includes not only those elements, but also other elements that are not explicitly listed. Elements, or also include elements inherent to such processes, methods, products, or equipment. If there are no more restrictions, it does not exclude that there are other identical or equivalent elements in the process, method, product, or device including the elements. Words such as first and second are used to denote names, but do not denote any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the function of each module can be realized in the same one or more software and/or hardware, or the module that realizes the same function can be realized by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are merely illustrative, for example, the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or integrated To another system, or some features can be ignored, or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

This application is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of this application. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.

In a typical configuration, the computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent memory in computer readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of a computer readable medium.

Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. The information can be computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

Those skilled in the art should understand that one or more embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, one or more embodiments of this specification may adopt a computer program implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. The form of the product.

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

The various embodiments in this specification are described in a progressive manner, and the same and similar parts between the various embodiments can participate in each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be described in the method embodiment. In the description of this specification, descriptions with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" etc. mean specific features described in conjunction with the embodiment or example , Structure, materials or features are included in at least one embodiment or example in this specification. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the described specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples and the features of the different embodiments or examples described in this specification without contradicting each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not used to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.

Claims

A digital currency transaction data processing method, which is characterized in that it comprises:

Receiving transaction request data sent by the first secret key service client, where the transaction request data includes data to be signed;

Sending the data to be signed to the second secret key service client;

According to the first private key component saved by the first secret key service client and the second private key component saved by the second secret key service client, the data to be signed is signed to obtain the signature data, wherein: The sum of the first private key component and the second private key component is the private key of the transaction account;

The signature data is sent to the first secret key service client, so that the first secret key service client performs transaction transfer processing.
The method of claim 1, wherein the second private key component includes a first private key fragment and a second private key fragment;

Correspondingly, the said data to be signed is signed according to the first private key component saved by the first secret key service client and the second private key component saved by the second secret key service client to obtain Signature data, including:

Acquiring the first private key fragment, and sending the second private key fragment to the first secret key service client;

According to the first private key shard, pair with the first private key component stored in the first secret key service client and the second private key shard received by the first secret key service client The data to be signed is signed to obtain the signature data.
The method according to claim 2, wherein the first private key component corresponds to a public key, and the second private key segment is encrypted using the public key corresponding to the first private key component;

Correspondingly, the sending the second private key fragments to the first secret key service client includes:

Receiving the signature confirmation information of the second secret key service client, and obtaining the first private key fragment and the encrypted second private key fragment;

The encrypted second private key fragments are sent to the first secret key service client, so that the first secret key service client uses the first private key component to decrypt to obtain the second private key Key fragmentation.
The method according to claim 1, wherein the signing the data to be signed to obtain the signature data comprises:

According to the first private key component and the second private key component, and the first secret key service client, use secure multi-party computing to sign the data to be signed to obtain the signature data.
The method of claim 1, wherein the transaction request data includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, exchange withdrawal request data, and financial management request data. At least one of.
A secret key management server for digital currency transactions, which is characterized in that it includes:

A transaction request receiving module, configured to receive transaction request data sent by the first secret key service client, where the transaction request data includes data to be signed;

A signed data forwarding module, configured to send the data to be signed to the second secret key service client;

The first signature module is configured to sign the data to be signed according to the first private key component saved by the first secret key service client and the second private key component saved by the second secret key service client , Obtain the signature data, wherein the sum of the first private key component and the second private key component is the private key of the transaction account;

The first transfer processing module is configured to send the signature data to the first secret key service client, so that the first secret key service client performs transaction transfer processing.
7. The secret key management server according to claim 6, wherein the second private key component includes a first private key fragment and a second private key fragment;

Correspondingly, the first signature module is specifically used for:

Acquiring the first private key fragment, and sending the second private key fragment to the first secret key service client;

According to the first private key shard, pair with the first private key component stored in the first secret key service client and the second private key shard received by the first secret key service client The data to be signed is signed to obtain the signature data.
8. The key management server according to claim 7, wherein the first private key component corresponds to a public key, and the second private key fragment is encrypted using the public key corresponding to the first private key component ；

Correspondingly, the first signature module is specifically used for:

Receiving the signature confirmation information of the second secret key service client, and obtaining the first private key fragment and the encrypted second private key fragment;

The encrypted second private key fragments are sent to the first secret key service client, so that the first secret key service client uses the first private key component to decrypt to obtain the second private key Key fragmentation.
7. The key management server according to claim 6, wherein the first signature module is specifically configured to:

According to the first private key component and the second private key component, and the first secret key service client, use secure multi-party computing to sign the data to be signed to obtain the signature data.
The key management server according to claim 6, wherein the transaction request data received by the transaction request receiving module includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data , At least one of exchange withdrawal request data and wealth management request data.
A digital currency transaction data processing method, which is characterized in that it comprises:

Sending transaction request data to the secret key management server, so that the secret key management server sends transaction request data to the second secret key service client, where the transaction request data includes data to be signed;

Receiving the second private key component saved by the second key service client and sent by the key management server;

According to the first private key component stored by itself and the received second private key component, the data to be signed is signed to obtain signature data, wherein the first private key component and the second private key The sum of the weights is the private key of the trading account;

Perform transaction transfer processing according to the signature data.
The method according to claim 11, wherein the second private key component comprises: a first private key fragment, a second private key fragment, and the second private key fragment uses the first private key fragment. The public key corresponding to the key component is encrypted;

Correspondingly, the receiving the second private key component saved by the second key service client sent by the key management server includes:

Receive the encrypted second private key segment sent by the key management server, and use the first private key component to decrypt the encrypted second private key segment to obtain the second private key Fragmentation;

Correspondingly, the signing the data to be signed to obtain the signature data includes:

Sign the data to be signed according to the first private key component, the obtained second private key fragment, and the first private key fragment obtained by the key management server to obtain signature data.
The method according to claim 11, wherein the signing the data to be signed to obtain the signature data comprises:

According to the first private key component and the second private key component, and the key management server, use secure multi-party computing to sign the data to be signed to obtain the signature data.
The method of claim 11, wherein the transaction request data includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, exchange withdrawal request data, and financial management request data. At least one of.
The method according to claim 14, wherein the method for generating the first private key component and the second private key component comprises:

If the transaction request data is the digital currency transaction request data or the user withdrawal request data or the wealth management request data, when the user account is created, the private key corresponding to the user account will be The second secret key service client generates respective first private key components and second private key components;

If the transaction request data is the cold wallet transfer request data or the exchange currency withdrawal request data, when the exchange account is created, according to the private key of the exchange account, serve the customer with the second secret key The terminals respectively generate their first private key component and second private key component.
A digital currency transaction data processing client is characterized in that it includes:

The transaction request sending module is configured to send transaction request data to the secret key management server, so that the secret key management server sends the transaction request data to the second secret key service client, and the transaction request data includes the data to be signed;

A secret key receiving module, configured to receive the second private key component saved by the second secret key service client and sent by the secret key management server;

The second signature module is configured to sign the data to be signed according to the first private key component stored by itself and the received second private key component to obtain signature data, wherein the first private key component The sum of the second private key component is the private key of the transaction account;

The second transfer processing module is used to perform transaction transfer processing according to the signature data.
The client according to claim 16, wherein the second private key component comprises: a first private key fragment, a second private key fragment, and the second private key fragment uses the first private key fragment. Encrypt the public key corresponding to the private key component;

Correspondingly, the secret key receiving module is specifically used for:

Receive the encrypted second private key segment sent by the key management server, and use the first private key component to decrypt the encrypted second private key segment to obtain the second private key Fragmentation;

Correspondingly, the second signature module is specifically used for:

Sign the data to be signed according to the first private key component, the obtained second private key fragment, and the first private key fragment obtained by the key management server to obtain signature data.
The client according to claim 16, wherein the second signature module is specifically configured to:

According to the first private key component and the second private key component, and the key management server, use secure multi-party computing to sign the data to be signed to obtain the signature data.
The client according to claim 16, wherein the transaction request data sent by the transaction request sending module includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, and exchange At least one of withdrawal request data and wealth management request data.
The client according to claim 19, wherein the client further comprises a first private key component generating module, configured to:

If the transaction request data is the digital currency transaction request data or the user withdrawal request data or the wealth management request data, when the user account is created, the private key corresponding to the user account will be The second secret key service client generates respective first private key components and second private key components;

If the transaction request data is the cold wallet transfer request data or the exchange currency withdrawal request data, when the exchange account is created, according to the private key of the exchange account, serve the customer with the second secret key The terminals respectively generate their first private key component and second private key component.
A digital currency transaction data processing method, which is characterized in that it comprises:

Receiving transaction request data sent by the secret key management server, the transaction request data being sent by the first secret key service client, and the transaction request data including data to be signed;

Return confirmation signature information to the key management server, and send the second private key component stored by itself to the key management server, so that the key management server and the first key service client The second private key component and the first private key component saved by the first secret key service client sign the data to be signed to obtain the signature data, and the first secret key service client is based on The signature data is processed for transaction transfer;

Wherein, the sum of the first private key component and the second private key component is the private key of the transaction account.
21. The method of claim 21, wherein the sending the first private key component stored by itself to the secret key management server comprises:

Split the second private key component into a first private key fragment and a second private key fragment, and encrypt the second private key fragment by using a public key corresponding to the first private key component;

Sending the first private key fragment and the encrypted second private key fragment to the secret key management server;

Correspondingly, the secret key management server and the first secret key service client perform the signature on the to-be-signed according to the second private key component and the first private key component stored by the first secret key service client Data is signed, including:

The key management server sends the encrypted second private key fragments to the first key service client;

The first secret key service client uses the first private key component to decrypt the encrypted second private key fragment to obtain the second private key fragment;

Based on the first private key fragment, the first private key component, and the second private key fragment, the key management server and the first key service client use secure multi-party computing to compare the data to be signed Sign and obtain the signature data.
The method of claim 21, wherein the transaction request data includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, exchange withdrawal request data, and financial management request data. At least one of.
The method of claim 23, wherein the method for generating the first private key component and the second private key component comprises:

If the transaction request data is the digital currency transaction request data or the user withdrawal request data or the wealth management request data, when the user account is created, the private key corresponding to the user account will be The first secret key service client generates respective second private key components and first private key components;

If the transaction request data is the cold wallet transfer request data or the exchange currency withdrawal request data, when the exchange account is created, according to the private key of the exchange account, serve the customer with the first secret key The terminals respectively generate their second private key component and first private key component.
A digital currency transaction data processing terminal, characterized in that it comprises:

The transaction request query module is configured to receive transaction request data sent by the secret key management server, the transaction request data is sent by the first secret key service client, and the transaction request data includes data to be signed;

The signature confirmation module is used to return confirmation signature information to the secret key management server, and send the second private key component stored by itself to the secret key management server, so that the secret key management server and the first The secret key service client signs the data to be signed according to the second private key component and the first private key component saved by the first secret key service client to obtain signature data, and the The secret key service client performs transaction transfer processing according to the signature data;

Wherein, the sum of the first private key component and the second private key component is the private key of the transaction account.
The terminal according to claim 25, wherein the signature confirmation module is specifically configured to:

Split the second private key component into a first private key fragment and a second private key fragment, and encrypt the second private key fragment by using a public key corresponding to the first private key component;

Sending the first private key fragment and the encrypted second private key fragment to the secret key management server;

Correspondingly, the secret key management server and the first secret key service client perform the signature on the to-be-signed according to the second private key component and the first private key component stored by the first secret key service client Data is signed, including:

The key management server sends the encrypted second private key fragments to the first key service client;

The first secret key service client uses the first private key component to decrypt the encrypted second private key fragment to obtain the second private key fragment;

Based on the first private key fragment, the first private key component, and the second private key fragment, the key management server and the first key service client use secure multi-party computing to compare the data to be signed Sign and obtain the signature data.
The terminal according to claim 25, wherein the transaction request data received by the transaction request query module includes: digital currency transaction request data, user withdrawal request data, cold wallet transfer request data, exchange At least one of withdrawal request data and wealth management request data.
The terminal according to claim 27, wherein the terminal further comprises a second private key component generating module, configured to:

If the transaction request data is the digital currency transaction request data or the user withdrawal request data or the wealth management request data, when the user account is created, the private key corresponding to the user account will be The first secret key service client generates respective second private key components and first private key components;

If the transaction request data is the cold wallet transfer request data or the exchange currency withdrawal request data, when the exchange account is created, according to the private key of the exchange account, serve the customer with the first secret key The terminals respectively generate their second private key component and first private key component.
A digital currency transaction data processing equipment, which is characterized by comprising: at least one processor and a memory for storing executable instructions of the processor. The processor implements the instructions described in any one of claims 1-5 when executing the instructions. The method or the method of any one of claims 11-15 or the method of any one of claims 21-24.
A computer-readable storage medium, characterized in that computer instructions are stored thereon, and when executed, the instructions implement the method of any one of claims 1-5 or the method of any one of claims 11-15. The method or the method of any one of claims 21-24.
A digital currency transaction data processing system, which is characterized by comprising: a secret key management server, a first secret key service client, and a second secret key service client;

The digital currency transaction data processing system is used to perform at least one of the buying and selling of digital currency, the withdrawal of digital currency, the cold wallet transfer of digital currency in the exchange system, and the investment management of digital currency. The secret key The management server is used to execute the method according to any one of claims 1-5, the first secret key service client is used to execute the method according to any one of claims 11-15, and the second secret The key service client is used to execute the method described in any one of claims 21-24;

Wherein, if the digital currency transaction data processing system is used for buying and selling digital currency, the first secret key service client is a buyer user transaction client or a seller user transaction client, and the second secret The key service client is the exchange client;

If the digital currency transaction data processing system is used to withdraw digital currency, the first secret key service client is a withdrawal user client, and the second secret key service client is an exchange client, Wherein, if the withdrawal of the digital currency is an exchange withdrawal, the second secret key service client includes one or more;

If the digital currency transaction data processing system is used for cold wallet transfer of digital currency of the exchange system, the first secret key service client and the second secret key service client are both exchange clients, where , The second secret key service client includes one or more;

If the digital currency transaction data processing system is used for digital currency investment management, the first secret key service client is a wealth management user client, and the second secret key service client is an asset management client.