Data processing method and apparatus based on blockchain key, and device and storage medium

Abstract

Disclosed in the embodiments of the present application are a data processing method and apparatus based on a blockchain key, and a device and a storage medium. The method comprises: acquiring communication channels by means of which communication with N clients is separately performed, and on the basis of the N communication channels, separately performing key shard negotiation with the N clients, so as to obtain a local private-key shard and a complete public key; receiving signature requests sent by M-1 clients among the N clients, and acquiring identity association information from the M-1 signature requests; if each piece of the identity association information is legitimate identity information, determining, as a target client, a client among the M-1 clients which is used for initiating a blockchain service, and acquiring service execution data associated with the target client; and if the service execution data conforms to a risk management strategy corresponding to the identity association information of the target client, participating, together with the M-1 clients, in joint signature processing for the blockchain service. By means of the embodiments of the present application, the risk probability during the use of a digital asset can be reduced.

Description

Data processing method, device, equipment and storage medium based on blockchain key

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on August 9, 2023, with application number 202310997066.1 and application name “Data processing method, device, equipment and storage medium based on blockchain key”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of blockchain technology, and in particular to a data processing method, apparatus, device and storage medium based on blockchain keys. The method mainly relates to digital asset management technology, and realizes signature processing through key management methods and key usage methods. Background Art

[0003] With the development of blockchain technology, the application of digital assets is becoming increasingly widespread. Since digital assets require signatures using corresponding keys during business interactions, successful business interactions require the generation of secure and stable signing keys. Current key generation methods typically use algorithms to generate a public-private key pair, which is then encrypted using the private key and decrypted using the corresponding public key. If the private key is damaged or lost, the digital asset becomes unusable. Therefore, current key signing methods increase the risk associated with the use of digital assets.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a data processing method, apparatus, device, and storage medium based on a blockchain key, which can reduce the risk probability of using digital assets.

[0006] On the one hand, an embodiment of the present application provides a data processing method based on a blockchain key, the method comprising:

[0007] Acquire communication channels for communicating with N clients respectively, and perform key shard negotiation with each of the N clients based on the N communication channels to obtain local private key shards and a complete public key; N is a positive integer greater than 1; the complete public key is the unique public key corresponding to the local private key shard and the N target private key shards; the i-th target private key shard among the N target private key shards is the private key shard exclusively held by the i-th client among the N clients after the key shard negotiation;

[0008] Receive signature requests from M-1 clients out of N clients, and obtain identity association information from the M-1 signature requests; M is the threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1;

[0009] If the identity-related information in the M-1 signature requests is all legitimate, the client used to initiate the blockchain business among the M-1 clients is determined as the target client, and the business execution data associated with the target client is obtained;

[0010] If the business execution data complies with the risk management policy corresponding to the identity association information of the target client, it will participate in the joint signature processing for the blockchain business together with M-1 clients; the joint signature result generated by the joint signature processing is based on the local private key shard and the target private key shards held by M-1 clients respectively, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0011] On the one hand, an embodiment of the present application provides a data processing method based on a blockchain key, which is executed by a target client for initiating a blockchain service, and the method includes:

[0012] The target client obtains a communication channel for communicating with N-1 clients and a server respectively, and performs key shard negotiation with the server and the N-1 clients based on the communication channel to obtain a target private key shard and a complete public key corresponding to the target client; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the target private key shard corresponding to the target client, the server private key shard, and the target private key shards corresponding to the N-1 clients; the i-th target private key shard among the target private key shards corresponding to the N-1 clients is the private key shard exclusively held by the i-th client among the N-1 clients after the key shard negotiation; the server private key shard is the private key shard exclusively held by the server after the key shard negotiation;

[0013] Generate a signature request corresponding to the target client based on the identity association information corresponding to the target client, and send the signature request corresponding to the target client to the server, so that the server can verify the legality of the identity association information in the M-1 signature requests received; the M-1 signature requests include the signature request corresponding to the target client; M is the threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1;

[0014] If the server determines that the identity-related information in the M-1 signature requests is all legal identity information, the service execution data associated with the target client is sent to the server;

[0015] If the business execution data complies with the risk management policy corresponding to the identity association information of the target client, it will jointly participate in the joint signature processing for the blockchain business with the client that initiates the signature request and the server; the joint signature result generated by the joint signature processing is based on the target private key shard corresponding to the client that initiates the signature request and the server private key shard, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0016] In one aspect, an embodiment of the present application provides a data processing device based on a blockchain key, the data processing device comprising:

[0017] A local private key shard acquisition module is configured to acquire communication channels for communicating with N clients, perform key shard negotiation with each of the N clients based on the N communication channels, and obtain local private key shards and a complete public key; N is a positive integer greater than 1; the complete public key is the unique public key corresponding to the local private key shard and the N target private key shards; the i-th target private key shard among the N target private key shards is the private key shard exclusively held by the i-th client among the N clients after the key shard negotiation;

[0018] An identity association information acquisition module is configured to receive signature requests from M-1 clients out of N clients and obtain identity association information from the M-1 signature requests; M is a threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1;

[0019] A target client determination module is configured to determine the client used to initiate the blockchain service among the M-1 clients as the target client if the identity association information in the M-1 signature requests is all legitimate identity information;

[0020] A service execution data acquisition module is used to obtain service execution data associated with the target client;

[0021] The first joint signature module is used to participate in the joint signature processing for blockchain business with M-1 clients if the business execution data complies with the risk management policy corresponding to the identity association information of the target client; the joint signature result generated by the joint signature processing is jointly generated based on the local private key shard and the target private key shards held by the M-1 clients respectively, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0022] Among them, the local private key shard acquisition module includes:

[0023] A local test private key generation unit is used to randomly generate a local test private key for key sharding negotiation, and encrypt local negotiation data using the local test private key to obtain local test information;

[0024] A communication channel acquisition unit, configured to acquire communication channels for communicating with N clients respectively, and send local test information to the N clients via each communication channel;

[0025] A target decryption data acquisition unit is configured to receive target test public keys and target test information respectively sent by N clients, and decrypt the target test information belonging to the same client using the target test public key to obtain N target decrypted data; a target test public key refers to a public key corresponding to a target test private key generated by a client for key sharding negotiation, and a target test information refers to information obtained by encrypting target negotiation data using the target test private key generated by a client;

[0026] A first hash result determining unit is configured to decrypt the local test information based on the local test public key corresponding to the local test private key to obtain local decrypted data, and determine the local decrypted data and the N target decrypted data as a first hash result;

[0027] A second hash result obtaining unit, configured to perform a hash operation on the local negotiation data and the N target negotiation data to obtain a second hash result;

[0028] a local private key shard determining unit, configured to determine that the key negotiation is successful if the first hash result is equal to the second hash result, and determine the local test private key as the local private key shard;

[0029] The complete public key generation unit is used to generate a complete public key during the key sharding negotiation process with N clients.

[0030] The data processing device further includes:

[0031] The target shard public key acquisition module is used to obtain the target shard public keys corresponding to M-1 clients respectively; the target shard public key corresponding to a client is generated based on the target private key shard corresponding to the client;

[0032] The signature verification module is used to verify the signatures of the shard signatures sent by M-1 clients using M-1 target shard public keys, and obtain M-1 signature verification results. A shard signature result refers to the data obtained by a client signing the identity association information using the target private key shard corresponding to the client.

[0033] The legal identity authentication module is used to perform legal identity authentication on the identity association information in the signature requests sent by the M-1 clients if all the M-1 signature verification results are successful.

[0034] The M-1 clients include client Si, where i is a positive integer less than or equal to M-1; the legal identity authentication module includes:

[0035] The business type acquisition unit is used to obtain the business type of the blockchain business initiated by M-1 clients, and obtain the client S i The identity identifier and identity feature data in the corresponding identity association information;

[0036] An identity authentication policy determination unit is used to determine the identity authentication policy that matches the business type, and select data that matches the verification dimension indicated by the identity authentication policy from the identity identifier and identity feature data as the data to be verified;

[0037] The legal identity information determining unit is configured to determine that the identity association information in the signature request corresponding to the client Si is legal identity information if the data to be verified exists in the identity database.

[0038] Among them, the business execution data acquisition module is specifically used to obtain the historical business execution data of the target client and the target business execution data in the initiated blockchain business, and determine the historical business execution data and the target business execution data as the business execution data associated with the target client;

[0039] The data processing device further includes:

[0040] A business threshold setting module is used to analyze historical business execution data in the business execution data to obtain the historical business operation range and set the business threshold based on the historical business operation range;

[0041] The risk management policy determination module is configured to determine that the business execution data complies with the risk management policy corresponding to the identity association information of the target client if the target business execution data in the business execution data is less than or equal to the business threshold.

[0042] The data processing device further includes:

[0043] The address risk detection module is used to obtain the application chain address corresponding to the target client from the business execution data and perform address risk detection on the application chain address;

[0044] A first address detection module is configured to determine whether the business execution data complies with the risk management policy corresponding to the identity association information of the target client if it is detected that the address on the application chain exists in the legal address list;

[0045] The second address detection module is used to determine that the address on the application chain is a risky address if it is detected that the address on the application chain does not exist in the legal address list, and prohibit responding to the blockchain business initiated by the target client.

[0046] The M-1 clients include the target client; the first joint signature module includes:

[0047] The server-side signature result acquisition unit is used to receive the intermediate encryption result sent by the target client after being encrypted by the target private key fragment corresponding to the target client, and sign the received intermediate encryption result using the local private key fragment to obtain the server-side signature result;

[0048] The joint signature result generation unit is used to send the server signature result to the target client; the server signature result is used to instruct the target client to generate a joint signature result.

[0049] The data processing device further includes:

[0050] The business data receiving module is used to receive the business data to be uploaded to the blockchain sent by the target client; the business data to be uploaded to the blockchain consists of the target business execution data and the joint signature result in the blockchain business;

[0051] The business data forwarding module is used to forward the business data to be uploaded to the blockchain consensus network, so that the blockchain consensus network can verify the joint signature result based on the complete public key during the consensus process. When the consensus is passed, the execution result data corresponding to the target business execution data is stored in the blockchain ledger.

[0052] The data processing device further includes:

[0053] A target business address generation module, used to generate a target business address based on a complete public key;

[0054] The to-be-verified address acquisition module is used to obtain the to-be-verified addresses sent by N clients respectively; the to-be-verified address sent by a client is generated based on the complete public key;

[0055] A legal address determination module is used to determine that the target business address is a legal address if the target business address is the same as the N addresses to be verified, and to determine the target business address as the address on the application chain;

[0056] The module for deleting the address to be verified is used to delete the generated target business address and the N addresses to be verified if there is an address to be verified that is different from the target business address among the N addresses to be verified, and send a request to regenerate the address on the application chain to the N clients; the request to regenerate the address on the application chain is used to instruct the N clients to regenerate a new address to be verified based on the complete public key.

[0057] In one aspect, an embodiment of the present application provides a data processing device based on a blockchain key, the data processing device comprising:

[0058] A target private key shard acquisition module is configured to cause a target client to acquire a communication channel for communicating with N-1 clients and a server, respectively, and to perform key shard negotiation with the server and the N-1 clients based on the communication channel to obtain a target private key shard and a complete public key corresponding to the target client; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the target private key shard corresponding to the target client, the server private key shard, and the target private key shards corresponding to the N-1 clients; the i-th target private key shard among the target private key shards corresponding to the N-1 clients is the private key shard solely held by the i-th client among the N-1 clients after the key shard negotiation; the server private key shard is the private key shard solely held by the server after the key shard negotiation;

[0059] A signature request sending module is configured to generate a signature request corresponding to the target client based on the identity association information corresponding to the target client, and send the signature request corresponding to the target client to the server, so that the server can authenticate the legality of the identity association information in the M-1 signature requests received; the M-1 signature requests include the signature request corresponding to the target client; M is a threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1;

[0060] A service execution data sending module is configured to send service execution data associated with the target client to the server if it is detected that the identity association information in the M-1 signature requests determined by the server is all legal identity information;

[0061] The second joint signature module is used to participate in the joint signature processing for the blockchain business together with the client that initiates the signature request and the server if the business execution data complies with the risk management policy corresponding to the identity association information of the target client; the joint signature result generated by the joint signature processing is based on the target private key shard corresponding to the client that initiates the signature request and the server private key shard, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0062] The M-1 clients include a target client and a signing client; the data processing device further includes:

[0063] The first encryption module is configured to, upon receiving server failure information sent by the server, encrypt the acquired information to be signed using the target private key shard corresponding to the target client to obtain an initial signature result;

[0064] The second encryption module is used to send the initial signature result to the signing client, so that the signing client encrypts the initial signature result using the target private key fragment corresponding to the signing client to obtain a target signature result;

[0065] The target signature result receiving module is used to receive the target signature result sent by the signature client and generate a joint signature result based on the target signature result.

[0066] Among them, the signature request sending module includes:

[0067] The data display unit is used to display the business initiation control, the application chain address corresponding to the target client, and the virtual resource data in the blockchain function interface; the virtual resource data is used to represent the business data in the blockchain business account corresponding to the target client;

[0068] An operation response unit, configured to respond to an initiation of a blockchain business operation in response to a business initiation control in the blockchain function interface, and send a signature request corresponding to the target client generated based on the identity association information corresponding to the target client to the server;

[0069] The data processing device further includes:

[0070] The data sending module sends the business data to be uploaded to the server. The business data to be uploaded consists of the target business execution data and the joint signature result in the blockchain business.

[0071] The feedback data receiving module is used to receive feedback data sent by the server for the business data to be uploaded if the blockchain consensus network successfully verifies the joint signature result based on the complete public key and the consensus on the business data to be uploaded is passed, and update the virtual resource data displayed in the blockchain function interface based on the feedback data.

[0072] On one hand, the present application provides a computer device, including: a processor, a memory, and a network interface;

[0073] The above-mentioned processor is connected to the above-mentioned memory and the above-mentioned network interface, wherein the above-mentioned network interface is used to provide data communication function, the above-mentioned memory is used to store computer programs, and the above-mentioned processor is used to call the above-mentioned computer program so that the computer device executes the method in the embodiment of the present application.

[0074] On one hand, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. The computer program is suitable for being loaded by a processor and executing the method in the embodiment of the present application.

[0075] On the one hand, an embodiment of the present application provides a computer program product or a computer program, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method in the embodiment of the present application.

[0076] In an embodiment of the present application, communication channels for communicating with N clients are obtained, and key sharding negotiation is performed with each of the N clients based on the N communication channels to obtain local private key shards and a complete public key. N is a positive integer greater than 1. Specifically, the complete public key is the unique public key corresponding to the local private key shard and the N target private key shards. The i-th target private key shard among the N target private key shards is the private key shard held exclusively by the i-th client among the N clients after key sharding negotiation. Furthermore, signature requests are received from M-1 of the N clients, and identity-related information in the M-1 signature requests is obtained. M is the threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1. Furthermore, if the identity-related information in the M-1 signature requests is all valid, the client among the M-1 clients that initiated the blockchain service is determined as the target client, and service execution data associated with the target client is obtained. Furthermore, if the business execution data complies with the risk management policy corresponding to the identity-related information of the target client, then the joint signature process for the blockchain business is jointly participated in with M-1 clients. The joint signature result generated by the joint signature process is jointly generated based on the local private key shard and the target private key shards held by the M-1 clients, and the joint signature result is used to provide the target client with the blockchain business execution. In this embodiment of the present application, by negotiating the key shards to obtain the local private key shard and the target private key shard, and verifying the identity-related information of the client or server participating in the signature, and then performing a joint signature process for the multi-terminal private key shards after the identity-related information is verified as legitimate, it is no longer necessary to use a single private key to sign digital assets, thereby reducing the probability of signature errors due to private key problems. That is, when the private key shards in some clients or servers are unavailable, the signing function can still be achieved through the other M available private key shards, thereby improving the security probability of digital asset signatures, that is, reducing the risk probability of using digital assets. In addition, the legality detection of identity-related information and the application of risk management policies can reduce the risk of digital asset business interactions and improve the security of digital asset business interactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0078] FIG1 is a schematic diagram of the structure of a blockchain network provided in an embodiment of the present application;

[0079] FIG2 is a schematic diagram of a scenario regarding digital asset signature provided by an embodiment of the present application;

[0080] FIG3 is a flow chart of a data processing method provided in an embodiment of the present application;

[0081] FIG4 is a flow chart of another data processing method provided in an embodiment of the present application;

[0082] FIG5 is a schematic diagram of an interface of a target client provided in an embodiment of the present application;

[0083] FIG6 is an interactive flow chart of digital asset signature provided by an embodiment of the present application;

[0084] FIG7 is a schematic structural diagram of a data processing device provided in an embodiment of the present application;

[0085] FIG8 is a schematic structural diagram of another data processing device provided in an embodiment of the present application;

[0086] FIG9 is a schematic structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0087] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0088] It is understandable that in the specific implementation of this application, when data related to objects or users (such as payment data) is involved, when the following embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0089] The solution provided in the embodiments of this application involves blockchain technology, and the specific process is explained through the following embodiments.

[0090] Please refer to Figure 1, which is a schematic diagram of the structure of a blockchain network provided in an embodiment of the present application. The blockchain network shown in Figure 1 may include, but is not limited to, a distributed network corresponding to a blockchain service. The blockchain network may include multiple blockchain nodes, which may specifically include blockchain node 10a, blockchain node 10b, blockchain node 10c, blockchain node 10d, ..., and blockchain node 10n. For example, a blockchain node may be a client or server in the distributed network corresponding to the blockchain service. During normal operation, each blockchain node may receive data sent from the outside world, perform block chain processing based on the received data, and may also send data to the outside world. To ensure data interoperability between the various blockchain nodes, data connections may exist between each blockchain node, for example, a data connection between blockchain node 10a and blockchain node 10b, a data connection between blockchain node 10a and blockchain node 10c, and a data connection between blockchain node 10b and blockchain node 10c.

[0091] It is understandable that data or blocks can be transferred between blockchain nodes through the above-mentioned data connection. The blockchain network can realize data connection between blockchain nodes based on node identification. Each blockchain node in the blockchain network has a corresponding node identification, and each of the above-mentioned blockchain nodes can store the node identifications of other blockchain nodes with which it is connected, so that the acquired data or generated blocks can be broadcast to other blockchain nodes based on the node identifications of other blockchain nodes. For example, the blockchain node 10a can maintain a node identification list as shown in Table 1, which stores the node names and node identifications of other nodes:

[0092] Table 1

[0093] The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify a node in a blockchain network. Table 1 uses the IP address as an example. For example, blockchain node 10a can send blockchain data (e.g., encrypted data packaged in a block format) to blockchain node 10b using the node identifier BBB.BBB.BBB.BBB, and blockchain node 10b can determine that the information was sent by blockchain node 10a using the node identifier AAA.AAA.AAA.AAA.

[0094] In a blockchain, before a block is uploaded to the blockchain, it must be agreed upon by consensus nodes within the blockchain network. Only after consensus is achieved can the block be added to the blockchain. It is understandable that when blockchain is used in certain commercial scenarios, not all participating nodes in the blockchain (i.e., the blockchain nodes in the aforementioned blockchain network) have sufficient resources or the necessary resources to serve as consensus nodes. For example, in the blockchain network shown in Figure 1, blockchain nodes 10a, 10b, 10c, and 10d can be considered consensus nodes. Consensus nodes in a blockchain network participate in consensus, i.e., reaching consensus on blocks (containing a batch of transactions) and voting on blocks. Non-consensus nodes, on the other hand, do not participate in consensus, but help propagate block and voting information and synchronize their status with each other.

[0095] It is understood that the method provided in the embodiment of the present application can be executed by a computer device, including but not limited to the above-mentioned blockchain node (which can be a client or a server in the embodiment of the present application). In the embodiment of the present application, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. In particular, the client mentioned above can be an electronic device, including but not limited to mobile phones, tablet computers, desktop computers, laptop computers, PDAs, in-vehicle devices, augmented reality / virtual reality (AR / VR) devices, helmet displays, smart TVs, wearable devices, smart speakers, digital cameras, cameras and other mobile Internet devices (mobile internet devices, MIDs) with network access capabilities, or terminal devices in scenarios such as trains, ships, and flights.

[0096] It is understood that the embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, etc. For example, a blockchain node system can reach a consensus on driving behavior data, road trajectory data, etc. sent by an in-vehicle terminal, and store the data on the blockchain after consensus is reached.

[0097] It is understood that the storage and calculation of multiple different private key shards in the embodiments of the present application can be performed by servers, personal computers, personal smart wearable devices, and other devices with computing and storage capabilities (such as smart cars and smart drones). For example, when a business object needs to manage data assets through its own smart devices, it can initiate a digital asset processing process through a personal smart car or smart watch, VR device, etc., and complete the signature based on the joint calculation of the local private key shard corresponding to the smart device and the private key shards corresponding to other devices.

[0098] The computer device mentioned in this application may be a server or a client, or a system composed of a server and a client.

[0099] Further, please refer to Figure 2, which is a schematic diagram of a scenario for digital asset signature provided by an embodiment of the present application. As shown in Figure 2, the server 300 can be the background server (i.e., the server) corresponding to the client with the payment application installed in the embodiment of the present application, and the business device 400a can be the client with the payment application installed in the embodiment of the present application. At the same time, the server 300 can be the blockchain node 10b in Figure 1, and the business device 400a can be the blockchain node 10a in Figure 1. Specifically, the server 300 can obtain a communication channel for communicating with N clients respectively. Among them, the N clients can include the business device 400a. Further, the server 300 can perform key sharding negotiation with the N clients respectively based on the N communication channels to obtain local private key shards and complete public keys held solely by the server 300. For example, server 300 can conduct key shard negotiation with N business devices, including business device 400a, business device 401a, ..., and business device 402a, to obtain a local private key shard solely held by server 300, a first target private key shard solely held by business device 400a, a second target private key shard solely held by business device 401a, ..., a third target private key shard solely held by business device 402a, and a complete public key. N is a positive integer greater than 1. It can be understood that the complete public key is the unique public key corresponding to the local private key shard and the N target private key shards. The i-th target private key shard among the N target private key shards is the private key shard solely held by the i-th client among the N clients after key shard negotiation. In other words, each client can only hold one of the target private key shards. Furthermore, server 300 receives signature requests from M-1 of the N clients and obtains identity-associated information from the M-1 signature requests. Here, M is the threshold number of private key shards required for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1. Specifically, the threshold number of private key shards may refer to the minimum number of private key shards required to form a complete private key corresponding to a complete public key. For example, if a distributed system corresponding to a blockchain service includes one server and four clients, and the threshold number of private key shards for this distributed system is three, then the distributed system needs to generate a complete private key based on the private key shards corresponding to three participants (e.g., one server and two clients). In other words, a distributed system cannot generate a complete private key based on the private key shards corresponding to two participants. Furthermore, if the identity-related information in the M-1 signature requests is all valid, the client used to initiate the blockchain service among the M-1 clients is determined as the target client, and service execution data associated with the target client is obtained. For example, the service execution data associated with the target client may include transfer data from an application with payment functionality. Specifically, this transfer data may include data such as the transfer object, transfer amount, and identity information of the target client.Optionally, the service execution data associated with the target client may also refer to driving behavior data, road trajectory data, etc. transmitted by the vehicle terminal. Furthermore, if the service execution data complies with the risk management policy corresponding to the target client's identity-related information, the client and M-1 clients jointly participate in the joint signature process for the blockchain service. The joint signature result generated by the joint signature process is based on the local private key shard and the target private key shards held by the M-1 clients. The joint signature result is used to provide the target client with the execution of the blockchain service.

[0100] The public key and private key are a key pair (i.e., one public key and one private key) generated through a key generation algorithm. The public key is the public key portion of the key pair, while the private key is the private key portion. Specifically, the public key is typically used to encrypt data, verify digital signatures, and so on. This key generation algorithm ensures that the resulting key pair is unique. When using this key pair, if one key is used to encrypt a piece of data, the other key is required to decrypt it. For example, if data is encrypted with the public key, it must be decrypted with the private key. Similarly, if data is encrypted with the private key, it must also be decrypted with the public key; otherwise, the decryption will fail.

[0101] Specifically, taking the example of the server 300 and the business device 400a jointly participating in the joint signature processing for the blockchain business, the data processing method may at least include the following steps S21 to S27:

[0102] In step S21, the business device 400a signs the content to be signed using the target private key fragment it holds to obtain an intermediate encryption result.

[0103] The content to be signed may refer to business data that requires signature confirmation. For example, the business data may be data related to a transfer business in a payment application, such as the transfer object, transfer amount, and transfer institution.

[0104] In step S22, the server 300 receives the intermediate encryption result.

[0105] In step S23, the server 300 signs the intermediate encryption result using the local private key fragment to obtain a server-side signature result.

[0106] In step S24, the server 300 sends the server-side signature result.

[0107] In step S25, the business device 400a generates a joint signature result based on the server signature result, and generates business data to be uploaded to the chain based on the content to be signed and the joint signature result.

[0108] Step S26: The server 300 receives the business data to be uploaded to the chain.

[0109] In step S27, the server 300 sends the business data to be uploaded to the blockchain consensus network.

[0110] Optionally, server 300 may also receive data on the blockchain consensus network (i.e., server 300 may also be one of the consensus nodes in the blockchain consensus network) and process the received data. For the specific data processing process, please refer to the detailed description of the server's processing of the received client's blockchain business data in Figure 3 below.

[0111] It should be understood that in the distributed system 200S (i.e., the system consisting of the server 300 and the business device 400a), any machine (such as a server or a client) can join and become a node, and a node can correspond to a role (also referred to as an object). In other words, the distributed system can be used to provide corresponding access interfaces for roles joining the blockchain system. For example, corresponding access interfaces can be provided for roles such as the tax bureau (i.e., the tax bureau), the invoicing company, the consumer, and the reimbursement company. For example, tax personnel in the tax bureau can access the corresponding node through the target web page in the browser. For example, when consumers complete data interaction services through the target application, they can further access the corresponding node through the sub-application provided by the target application (e.g., a mini-program embedded in a payment application, etc.). It is understood that each node can include a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0112] Further, please refer to Figure 3, which is a flow chart of a data processing method provided in an embodiment of the present application. As shown in Figure 3, the method can be executed by a server, which can be the blockchain node 10b shown in Figure 1 above, but is not limited here. For ease of understanding, the embodiment of the present application uses the method executed by the server as an example for explanation. The data processing method can at least include the following steps S101-S104:

[0113] Step S101: obtain communication channels for communicating with N clients respectively, and perform key sharding negotiation with the N clients respectively based on the N communication channels to obtain local private key shards and a complete public key; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the local private key shard and the N target private key shards; the i-th target private key shard among the N target private key shards is the private key shard held solely by the i-th client among the N clients after the key sharding negotiation.

[0114] Specifically, the server can transmit communication messages to N clients through the communication channels that communicate with the N clients respectively (for example, send broadcasts to N clients). Furthermore, the server can perform operations such as service negotiation and service request confirmation through the communication channel. Among them, the communication channel may refer to a session channel used for conducting conversations between the server and the client. In a broad sense, the communication channel may include virtual channels for communication and physical channels that constitute communication lines. For example, the communication channel may include physical channels such as transmission cables. Specifically, the communication channel may refer to a communication channel used for broadcasting and other purposes. For example, in a local area network composed of communication lines, the communication channel may refer to the virtual lines and hardware lines that constitute the local area network.

[0115] Specifically, the embodiment of the present application does not limit the total number of clients. The client can be one or more, that is, N can be greater than or equal to 1. The specific value of N is determined by the number of participants (i.e., blockchain nodes) in the process of generating a complete private key when jointly generating a complete private key corresponding to a complete public key in the distributed system corresponding to the blockchain business. Here, an example is taken in which one client and one server jointly participate in the signing of a payment application, that is, the business object requests two participants to hold private key shards respectively (i.e., a local private key shard and a target private key shard). In other words, the server can negotiate key sharding with the client to generate two independent private key shards (i.e., the server holds the local private key shard alone, and the client holds the target private key shard alone). It should be understood that the generated private key shard is only known within the device that generates the private key shard, and is held solely by the device that generates the private key shard and will not be disclosed to the outside world. The private key shard is a portion of the complete private key of the blockchain system (the complete private key is not accessible to any participating party). The complete private key is composed of multiple private key fragments. The complete private key corresponds to the complete public key, and the complete public key and private key shards can be generated based on a distributed key generation (DKG) protocol. Specifically, in the DKG protocol, multiple participating servers or clients jointly generate a complete public key and their respective private key shards based on a pre-defined encryption system. The complete private key corresponding to the complete public key can be synthesized based on a number of private key shards exceeding a certain threshold, while any information about the complete private key cannot be obtained based on a number of private key shards below the threshold. The complete public key generated by the DKG protocol is output in a public form, and the private key shards are shared by participants according to a secret sharing scheme. The shared private key shards can be used in group-oriented cryptographic systems, such as group signatures or group decryption. Optionally, N can be 2. That is, a distributed system (such as the distributed system 200S shown in FIG2 ) can be exemplified by two clients and one server jointly participating in the signing of a payment application, i.e., the business object requests that three parties each hold a private key shard (i.e., a local private key shard and two target private key shards). In other words, the server can negotiate key shards with the two clients to generate three independent private key shards (i.e., a local private key shard corresponding to the server and target private key shards corresponding to the two clients). Optionally, the key agreement process can also include a threshold signature scheme (TSS) process. In other words, during the key agreement process, the server can use the threshold signature method to generate a single digital signature from multiple signers (blockchain nodes).Furthermore, specific implementation schemes of threshold signatures may include the Lindell algorithm (a threshold signature algorithm), the DKLS algorithm (a threshold signature algorithm), the CCLST algorithm (a threshold signature algorithm), the GKSS algorithm (a threshold signature algorithm), the GG18 algorithm (a threshold signature algorithm), the GG20 algorithm (a threshold signature algorithm), and the like.

[0116] Specifically, a distributed system (such as the distributed system 200S shown in FIG2 ) can create a key pair through an asymmetric encryption algorithm. Among them, the asymmetric encryption algorithm may include but is not limited to: Elgamal algorithm (an asymmetric encryption algorithm), Rabin algorithm (an asymmetric encryption algorithm), Diffie-Hellman algorithm (an asymmetric encryption algorithm), ECC algorithm (elliptic curve encryption algorithm). Specifically, the Diffie-Hellman algorithm is a public key encryption algorithm based on the discrete logarithm problem, which allows two nodes to negotiate a common secret without sharing any information. Furthermore, the RSA algorithm is an algorithm that generates a public-private key pair based on large prime numbers and uses these numbers to perform decryption operations. In addition, the ECC algorithm is a public key encryption algorithm based on the elliptic curve discrete logarithm problem, which has the advantages of short key length and high security.

[0117] Specifically, the server can randomly generate a local test private key for key sharding negotiation, and encrypt the local negotiation data (the local negotiation data can be random data) through the local test private key to obtain local test information. Furthermore, the server can obtain a communication channel for communicating with N clients respectively, and send local test information to N clients through each communication channel. Furthermore, the server can receive the target test public key and target test information sent by N clients respectively, and decrypt the target test information belonging to the same client through the target test public key to obtain N target decrypted data. Among them, a target test public key refers to the public key corresponding to the target test private key generated by a client for key sharding negotiation, and a target test information refers to the information obtained by encrypting the target negotiation data through the generated target test private key in a client. For example, if a pair of keys is generated in the client, and the private key in the pair of keys is the target test private key Z1, then the public key in the pair of keys can be the target test public key Z2. On this basis, the target test information Y is the information obtained by encrypting the target negotiation data in the client using the target test private key Z1. This encrypted information can be used to send or transmit within the blockchain node system. Furthermore, the server can decrypt the local test information based on the local test public key corresponding to the local test private key to obtain local decrypted data, and determine the local decrypted data and N target decrypted data as the first hash result. Furthermore, the server can perform a hash operation on the local negotiation data and the N target negotiation data to obtain a second hash result. Furthermore, if the first hash result is equal to the second hash result, it is determined that the key negotiation is successful, and the local test private key is determined as the local private key shard. Furthermore, the server can generate a complete public key during the key shard negotiation process with N clients. Similarly, in N clients, N target private key shards held independently by each client can also be generated using a method similar to that used to generate local private key shards.

[0118] The server can generate a pseudo-random number on the server through a random generation algorithm and use it as a local private key shard of the server. The specific implementation method of generating a pseudo-random number is not limited. For example, a random number seed (true random number) is used as the initial condition, and then the algorithm is used to continuously iterate to generate random numbers. The server can encrypt the local negotiation data through the local test private key. Specifically, the digital signature algorithm corresponding to the encryption process may include but is not limited to: ElGamal (a signature algorithm), Fiat-Shamir (a signature algorithm), Guillou-Quisquarter (a signature algorithm), Schnorr (a signature algorithm), Ong-Schnorr-Shamir (a signature algorithm), elliptic curve digital signature algorithm and finite automaton digital signature algorithm, etc. The local negotiation data refers to the business data that needs to be encrypted in the server. Accordingly, each client can encrypt the target negotiation data through the target test private key corresponding to each client to obtain target test information. The target negotiation data refers to the business data that needs to be encrypted in the client. Furthermore, the target test information belonging to the same client is decrypted using the target test public key corresponding to each client to obtain the target decrypted data corresponding to each client. It should be understood that if the first hash result and the second hash result are equal, it means that the process of encrypting the local negotiation data using the local test private key, decrypting the local test information using the local test public key corresponding to the local test private key, encrypting the target negotiation data using the target test private key, and decrypting the target test information using the target test public key corresponding to the target test private key are all correct.

[0119] Furthermore, the server can generate a target business address based on the complete public key. Furthermore, the server can obtain the addresses to be verified sent by N clients respectively. Among them, the address to be verified sent by one client is generated based on the complete public key. Furthermore, if the target business address is the same as the N addresses to be verified, the target business address is determined to be a legal address, and the target business address is determined to be the address on the application chain. Correspondingly, if there is an address to be verified that is different from the target business address among the N addresses to be verified, the generated target business address and the N addresses to be verified are deleted, and a request to regenerate the address on the application chain is sent to the N clients. Among them, the request to regenerate the address on the application chain is used to instruct the N clients to regenerate a new address to be verified based on the complete public key.

[0120] Specifically, the server can deduce the target business address through the complete public key. Furthermore, if the target business address is the same as the N addresses to be verified obtained, the target business address is determined to be a legal address, and the target business address is determined to be the address on the application chain. Among them, the address on the application chain is the address of the application corresponding to the blockchain business (such as the address of the payment application). For example, if the distributed system 200S in Figure 2 is composed of a client and a server, then if the target business address generated by the server is the same as the address to be verified generated by the client, it means that the target business address is the address of the application corresponding to the blockchain business (such as the payment application on the client). Furthermore, the target business address can be used to locate blockchain data interaction objects in the blockchain node network. For example, in an embodiment of the present application, after the target node (i.e., the server) obtains the complete public key and the address of the game resource account (i.e., the target business address) sent by the game client (i.e., the target client), it can send the complete public key and the address of the game resource account to each node in the blockchain network. After any node receives the complete public key and the address of the game resource account, it can interact with game resource-related data (such as virtual game equipment data that needs to be updated) through the game resource account address. In addition, after receiving the complete public key and the address of the game resource account, the node can also perform consensus processing on the complete public key and the address of the game resource account through the consensus algorithm and then broadcast it to the blockchain network again, and continuously execute the consensus processing until the public key and the address of the game resource account stored by each node reach a consensus. In this way, the consistency of the public key and the address of the game resource account stored by each node can be guaranteed.

[0121] Step S102: Receive signature requests from M-1 clients among N clients, and obtain identity association information in the M-1 signature requests; M is the threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1.

[0122] Specifically, the server can trigger the signing process by receiving signature requests from M-1 clients among N clients. Furthermore, the server can obtain the identity association information in the M-1 signature requests and then perform signature verification for the M-1 clients.

[0123] Specifically, the server can obtain the target shard public keys corresponding to M-1 clients respectively. The target shard public key corresponding to a client is generated based on the target private key shard corresponding to the client. Furthermore, the server can use the M-1 target shard public keys to perform signature verification on the shard signature results sent by M-1 clients respectively, and obtain M-1 signature verification results. A shard signature result refers to the data after a client signs the identity-related information using the target private key shard corresponding to the client. Furthermore, if the M-1 signature verification results are all successful verification results, the identity-related information in the signature request sent by the M-1 clients is authenticated as legitimate.

[0124] Among them, the server can determine the identity of the client by verifying the public key of the target shard. Specifically, the server can associate the client corresponding to the target private key shard that constitutes a complete private key with the server when generating the local private key shard. Thus, the server can verify the association between the client and the server by verifying the public key of the target shard. In other words, the server can verify whether the client and the server belong to the same distributed system corresponding to the same complete public key by verifying the public key of the target shard. If the M-1 signature verification results are all successful verification results, it proves that the server has an association relationship with the client corresponding to the M-1 signature verification results. In other words, the server and the client corresponding to the M-1 signature verification results can constitute a distributed system belonging to the same complete public key (or complete private key).

[0125] Furthermore, if the verification is successful, the server can perform server-side signature processing based on the received signature request. The signature request received by the server is sent by the client that has passed the verification. For a detailed description of the server-side signature processing process, please refer to steps S103 and S104 below.

[0126] Step S103: If the identity association information in the M-1 signature requests is all legal identity information, the client used to initiate the blockchain business among the M-1 clients is determined as the target client, and the business execution data associated with the target client is obtained.

[0127] Specifically, the M-1 clients corresponding to the M-1 signature requests may include client Si, where i is a positive integer less than or equal to M-1. Specifically, the server can obtain the business type of the blockchain business initiated by the M-1 clients, and obtain the identity identifier and identity feature data in the identity association information corresponding to the client Si. Furthermore, the server can determine the identity authentication policy that matches the business type, and select the data that matches the verification dimension indicated by the identity authentication policy from the identity identifier and identity feature data as the data to be verified. Furthermore, if the data to be verified exists in the identity database, the identity association information in the signature request corresponding to the client Si is determined to be legal identity information.

[0128] Among them, the business type may include business query, transfer and account management and other operation types. Specifically, the server can bind the identity identification and identity feature data when the business object registers an account. Specifically, the identity feature data may include but is not limited to features corresponding to multiple key parts. Specifically, the server can determine the identity identification or identity feature information that needs to be verified based on the identity authentication policy matched by the business type. For example, if the server obtains that the business type initiated by the client is a business query (specifically, it can be an account balance query), the server can determine that the identity authentication policy matched by the business type is to verify the identity feature data. Further, the server can select the identity feature data of the business object as the data that matches the verification dimension indicated by the identity authentication policy, that is, the server can select the identity feature data of the business object as the data to be verified. Further, if the identity feature data of the business object exists in the identity database, it is determined that the client S i The identity association information in the corresponding signature request is legal identity information. Among them, the way for the server to verify the identity feature data can be to verify only any one of the multiple key parts. The verification method can be set by the business object in the payment application, and there is no specific restriction on it here. For another example, if the server obtains that the business type initiated by the client is a transfer, the server can determine that the identity authentication strategy matched by the business type is to verify the identity feature data and the identity identifier. Further, the server can select the identity feature data of the business object and the identity identifier of the business object as the data that matches the verification dimension indicated by the identity authentication strategy, that is, the server can select the identity feature data of the business object and the identity identifier of the business object as the data to be verified. Further, if the identity feature data and the identity identifier of the business object both exist in the identity database, it is determined that the client S i The identity association information in the corresponding signature request is legal identity information. Correspondingly, if the identity feature data of the business object and the identity identifier of the business object do not exist in the identity database, it is determined that the client Si The identity association information in the corresponding signature request is illegal identity information, and the server can refuse to respond to the transfer service initiated by the client. It should be understood that the identity authentication strategies listed above are two possible identity authentication strategies. The specific identity authentication strategy in the embodiment of this application can be set by the maintenance object of the payment application and is not specifically limited here. By analogy, it can be understood that among the M-1 clients, except for client S i For the specific process of determining identity association information of other clients other than S, please refer to the above client S i The specific process of determining identity association information is not described here. Further, after verifying the identity association information corresponding to the M-1 clients, if it is determined that the identity association information corresponding to the M-1 clients is all legal identity information, then the identity association information in the M-1 signature requests is determined to be legal identity information.

[0129] Furthermore, if the identity-related information in the M-1 signature requests is all legitimate, the server can obtain the target client's historical business execution data and the target business execution data in the initiated blockchain business, and determine the historical business execution data and the target business execution data as the business execution data associated with the target client. Specifically, the server can obtain data such as the target client's historical business interaction records (e.g., historical transaction records), historical setting changes of the target client, and historical business interaction objects of the target client to determine as the historical business execution data. Furthermore, the server can obtain business information of all clients associated with the blockchain business as the target business execution data. Specifically, the server can determine information such as the business interaction object (e.g., transfer object identifier), business interaction content (e.g., transfer amount), and business interaction address (e.g., transfer object address) as the business information of the client associated with the blockchain business. In other words, the server can determine information such as the business interaction object (e.g., transfer object identifier), business interaction content (e.g., transfer amount), and business interaction address (e.g., transfer object address) as the target business execution data.

[0130] Furthermore, the server can analyze historical business execution data in the business execution data to obtain a historical business operation range, and set a business threshold based on the historical business operation range. Furthermore, if the target business execution data in the business execution data is less than or equal to the business threshold, the business execution data is determined to comply with the risk management policy corresponding to the target client's identity-related information. For example, if the application on the client interacting with the server is a payment application, the server can analyze the historical business execution data in the business execution data to obtain a historical business operation range that can be the payment application's historical transfer limit, and set a transfer threshold (i.e., business threshold) based on the payment application's historical transfer limit. Furthermore, if the target business execution data in the business execution data (i.e., the current transfer limit in the payment application) is less than or equal to the business threshold (i.e., transfer threshold), the business execution data is determined to comply with the risk management policy corresponding to the target client's identity-related information. In other words, the current transfer data of the payment application is determined to comply with the risk management policy corresponding to the target client's identity-related information. For example, the server can set a limit for a single business interaction data transaction within a fixed time period, where the fixed time period can include hours, days, or months. Optionally, the server can set a limit on the number of business interaction data within a fixed time period. Optionally, the server can also implement risk management strategies that limit blockchain business interactions based on specific scenarios pre-set for certain business objects.

[0131] Specifically, the server can obtain the application chain address corresponding to the target client from the business execution data and perform address risk detection on the application chain address. Furthermore, if it is detected that the application chain address exists in the list of legal addresses, the business execution data is determined to comply with the risk management policy corresponding to the target client's identity-related information. Correspondingly, if it is detected that the application chain address does not exist in the list of legal addresses, the application chain address is determined to be a risky address and is prohibited from responding to blockchain businesses initiated by the target client. Among them, by performing address risk detection on the application chain address, the server can filter out blacklist addresses issued by regulatory agencies and addresses of regulated entities, thereby reducing the risk of digital asset business interactions and improving the security of digital asset business interactions.

[0132] Step S104: If the business execution data complies with the risk management policy corresponding to the identity association information of the target client, then participate in the joint signature processing for the blockchain business together with M-1 clients; the joint signature result generated by the joint signature processing is jointly generated based on the local private key shard and the target private key shards held by the M-1 clients respectively, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0133] Specifically, the M-1 clients include the target client. Specifically, the server can receive an intermediate encryption result sent by the target client, which has been encrypted using the target private key shard corresponding to the target client, and sign the received intermediate encryption result using the local private key shard to obtain a server-side signature result. Furthermore, the server can send the server-side signature result to the target client. The server-side signature result is used to instruct the target client to generate a joint signature result.

[0134] Furthermore, the server can receive the business data to be put on the chain sent by the target client. The business data to be put on the chain consists of the target business execution data and the joint signature result in the blockchain business. Furthermore, the server can forward the business data to be put on the chain to the blockchain consensus network, so that the blockchain consensus network verifies the joint signature result based on the complete public key during the consensus process, and when the consensus is passed, the execution result data corresponding to the target business execution data is stored in the blockchain account book. The blockchain account book is used to provide functions such as storage, query and modification of account data, and sends the record data of the operation on the account data to other nodes in the blockchain system (such as the distributed system 200S in Figure 2). After the other nodes verify that it is valid, as a response to acknowledging the validity of the account data, the record data is stored in a temporary block, and a confirmation can also be sent to the node that initiated the operation. A node can refer to any form of computing device connected to the network, such as a server or a client.

[0135] It should be understood that in the embodiment of the present application, the ratio of the number of private key shards held by the server (i.e., one shard) to the total number of private key shards in the distributed system corresponding to the blockchain business is less than or equal to 50%. In other words, the shard share of the private key shards held by the server is less than or equal to 50%. This ensures that if the client does not participate in the joint signature, the server cannot complete the joint signature alone. Therefore, the server cannot use digital assets privately, reducing the risk probability of using digital assets.

[0136] It is understandable that in the specific implementation of this application, when blockchain business data such as associated data of payment applications is applied to specific products or technologies, the collection and processing of relevant data should be strictly in accordance with the requirements of relevant national laws and regulations when applied in the instance, and the informed consent or separate consent of the personal information subject (or with a legal basis) should be obtained, and subsequent data use and processing should be carried out within the scope of authorization of laws and regulations and personal information subjects. When facial (or other biometric) recognition technology is involved, the relevant data collection, use and processing process should comply with the requirements of national laws and regulations. Before collecting facial information, the information processing rules should be informed and the separate consent of the target object should be sought (or with a legal basis). Facial information should be processed in strict accordance with the requirements of laws and regulations and personal information processing rules, and technical measures should be taken to ensure the security of relevant data.

[0137] In an embodiment of the present application, communication channels for communicating with N clients are obtained, and key sharding is negotiated with each of the N clients based on the N communication channels to obtain local private key shards and a complete public key. Furthermore, signature requests are received from M-1 of the N clients, and identity association information in the M-1 signature requests is obtained. Furthermore, if the identity association information in the M-1 signature requests is legitimate, the client among the M-1 clients used to initiate the blockchain service is identified as the target client, and service execution data associated with the target client is obtained. Furthermore, if the service execution data complies with the risk management policy corresponding to the identity association information of the target client, the M-1 clients are jointly involved in a joint signature process for the blockchain service. The joint signature result generated by the joint signature process is generated based on the local private key shard and the target private key shards held by the M-1 clients. The joint signature result is provided to the target client to execute the blockchain service. The embodiment of the present application obtains a local private key shard and a target private key shard through key shard negotiation, and verifies the identity association information of the client or server participating in the signature. After the identity association information is verified as legal identity information, a joint signature process of multiple-end private key shards is performed. It is no longer necessary to use a single private key to perform the digital asset signature process, thereby reducing the probability of signature errors due to private key problems and reducing the risk probability of using digital assets. It should be understood that in the embodiment of the present application, the identity association information of the client can be verified for security, thereby reducing the risk probability of the signing process. Moreover, in the embodiment of the present application, the address on the application chain is detected for address risk through verification of the risk management strategy, and the blacklist addresses and addresses of regulated entities issued by the regulatory unit can be filtered and intercepted, thereby reducing the risk of digital asset business interactions and improving the security of digital asset business interactions. In the embodiment of the present application, the risk probability of using digital assets is reduced.

[0138] Further, please refer to Figure 4, which is a flow chart of another data processing method provided in an embodiment of the present application. As shown in Figure 4, the method can be executed by a client, and the client can be any blockchain node in the blockchain node system shown in Figure 1 above, for example, blockchain node 10a, without limitation here. For ease of understanding, the embodiment of the present application is described as an example of the method being executed by a client. The data processing method can include at least the following steps S201-S204:

[0139] In step S201, the target client obtains a communication channel for communicating with N-1 clients and the server respectively, and performs key sharding negotiation with the server and the N-1 clients based on the communication channel to obtain a target private key shard and a complete public key corresponding to the target client; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the target private key shard corresponding to the target client, the server private key shard, and the target private key shards corresponding to the N-1 clients; the i-th target private key shard among the target private key shards corresponding to the N-1 clients is the private key shard solely held by the i-th client among the N-1 clients after the key sharding negotiation; the server private key shard is the private key shard solely held by the server after the key sharding negotiation.

[0140] Specifically, the target client can conduct a conversation via the acquired communication channel. Broadcasts and message replies during the key negotiation process are performed via this communication channel. Furthermore, the target client can perform key sharding negotiation based on the communication channel to obtain a unique public key. This step represents the response process executed by the client. For details, please refer to the detailed description of step S201 in step S101 of the embodiment corresponding to FIG. 3 , which is executed by the server. Further details are omitted here.

[0141] Step S202: Generate a signature request corresponding to the target client based on the identity association information corresponding to the target client, and send the signature request corresponding to the target client to the server, so that the server can verify the legal identity of the identity association information in the M-1 signature requests received; the M-1 signature requests include the signature request corresponding to the target client; M is the threshold number of private key fragments for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1.

[0142] The specific process of this step can be found in S102 in the embodiment corresponding to FIG. 3 , and will not be described in detail here.

[0143] Step S203: If it is detected that the server determines that the identity association information in the M-1 signature requests is all legal identity information, the service execution data associated with the target client is sent to the server.

[0144] The specific process of this step can be found in S103 in the embodiment corresponding to FIG. 3 , and will not be described in detail here.

[0145] Step S204: If the business execution data complies with the risk management policy corresponding to the identity association information of the target client, the client that initiates the signature request and the server jointly participate in the joint signature processing for the blockchain business; the joint signature result generated by the joint signature processing is based on the target private key shard corresponding to the client that initiates the signature request and the server private key shard, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0146] Furthermore, the M-1 clients include a target client and a signing client. Specifically, if the target client receives a server failure message sent by the server, the target client encrypts the acquired information to be signed through the target private key shard corresponding to the target client to obtain an initial signature result. Furthermore, the target client can send the initial signature result to the signing client, so that the signing client encrypts the initial signature result through the target private key shard corresponding to the signing client to obtain a target signature result. Furthermore, the target client can receive the target signature result sent by the signing client, and generate a joint signature result based on the target signature result. It should be understood that by jointly signing with the target client, when the server is permanently unavailable or the server evidence denies service, the digital assets can be transferred to a new controllable address for blockchain business, thereby ensuring the security of the digital assets and reducing the risk probability of using digital assets.

[0147] Furthermore, the target client can send business data to be uploaded to the server. The business data to be uploaded consists of the target business execution data and the joint signature result in the blockchain business. Furthermore, if the blockchain consensus network successfully verifies the joint signature result based on the complete public key and the consensus on the business data to be uploaded is passed, the target client can receive feedback data from the server regarding the business data to be uploaded, and update the virtual resource data displayed in the blockchain function interface based on the feedback data.

[0148] Specifically, the target client can display a service initiation control, the target client's corresponding application chain address, and virtual resource data in the blockchain functional interface. The virtual resource data represents the service data in the target client's corresponding blockchain service account. Furthermore, the target client can respond to the initiation of a blockchain service operation in the service initiation control in the blockchain functional interface by sending a signature request corresponding to the target client, generated based on the target client's corresponding identity information, to the server for signature processing. The server's signature processing procedures are described in detail in step S104 of FIG. 3 above and are not further elaborated here.

[0149] Please refer to Figure 5, which is a schematic diagram of an interface for a target client provided in an embodiment of the present application. As shown in Figure 5, business device 500a can be a client with a payment application installed in the embodiment of the present application. Furthermore, business device 500a can be blockchain node 10b in Figure 1. Specifically, in Figure 5, client interface 50D is the blockchain function interface. Client interface 50D can include an application chain address 51A corresponding to the target client. For example, application chain address 51A corresponding to the target client can be the address of the client corresponding to the payment application. Furthermore, client interface 50D can display controls corresponding to core functions. For example, the transfer-out control 52G shown in Figure 5 can be used to initiate a transfer-out process for the account balance corresponding to the current payment application. Correspondingly, the transfer-in control 53G can be used to initiate a transfer-in process for the account balance corresponding to the current payment application. Correspondingly, the exchange control 54G can be used to initiate an exchange process for a digital asset type (e.g., a digital asset category commonly used in different regions) corresponding to the account balance corresponding to the current payment application. For example, if the digital asset types in Region W and Region V differ, the exchange control 54G can be used to convert the payment application account balance between the digital asset types in Region W and Region V. Furthermore, the client interface 50D can display virtual resource data. For example, the virtual resource data can be digital collections 55S and 56S as shown in Figure 5 . Different digital collections can have different digital collection identifiers. Specifically, other digital collections in the payment application can be viewed by triggering the area containing the virtual resource data. Triggering operations can include clicking, double-clicking, long pressing, zooming in and out, etc., which are not specifically limited here. These triggering operations can be set in the function menu 57D of the client interface 50D. Furthermore, the client interface 50D can display a function menu 57D, which can be used to perform functions corresponding to the payment application, such as account switching, account copying, account recovery, and account hosting. Specifically, the triggering operations here can also refer to the triggering operations described above and are not specifically limited here. Furthermore, client interface 50D can display blockchain network status 58D and switch blockchain networks by triggering operations on the area corresponding to blockchain network status 58D. The specific triggering operations are not limited here. Furthermore, client interface 50D can display a service initiation control 59D, which can be used to initiate blockchain business operations. For example, service initiation control 59D can initiate blockchain business operations by scanning a code using the camera of the hardware device corresponding to the payment application. Furthermore, client interface 50D can also display data such as the current time and the battery level of the hardware device corresponding to the payment application.

[0150] In an embodiment of the present application, a target client obtains a communication channel for communicating with N-1 clients and a server, performs key sharding negotiation with the server and N-1 clients based on the communication channel, and obtains a target private key shard and a complete public key corresponding to the target client. Furthermore, a signature request corresponding to the target client is generated based on the identity information associated with the target client, and the signature request corresponding to the target client is sent to the server, so that the server verifies the legality of the identity information in the M-1 signature requests received. Furthermore, if the server determines that the identity information in the M-1 signature requests is legal, it sends service execution data associated with the target client to the server. Furthermore, if the service execution data complies with the risk management policy corresponding to the identity information associated with the target client, it participates in a joint signature process for a blockchain service with the client that initiated the signature request and the server. The joint signature result generated by the joint signature process is generated based on the target private key shard corresponding to the client that initiated the signature request and the server's private key shard. The joint signature result is provided to the target client to execute the blockchain service. In the embodiment of the present application, a local private key shard and a target private key shard are obtained through key shard negotiation, and identity association information is verified for the client or server participating in the signature. After the identity association information is verified as legal identity information, a joint signature process of multiple private key shards is performed. This eliminates the need to use a single private key to perform the digital asset signature process, thereby reducing the probability of signature errors due to private key problems and the risk probability of using digital assets. It should be understood that in the embodiment of the present application, identity association information verification can be performed to enable the server to detect the client's identity information. If the identity information provided by the client does not match the identity information stored in the server's identity database, the client's signature request is intercepted, thereby improving the server's security control over the signing process and reducing the risk probability of using digital assets. Moreover, in the embodiment of the present application, address risk detection is performed on the application chain address through verification of the risk management strategy, and the blacklist addresses and addresses of regulated entities issued by the regulatory unit can be filtered and intercepted, thereby reducing the risk of digital asset business interaction and reducing the risk probability of using digital assets. Furthermore, if a server-side device problem occurs, the present embodiment can be used to sign via two clients, thereby bypassing the failed server-side signature processing. This improves the distributed system's ability to cope with risks and increases the security of the distributed system for blockchain services. In the present embodiment, the risk probability of using digital assets is reduced.

[0151] Further, please refer to Figure 6, which is an interactive flow chart for digital asset signatures provided in an embodiment of the present application. As shown in Figure 6, the method can be executed by a computer device, and the computer device may include the client 600a or the server 610 in Figure 6. Specifically, the client 600a can be any blockchain node in the blockchain node system shown in Figure 1 above, for example, blockchain node 10a, and the server 610 can be the blockchain node 10b shown in Figure 1 above, which is not limited here. For ease of understanding, the embodiment of the present application is explained by taking the method executed by a computer device as an example. The data processing method can at least include the following steps S60-S68:

[0152] Step S60: Acquire communication channels for communicating with N clients respectively.

[0153] The specific process of this step can be found in S101 in the embodiment corresponding to FIG3 , and will not be described in detail here.

[0154] Step S61: Perform key sharding negotiation with N clients based on N communication channels respectively.

[0155] The specific process of this step can be found in S101 in the embodiment corresponding to FIG3 , and will not be described in detail here.

[0156] Step S62: Obtain the local private key fragments and the complete public key.

[0157] The specific process of this step can be found in S101 in the embodiment corresponding to FIG3 , and will not be described in detail here.

[0158] Step S63: Obtain the target private key fragment and the complete public key.

[0159] The specific process of this step can be found in S201 in the embodiment corresponding to FIG. 4 , and will not be described in detail here.

[0160] Step S64: Obtain the target shard public key, and verify the client's shard signature result using the target shard public key.

[0161] The specific process of this step can be found in S101 in the embodiment corresponding to FIG3 , and will not be described in detail here.

[0162] Step S65: Obtain the local shard public key and verify the server's shard signature result using the local shard public key.

[0163] The specific process of this step can be found in S201 in the embodiment corresponding to FIG. 4 , and will not be described in detail here.

[0164] Step S66: If all the M-1 signature verification results are successful, then the identity association information in the signature requests sent by the M-1 clients is subjected to legal identity verification.

[0165] The specific process of this step can be found in S101 in the embodiment corresponding to FIG3 , and will not be described in detail here.

[0166] Step S67: If the identity association information in the M-1 signature requests is all legal identity information, then obtain the service execution data associated with the target client.

[0167] The specific process of this step can be found in S103 in the embodiment corresponding to FIG. 3 , and will not be described in detail here.

[0168] Step S68: If the business execution data complies with the risk management policy, a joint signature process is performed.

[0169] The specific process of this step can be found in S104 in the embodiment corresponding to FIG. 3 , and will not be described in detail here.

[0170] Optionally, the client can be one or more, that is, N can be greater than or equal to 1, and the specific value of N is determined by the number of participants in the complete private key corresponding to the complete public key requested by the business object in the application client (such as the payment application). Here, an example is taken in which 4 clients and 1 server jointly participate in the signature of the payment application, that is, the business object requests 5 participants to hold private key shards respectively (that is, one local private key shard and four target private key shards). In other words, the server can negotiate key shards with the 4 clients respectively to generate five independent private key shards (that is, a local private key shard corresponding to 1 server and a target private key shard corresponding to 4 clients). It should be understood that the generated private key shard is only known inside the device that generates the private key shard, and is held solely by the device that generates the private key shard and will not be disclosed to the outside. If the number of participants required to constitute a complete private key is 3, then the participants can be a server and two clients. For example, one server is the service backend, and the two clients can be a mobile phone and a computer (PC) respectively. Specifically, the process of joint signing can refer to the joint signing process in Figures 3 and 4 above, and will be deduced by analogy, so it will not be repeated here.

[0171] It should be understood that in the embodiments of the present application, by setting a threshold for the number of private key shards and combining it with a centralized risk management strategy centered on the server, it has more prominent advantages than existing centralized hosting signature schemes and existing decentralized hosting signature schemes. Through the risk management strategy on the server side, it can lower the threshold for business objects to use applications corresponding to blockchain services (such as payment applications), thereby increasing the convenience of using applications corresponding to blockchain services. Moreover, the joint signing method of the target client and the signing client in the embodiments of the present application can ensure the autonomy and controllability of the business object over the digital assets, reducing the risk probability of using digital assets.

[0172] In an embodiment of the present application, communication channels for communicating with N clients are obtained, and key sharding is negotiated with each of the N clients based on the N communication channels to obtain local private key shards and a complete public key. Furthermore, signature requests are received from M-1 of the N clients, and identity association information in the M-1 signature requests is obtained. Furthermore, if the identity association information in the M-1 signature requests is legitimate, the client among the M-1 clients used to initiate the blockchain service is identified as the target client, and service execution data associated with the target client is obtained. Furthermore, if the service execution data complies with the risk management policy corresponding to the identity association information of the target client, the M-1 clients are jointly involved in a joint signature process for the blockchain service. The joint signature result generated by the joint signature process is generated based on the local private key shard and the target private key shards held by the M-1 clients. The joint signature result is provided to the target client to execute the blockchain service. In the embodiment of the present application, the local private key shard and the target private key shard are obtained by negotiating the key shards, and the identity association information of the client or server participating in the signature is verified. After the identity association information is verified as legal identity information, the joint signature processing of the multi-terminal private key shards is performed. It is no longer necessary to use a single private key to perform the digital asset signature processing process, thereby reducing the probability of signature errors due to private key problems and reducing the risk probability of using digital assets. It should be understood that in the embodiment of the present application, the identity association information of the client can be verified for security by performing identity association information verification, thereby reducing the risk probability of using digital assets. Moreover, in the embodiment of the present application, the address risk detection is performed on the address on the application chain through the verification of the risk management strategy, and the blacklist addresses issued by the regulatory unit and the addresses of the regulated entities can be filtered and intercepted, thereby reducing the risk of digital asset business interactions. In the embodiment of the present application, the risk probability of using digital assets is reduced.

[0173] Further, please refer to Figure 7, which is a schematic diagram of the structure of a data processing device provided in an embodiment of the present application. The above-mentioned data processing device can be a computer program (including program code) running in a computer device, for example, the data processing device is an application software; the device can be used to execute the corresponding steps of the method provided in the embodiment of the present application. As shown in Figure 7, the data processing device 1 is applied to the business management platform, and the data processing device 1 may include: a local private key shard acquisition module 11, an identity association information acquisition module 12, a target client determination module 13, a business execution data acquisition module 14 and a first joint signature module 15.

[0174] The local private key shard acquisition module 11 is configured to acquire communication channels for communicating with N clients respectively, and perform key shard negotiation with the N clients based on the N communication channels to obtain local private key shards and a complete public key; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the local private key shard and the N target private key shards; the i-th target private key shard among the N target private key shards is the private key shard exclusively held by the i-th client among the N clients after the key shard negotiation;

[0175] The identity association information acquisition module 12 is configured to receive signature requests sent by M-1 clients among N clients and obtain the identity association information in the M-1 signature requests; M is a threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1;

[0176] The target client determination module 13 is configured to determine the client used to initiate the blockchain service among the M-1 clients as the target client if the identity association information in the M-1 signature requests is all legal identity information;

[0177] A service execution data acquisition module 14 is used to acquire service execution data associated with a target client;

[0178] The first joint signature module 15 is used to participate in the joint signature processing for the blockchain business with M-1 clients if the business execution data complies with the risk management policy corresponding to the identity association information of the target client; the joint signature result generated by the joint signature processing is jointly generated based on the local private key shard and the target private key shards held by the M-1 clients respectively, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0179] Among them, the specific functional implementation methods of the local private key shard acquisition module 11, the identity association information acquisition module 12, the target client determination module 13, the business execution data acquisition module 14 and the first joint signature module 15 can be referred to steps S101 to S104 in the embodiment corresponding to Figure 3 above, and will not be repeated here.

[0180] Referring again to FIG. 7 , the local private key shard acquisition module 11 includes:

[0181] A local test private key generation unit 111 is configured to randomly generate a local test private key for key sharding negotiation, and encrypt local negotiation data using the local test private key to obtain local test information.

[0182] The communication channel acquisition unit 112 is configured to acquire communication channels for communicating with N clients respectively, and send local test information to the N clients via each communication channel;

[0183] The target decrypted data acquisition unit 113 is configured to receive target test public keys and target test information respectively sent by N clients, and decrypt the target test information belonging to the same client using the target test public key to obtain N target decrypted data. A target test public key refers to a public key corresponding to a target test private key generated by a client for key sharding negotiation, and a target test information refers to information obtained by encrypting target negotiation data using the target test private key generated by a client.

[0184] A first hash result determining unit 114 is configured to decrypt the local test information based on the local test public key corresponding to the local test private key to obtain local decrypted data, and determine the local decrypted data and the N target decrypted data as a first hash result;

[0185] A second hash result obtaining unit 115 is configured to perform a hash operation on the local negotiation data and the N target negotiation data to obtain a second hash result;

[0186] a local private key fragment determination unit 116, configured to determine that the key agreement is successful if the first hash result is equal to the second hash result, and determine the local test private key as the local private key fragment;

[0187] The complete public key generation unit 117 is configured to generate a complete public key during the key sharding negotiation process with N clients.

[0188] Among them, the specific functional implementation methods of the local test private key generation unit 111, the communication channel acquisition unit 112, the target decryption data acquisition unit 113, the first hash result determination unit 114, the second hash result acquisition unit 115, the local private key shard determination unit 116 and the complete public key generation unit 117 can be referred to step S101 in the corresponding embodiment of Figure 3 above, and will not be repeated here.

[0189] Referring again to FIG. 7 , the data processing device 1 further includes:

[0190] The target shard public key acquisition module 16 is used to obtain the target shard public keys corresponding to M-1 clients respectively; the target shard public key corresponding to a client is generated based on the target private key shard corresponding to the client;

[0191] The signature verification module 17 is used to perform signature verification on the shard signature results sent by M-1 clients using M-1 target shard public keys, and obtain M-1 signature verification results. A shard signature result refers to the data after a client signs the identity association information using the target private key shard corresponding to the client;

[0192] The legal identity verification module 18 is configured to perform legal identity verification on the identity association information in the signature requests sent by the M-1 clients if all the M-1 signature verification results are successful.

[0193] Among them, the specific functional implementation of the target shard public key acquisition module 16, the signature verification module 17 and the legal identity authentication module 18 can be found in step S101 in the embodiment corresponding to Figure 3 above, and will not be repeated here.

[0194] Please refer to Figure 7 again, where M-1 clients include client S i , i is a positive integer less than or equal to M-1; the legal identity authentication module 18 includes:

[0195] The business type acquisition unit 181 is used to obtain the business type of the blockchain business initiated by the M-1 clients, and obtain the identity identifier and identity feature data from the identity association information corresponding to the client Si;

[0196] The identity authentication policy determination unit 182 is configured to determine the identity authentication policy that matches the service type, and select, from the identity identifier and identity feature data, data that matches the verification dimension indicated by the identity authentication policy as data to be verified;

[0197] The legal identity information determining unit 183 is configured to determine that the identity association information in the signature request corresponding to the client Si is legal identity information if the data to be verified exists in the identity database.

[0198] The specific functional implementation of the service type acquisition unit 181 , the identity authentication policy determination unit 182 and the legal identity information determination unit 183 can be found in step S101 in the embodiment corresponding to FIG3 , which will not be described in detail here.

[0199] Referring again to FIG. 7 , the service execution data acquisition module 14 is specifically configured to acquire the historical service execution data of the target client and the target service execution data in the initiated blockchain service, and determine the historical service execution data and the target service execution data as the service execution data associated with the target client.

[0200] The data processing device 1 further includes:

[0201] A service threshold setting module 19 is configured to analyze historical service execution data in the service execution data to obtain a historical service operation range, and set a service threshold based on the historical service operation range;

[0202] The risk management policy determination module 20 is configured to determine that the service execution data complies with the risk management policy corresponding to the identity association information of the target client if the target service execution data in the service execution data is less than or equal to the service threshold.

[0203] The specific functional implementation of the service threshold setting module 19 and the risk management strategy determination module 20 can be found in step S101 in the embodiment corresponding to FIG. 3 , and will not be described in detail here.

[0204] Referring again to FIG. 7 , the data processing device 1 further includes:

[0205] The address risk detection module 21 is used to obtain the application chain address corresponding to the target client from the business execution data and perform address risk detection on the application chain address;

[0206] The first address detection module 22 is configured to determine whether the service execution data complies with the risk management policy corresponding to the identity association information of the target client if it is detected that the address on the application chain exists in the legal address list;

[0207] The second address detection module 23 is used to determine that the address on the application chain is a risky address if it is detected that the address on the application chain does not exist in the legal address list, and prohibit responding to the blockchain business initiated by the target client.

[0208] The specific functional implementation of the address risk detection module 21 , the first address detection module 22 and the second address detection module 23 can be found in step S101 in the embodiment corresponding to FIG. 3 , which will not be described in detail here.

[0209] Referring again to FIG. 7 , M-1 clients include the target client; the first joint signature module 15 includes:

[0210] The server-side signature result obtaining unit 151 is configured to receive an intermediate encryption result sent by a target client after being encrypted using the target private key fragment corresponding to the target client, and to sign the received intermediate encryption result using the local private key fragment to obtain a server-side signature result;

[0211] The joint signature result generating unit 152 is used to send the server signature result to the target client; the server signature result is used to instruct the target client to generate a joint signature result.

[0212] Among them, the specific functional implementation of the server-side signature result acquisition unit 151 and the joint signature result generation unit 152 can be found in step S104 of the embodiment corresponding to Figure 3 above, and will not be repeated here.

[0213] Referring again to FIG. 7 , the data processing device 1 further includes:

[0214] The business data receiving module 24 is used to receive the business data to be uploaded to the blockchain sent by the target client; the business data to be uploaded to the blockchain consists of the target business execution data and the joint signature result in the blockchain business;

[0215] The business data forwarding module 25 is used to forward the business data to be uploaded to the blockchain consensus network, so that the blockchain consensus network can verify the joint signature result based on the complete public key during the consensus process. When the consensus is passed, the execution result data corresponding to the target business execution data is stored in the blockchain account book.

[0216] The specific functional implementation of the service data receiving module 24 and the service data forwarding module 25 can be found in step S104 in the embodiment corresponding to FIG. 3 , and will not be described in detail here.

[0217] Referring again to FIG. 7 , the data processing device 1 further includes:

[0218] A target business address generation module 26, configured to generate a target business address based on the complete public key;

[0219] The to-be-verified address acquisition module 27 is used to acquire the to-be-verified addresses sent by N clients respectively; the to-be-verified address sent by a client is generated based on the complete public key;

[0220] A legal address determination module 28 is configured to determine that the target business address is a legal address if the target business address is the same as the N addresses to be verified, and to determine the target business address as an address on the application chain;

[0221] The address deletion module 29 is used to delete the generated target business address and the N addresses to be verified if there is an address to be verified that is different from the target business address among the N addresses to be verified, and send a request to regenerate the address on the application chain to the N clients; the request to regenerate the address on the application chain is used to instruct the N clients to regenerate a new address to be verified based on the complete public key.

[0222] Among them, the specific functional implementation of the target business address generation module 26, the to-be-verified address acquisition module 27, the legal address determination module 28 and the to-be-verified address deletion module 29 can be found in step S104 of the embodiment corresponding to FIG3 above, and will not be repeated here.

[0223] Further, please refer to Figure 8, which is a schematic diagram of the structure of a data processing device provided in an embodiment of the present application. The above-mentioned data processing device can be a computer program (including program code) running on a computer device, for example, the data processing device is an application software; the device can be used to execute the corresponding steps of the method provided in the embodiment of the present application. As shown in Figure 8, the data processing device 3 is applied to the business management platform, and the data processing device 3 can include: a target private key shard acquisition module 31, a signature request sending module 32, a business execution data sending module 33, and a second joint signature module 34.

[0224] The target private key shard acquisition module 31 is configured to cause a target client to acquire a communication channel for communicating with N-1 clients and a server, respectively, and to perform key shard negotiation with the server and the N-1 clients based on the communication channel to obtain a target private key shard and a complete public key corresponding to the target client. N is a positive integer greater than 1. The complete public key is a unique public key corresponding to the target private key shard corresponding to the target client, the server private key shard, and the target private key shards corresponding to the N-1 clients. The i-th target private key shard among the target private key shards corresponding to the N-1 clients is the private key shard solely held by the i-th client among the N-1 clients after the key shard negotiation. The server private key shard is the private key shard solely held by the server after the key shard negotiation.

[0225] The signature request sending module 32 is configured to generate a signature request corresponding to the target client based on the identity association information corresponding to the target client, and send the signature request corresponding to the target client to the server, so that the server can authenticate the legality of the identity association information in the M-1 signature requests received; the M-1 signature requests include the signature request corresponding to the target client; M is a threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1;

[0226] The service execution data sending module 33 is configured to send the service execution data associated with the target client to the server if it is detected that the identity association information in the M-1 signature requests determined by the server is all legal identity information;

[0227] The second joint signature module 34 is used to participate in the joint signature processing for the blockchain business together with the client that initiates the signature request and the server if the business execution data complies with the risk management policy corresponding to the identity association information of the target client; the joint signature result generated by the joint signature processing is jointly generated based on the target private key shard corresponding to the client that initiates the signature request and the server private key shard, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0228] Among them, the specific functional implementation methods of the target private key shard acquisition module 31, the signature request sending module 32, the business execution data sending module 33 and the second joint signature module 34 can be referred to steps S201 to S204 in the embodiment of Figure 4 above, and will not be repeated here.

[0229] Referring again to FIG8 , the M-1 clients include the target client and the signing client; the data processing device 3 further includes:

[0230] The first encryption module 35 is configured to encrypt the acquired information to be signed using the target private key fragment corresponding to the target client upon receiving the server fault information sent by the server to obtain an initial signature result;

[0231] The second encryption module 36 is used to send the initial signature result to the signing client, so that the signing client encrypts the initial signature result using the target private key fragment corresponding to the signing client to obtain the target signature result;

[0232] The target signature result receiving module 37 is used to receive the target signature result sent by the signature client and generate a joint signature result based on the target signature result.

[0233] The specific functional implementation of the first encryption module 35, the second encryption module 36 and the target signature result receiving module 37 can be found in step S201 of the embodiment of FIG4 above, which will not be described in detail here.

[0234] The signature request sending module 32 includes:

[0235] The data display unit 321 is used to display the business initiation control, the application chain address corresponding to the target client, and the virtual resource data in the blockchain function interface; the virtual resource data is used to represent the business data in the blockchain business account corresponding to the target client;

[0236] The operation response unit 322 is used to respond to the initiation of a blockchain business operation for the business initiation control in the blockchain function interface, and send a signature request corresponding to the target client generated based on the identity association information corresponding to the target client to the server;

[0237] The specific functional implementation of the data display unit 321 and the operation response unit 322 can refer to step S202 in the embodiment of FIG. 4 , and will not be described in detail here.

[0238] The data processing device 3 further includes:

[0239] The data sending module 38 sends the business data to be uploaded to the server. The business data to be uploaded consists of the target business execution data and the joint signature result in the blockchain business.

[0240] The feedback data receiving module 39 is used to receive feedback data sent by the server for the business data to be uploaded if the blockchain consensus network successfully verifies the joint signature result based on the complete public key and the consensus on the business data to be uploaded is passed, and update the virtual resource data displayed in the blockchain function interface based on the feedback data.

[0241] The specific functional implementation of the data sending module 38 and the feedback data receiving module 39 can be found in step S201 of the embodiment of FIG. 4 , and will not be described in detail here.

[0242] Further, please refer to Figure 9, which is a structural diagram of a computer device provided in an embodiment of the present application. As shown in Figure 9, the computer device 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, a memory 1005, and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, the user interface 1003 may include a display screen (Display), a keyboard (Keyboard), and the network interface 1004 may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 1005 may optionally also be at least one storage device located away from the aforementioned processor 1001. As shown in Figure 9, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application.

[0243] In the computer device 1000 shown in FIG9 , the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an interface for user input; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0244] Obtain communication channels for communicating with N clients respectively, and negotiate key shards with the N clients based on the N communication channels to obtain local private key shards and complete public keys; N is a positive integer greater than 1; the complete public key is the unique public key corresponding to the local private key shard and the N target private key shards; the i-th target private key shard among the N target private key shards is the private key shard held solely by the i-th client among the N clients after the key shard negotiation; receive signature requests sent by M-1 clients among the N clients, and obtain identity association information in the M-1 signature requests; M is the threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1; if the identity association information in the M-1 signature requests is all legitimate identity information, then determine the client used to initiate the blockchain business among the M-1 clients as the target client, and obtain business execution data associated with the target client; if the business execution data complies with the risk management policy corresponding to the identity association information of the target client, then jointly participate in the joint signature processing for the blockchain business with the M-1 clients; The joint signature result generated by the joint signature processing is jointly generated based on the local private key shard and the target private key shards held by M-1 clients. The joint signature result is used to provide to the target client to execute blockchain business.

[0245] In the computer device 1000 shown in FIG9 , the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an interface for user input; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0246] The target client obtains a communication channel for communicating with N-1 clients and the server respectively, and negotiates key shards with the server and N-1 clients based on the communication channel to obtain the target private key shard and complete public key corresponding to the target client; N is a positive integer greater than 1; the complete public key is the unique public key corresponding to the target private key shard corresponding to the target client, the server private key shard, and the target private key shards corresponding to the N-1 clients; the i-th target private key shard in the target private key shard corresponding to the N-1 clients is the private key shard held solely by the i-th client in the N-1 clients after the key shard negotiation; the server private key shard is the private key shard held solely by the server after the key shard negotiation; a signature request corresponding to the target client is generated based on the identity association information corresponding to the target client, and the signature request corresponding to the target client is sent to the server , so that the server can authenticate the legality of the identity-related information in the M-1 signature requests received; the M-1 signature requests include the signature request corresponding to the target client; M is the threshold number of private key shards for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1; if it is detected that the server determines that the identity-related information in the M-1 signature requests are all legal identity information, the service execution data associated with the target client is sent to the server; if the service execution data complies with the risk management policy corresponding to the identity-related information of the target client, the client that initiates the signature request and the server jointly participate in the joint signature processing for the blockchain business; the joint signature result generated by the joint signature processing is jointly generated based on the target private key shard corresponding to the client that initiates the signature request and the server private key shard, and the joint signature result is used to provide to the target client to execute the blockchain business.

[0247] It should be understood that the computer device 1000 described in the embodiments of the present application can execute the data processing methods described in the embodiments corresponding to Figures 2, 3, 4, 5, and 6 above, can also execute the data processing device 1 described in the embodiment corresponding to Figure 7 above, and can also execute the data processing device 3 described in the embodiment corresponding to Figure 8 above, and the description thereof will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0248] The present application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions. When the program instructions are executed by a processor, the data processing method provided in each step of FIG. 2 , FIG. 3 , FIG. 4 , FIG. 5 , and FIG. 6 is implemented. For details, please refer to the implementation methods provided in each step of FIG. 2 , FIG. 3 , FIG. 4 , FIG. 5 , and FIG. 6 , which will not be described in detail here. Furthermore, the description of the beneficial effects of using the same method will not be repeated here.

[0249] The computer-readable storage medium may be the data processing device provided in any of the aforementioned embodiments or the internal storage unit of the computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device. Furthermore, the computer-readable storage medium may also include both the internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

[0250] The present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, so that the computer device can perform the description of the data processing method in the embodiments corresponding to Figures 2, 3, 4, 5, and 6 above, which will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0251] The term "comprising" and any variations thereof in the description, claims, and drawings of the embodiments of this application are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps and modules inherent to the process, method, apparatus, product, or device.

[0252] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0253] The method and related apparatus provided in the embodiment of the present application are described with reference to the method flow chart and / or structural diagram provided in the embodiment of the present application, and specifically can be implemented by computer program instructions for each process and / or box of the method flow chart and / or structural diagram, and the combination of the process and / or box in the flow chart and / or block diagram. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the function specified in one process or multiple processes of the flow chart and / or one box or multiple boxes of the structural diagram. These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device, and the instruction device implements the function specified in one process or multiple processes of the flow chart and / or one box or multiple boxes of the structural diagram. These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the structural diagram.

[0254] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A data processing method based on blockchain key, characterized in that: include: Acquire communication channels for communicating with N clients respectively, and perform key sharding negotiation with the N clients respectively based on the N communication channels to obtain local private key shards and a complete public key; N is a positive integer greater than 1; The complete public key is the unique public key corresponding to the local private key fragment and the N target private key fragments; The i-th target private key shard among the N target private key shards is a private key shard held solely by the i-th client among the N clients after negotiation through the key shards; Receive signature requests sent by M-1 clients among the N clients, and obtain identity association information in the M-1 signature requests; M is a threshold number of private key fragments for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1; If the identity-related information in the M-1 signature requests is all legal identity information, the client used to initiate the blockchain service among the M-1 clients is determined as the target client, and the service execution data associated with the target client is obtained; If the business execution data complies with the risk management policy corresponding to the identity association information of the target client, then the joint signature processing for the blockchain business is jointly participated in with the M-1 clients; the joint signature result generated by the joint signature processing is jointly generated based on the local private key shard and the target private key shards held by the M-1 clients respectively, and the joint signature result is used to provide to the target client to execute the blockchain business.

2. The method according to claim 1, characterized in that The method further comprises: Obtain the target shard public keys corresponding to the M-1 clients respectively; the target shard public key corresponding to a client is generated based on the target private key shard corresponding to the client; The shard signature results sent by the M-1 clients are respectively signed and verified by using the M-1 target shard public keys to obtain M-1 signature verification results; one shard signature result refers to the data after a client signs the identity association information by using the target private key shard corresponding to the client; If the M-1 signature verification results are all successful verification results, the identity association information in the signature requests sent by the M-1 clients is subjected to legal identity verification.

3. The method according to claim 1 or 2, characterized in that: The M-1 clients include client Si, where i is a positive integer less than or equal to M-1; performing legal identity authentication on the identity association information in the signature request sent by the M-1 clients includes: Obtain the business type of the blockchain business initiated by the M-1 clients, and obtain the identity identifier and identity feature data in the identity association information corresponding to the client Si; Determine the identity authentication policy that matches the business type, and select data that matches the verification dimension indicated by the identity authentication policy from among the identity identifier and the identity feature data as data to be verified; If the data to be verified exists in the identity database, it is determined that the client S i The identity association information in the corresponding signature request is legal identity information.

4. The method according to any one of claims 1 to 3, characterized in that: The acquiring of the service execution data associated with the target client includes: Acquire historical service execution data of the target client and target service execution data in the initiated blockchain service, and determine the historical service execution data and the target service execution data as service execution data associated with the target client; The method further comprises: Performing data analysis on historical business execution data in the business execution data to obtain a historical business operation range, and setting a business threshold based on the historical business operation range; If the target service execution data in the service execution data is less than or equal to the service threshold, it is determined that the service execution data complies with the risk management policy corresponding to the identity association information of the target client.

5. The method according to any one of claims 1 to 4, characterized in that: Also includes: Obtaining the address on the application chain corresponding to the target client from the business execution data, and performing address risk detection on the address on the application chain; If it is detected that the address on the application chain exists in the legal address list, it is determined that the business execution data complies with the risk management policy corresponding to the identity association information of the target client; If it is detected that the address on the application chain does not exist in the list of legal addresses, the address on the application chain is determined to be a risky address, and responding to the blockchain business initiated by the target client is prohibited.

6. The method according to any one of claims 1 to 5, characterized in that: The participating in the joint signature processing for the blockchain service together with the M-1 clients includes: Receive the intermediate encrypted structure sent by the target client after being encrypted by the target private key fragment corresponding to the target client; The received intermediate encryption result is signed by the local private key fragment to obtain the server-side signature result; The server-side signature result is sent to the target client; the server-side signature result is used to instruct the target client to generate a joint signature result.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: Receive the business data to be uploaded to the chain sent by the target client; The business data to be uploaded to the blockchain consists of the target business execution data in the blockchain business and the joint signature result; The business data to be uploaded to the chain is forwarded to the blockchain consensus network, so that the blockchain consensus network verifies the joint signature result based on the complete public key during the consensus process. When the consensus is passed, the execution result data corresponding to the target business execution data is stored in the blockchain account book.

8. The method according to any one of claims 1 to 7, characterized in that: Also includes: Generate a target business address based on the complete public key; Obtaining the addresses to be verified respectively sent by the N clients; The address to be verified sent by a client is generated based on the complete public key; If the target business address is the same as the N addresses to be verified, the target business address is determined to be a legal address, and the target business address is determined as the address on the application chain; If there is an address to be verified that is different from the target business address among the N addresses to be verified, the generated target business address and the N addresses to be verified are deleted, and a request to regenerate the address on the application chain is sent to the N clients; the request to regenerate the address on the application chain is used to instruct the N clients to regenerate a new address to be verified based on the complete public key.

9. The method according to any one of claims 1 to 8, characterized in that: The obtaining of communication channels for communicating with N clients respectively, performing key sharding negotiation with the N clients respectively based on the N communication channels, and obtaining local private key shards and a complete public key, includes: Randomly generate a local test private key for key sharding negotiation, encrypt local negotiation data using the local test private key, and obtain local test information; Acquire communication channels for communicating with N clients respectively, and send the local test information to the N clients through each communication channel; Receive the target test public keys and target test information respectively sent by the N clients, decrypt the target test information belonging to the same client by using the target test public key, and obtain N target decrypted data; one target test public key refers to a public key corresponding to a target test private key generated by a client for key sharding negotiation, and one target test information refers to information obtained by encrypting target negotiation data by using the generated target test private key in a client; Decrypt the local test information based on the local test public key corresponding to the local test private key to obtain local decrypted data, and determine the local decrypted data and the N target decrypted data as a first hash result; Performing a hash operation on the local negotiation data and the N target negotiation data to obtain a second hash result; If the first hash result is equal to the second hash result, it is determined that the key negotiation is successful, and the local test private key is determined as a local private key fragment; A complete public key is generated during the key sharding negotiation with the N clients.

10. A data processing method based on blockchain key, characterized in that: The method is executed by a target client for initiating a blockchain service, and the method includes: The target client obtains a communication channel for communicating with N-1 clients and a server respectively, and performs key sharding negotiation with the server and the N-1 clients based on the communication channel to obtain a target private key shard and a complete public key corresponding to the target client; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the target private key shard corresponding to the target client, the server private key shard and the target private key shard corresponding to the N-1 clients; the i-th target private key shard among the target private key shards corresponding to the N-1 clients is a private key shard held solely by the i-th client among the N-1 clients after the key sharding negotiation; the server private key shard is a private key shard held solely by the server after the key sharding negotiation; Generate a signature request corresponding to the target client based on the identity association information corresponding to the target client, and send the signature request corresponding to the target client to the server, so that the server performs legal identity authentication on the identity association information in the received M-1 signature requests; the M-1 signature requests include the signature request corresponding to the target client; M is a threshold value of the number of private key fragments for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1; If it is detected that the server determines that the identity association information in the M-1 signature requests are all legal identity information, then the service execution data associated with the target client is sent to the server; If the business execution data complies with the risk management policy corresponding to the identity association information of the target client, then the client that initiates the signature request and the server jointly participate in the joint signature processing for the blockchain business; the joint signature result generated by the joint signature processing is jointly generated based on the target private key shard corresponding to the client that initiates the signature request and the server private key shard, and the joint signature result is used to provide to the target client to execute the blockchain business.

11. The method according to claim 10, characterized in that The M-1 clients include the target client and the signing client; the method further includes: If the server failure information sent by the server is received, the acquired information to be signed is encrypted by using the target private key fragment corresponding to the target client to obtain an initial signature result; Sending the initial signature result to the signing client, so that the signing client encrypts the initial signature result through the target private key fragment corresponding to the signing client to obtain a target signature result; Receive the target signature result sent by the signature client, and generate the joint signature result based on the target signature result.

12. The method according to claim 10 or 11, characterized in that: The step of generating a signature request corresponding to the target client based on the identity association information corresponding to the target client, and sending the signature request corresponding to the target client to the server includes: Displaying the business initiation control, the application chain address and virtual resource data corresponding to the target client in the blockchain function interface; the virtual resource data is used to represent the business data in the blockchain business account corresponding to the target client; In response to an initiation of a blockchain business operation for the business initiation control in the blockchain function interface, a signature request corresponding to the target client generated based on the identity association information corresponding to the target client is sent to the server; The method further comprises: Sending the business data to be uploaded to the server; the business data to be uploaded consists of the target business execution data in the blockchain business and the joint signature result; If the blockchain consensus network successfully verifies the joint signature result based on the complete public key and passes the consensus on the business data to be uploaded to the chain, feedback data sent by the server for the business data to be uploaded to the chain is received, and the virtual resource data is updated and displayed in the blockchain function interface based on the feedback data.

13. A data processing device based on blockchain key, characterized in that: The data processing device comprises: A local private key shard acquisition module is used to acquire communication channels for communicating with N clients respectively, and to negotiate key shards with N clients respectively based on the N communication channels to obtain local private key shards and complete public keys; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the local private key shard and the N target private key shards; the i-th target private key shard among the N target private key shards is a private key shard held solely by the i-th client among the N clients after the key shard negotiation; The identity association information acquisition module is used to receive signature requests sent by M-1 clients among N clients, and obtain the identity association information in the M-1 signature requests; M is the threshold number of private key fragments for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1; A target client determination module is used to determine the client used to initiate the blockchain service among the M-1 clients as the target client if the identity association information in the M-1 signature requests are all legal identity information; A service execution data acquisition module is used to acquire service execution data associated with a target client; The first joint signature module is used to participate in the joint signature processing for blockchain business with M-1 clients if the business execution data complies with the risk management policy corresponding to the identity association information of the target client; the joint signature result generated by the joint signature processing is jointly generated based on the local private key shard and the target private key shards held by the M-1 clients respectively, and the joint signature result is used to provide to the target client to execute blockchain business.

14. A data processing device based on blockchain key, characterized in that: The data processing device comprises: The target private key shard acquisition module is used for the target client to obtain a communication channel for communicating with N-1 clients and a server respectively, and to negotiate key shards with the server and the N-1 clients based on the communication channel to obtain a target private key shard and a complete public key corresponding to the target client; N is a positive integer greater than 1; the complete public key is a unique public key corresponding to the target private key shard corresponding to the target client, the server private key shard, and the target private key shard corresponding to the N-1 clients; the i-th target private key shard in the target private key shard corresponding to the N-1 clients is a private key shard held solely by the i-th client among the N-1 clients after the key shard negotiation; the server private key shard is a private key shard held solely by the server after the key shard negotiation; A signature request sending module is used to generate a signature request corresponding to the target client based on the identity association information corresponding to the target client, and send the signature request corresponding to the target client to the server, so that the server performs legal identity authentication on the identity association information in the received M-1 signature requests; the M-1 signature requests include the signature request corresponding to the target client; M is a threshold value of the number of private key fragments for signature verification based on the complete public key, and M is a positive integer less than or equal to N+1; The business execution data sending module is used to detect that the identity association information in the M-1 signature requests determined by the server is all legal identity information. If the target client receives the information, the service execution data associated with the target client is sent to the server; The second joint signature module is used to participate in the joint signature processing for the blockchain business together with the client that initiates the signature request and the server if the business execution data complies with the risk management policy corresponding to the identity association information of the target client; the joint signature result generated by the joint signature processing is jointly generated based on the target private key shard corresponding to the client that initiates the signature request and the server private key shard, and the joint signature result is used to provide to the target client to execute the blockchain business.

15. A computer device, characterized in that: include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide a data communication function, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method described in any one of claims 1 to 12.

16. A computer-readable storage medium, characterized in that: A computer program is stored in the computer-readable storage medium, and the computer program is suitable for being loaded and executed by a processor, so that a computer device having a processor executes the method according to any one of claims 1 to 12.

Images