Resource transfer method and device, computer equipment and storage medium

Abstract

The invention relates to a resource transfer method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: receiving a resource transfer request for a target wallet; the resource transfer request comprises request content and a participant signature of at least one participant; verifying the validity of the signatures of the participants; under the condition that the number of the participant signatures passing the validity verification reaches a first number, determining a wallet key according to the participant signatures passing the validity verification; and executing a resource transfer operation according to the wallet key and the request content. By adopting the method, the security of resource transfer can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technologies, and particularly to a resource transfer method, apparatus, computer device, storage medium, and computer program product. Background Art

[0002] A digital wallet is software that can pay for goods through the Internet and is an electronic form of wallet. For consumers, when purchasing goods, they can pay not only with physical resources but also with electronic resources, and the electronic resources can be stored through a digital wallet.

[0003] In scenarios where transactions are made with electronic resources, resource transfer is usually achieved through a digital wallet. When a consumer uses a digital wallet for payment, the consumer usually needs to sign the transaction with a private key saved by himself / herself to execute it. In most scenarios, it is usually necessary for the consumer to provide a single private key for signature to complete the payment behavior.

[0004] In traditional payment methods, payment through single-point signature may have the risk of single-point failure, that is, once the private key is lost or stolen, the resources in the digital wallet may be lost forever or misappropriated, posing a security hazard. Summary of the Invention

[0005] Based on this, in view of the above technical problems, it is necessary to provide a resource transfer method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve the security of resource transfer.

[0006] In a first aspect, the present application provides a resource transfer method, including:

[0007] A resource transfer method, the method including:

[0008] Receiving a resource transfer request for a target wallet; the resource transfer request includes a request content and participation signatures of at least one participant;

[0009] Verifying the validity of each of the participation signatures;

[0010] When the number of participation signatures passing the validity verification reaches a first number, determining a wallet key according to the participation signatures passing the validity verification;

[0011] Performing a resource transfer operation according to the wallet key and the request content.

[0012] In a second aspect, the present application further provides a resource transfer apparatus, including:

[0013] A receiving module, configured to receive a resource transfer request for a target wallet; the resource transfer request includes a request content and participation signatures of at least one participant;

[0014] A verification module, configured to verify the validity of each of the participation signatures;

[0015] A determination module, configured to determine a wallet key according to the participation signatures that pass the validity verification when the number of participation signatures that pass the validity verification reaches a first number;

[0016] An execution module, configured to perform a resource transfer operation according to the wallet key and the request content.

[0017] In a third aspect, the present application further provides a computer device, including a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, the steps of the above method are implemented.

[0018] In a fourth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0019] In a fifth aspect, the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0020] For the above resource transfer method, device, computer device, storage medium, and computer program product, a resource transfer request for a target wallet is received, and the validity of the participation signatures of each participant in the resource transfer request is verified. Only when the number of participation signatures that pass the validity verification reaches a first number, can the wallet key be restored according to the first number of participation signatures, and then the resource transfer is performed according to the wallet key. That is, the present application divides the wallet key into multiple shares. In a scenario where resource transfer is required, at least the first number of participants need to provide their respective shares (providing shares through participation signatures) to restore the wallet key. Even if some participants lose their shares, the wallet key can still be restored (that is, the signature key can be restored even if some participants do not provide participation signatures) to complete the resource transfer, which can not only avoid the single point of failure problem but also greatly improve the security of resource transfer. This flexible and secure way to manage and use resources is particularly suitable for scenarios with high security requirements, such as large-scale asset management or organizational resource management. Description of the Drawings

[0021] To more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the accompanying drawings required for the description of the embodiments or related technologies. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0022] Figure 1 It is an application environment diagram of the resource transfer method in an embodiment;

[0023] Figure 2 It is a schematic flowchart of the resource transfer method in an embodiment;

[0024] Figure 3 It is a schematic flowchart of the initiation process of the resource transfer request in an embodiment;

[0025] Figure 4 It is a schematic flowchart of the resource transfer method in another embodiment;

[0026] Figure 5 It is a schematic flowchart of the steps of performing validity verification based on the participant data to obtain the validity verification result in an embodiment;

[0027] Figure 6 It is a schematic flowchart of the initiation process of the resource transfer request in yet another embodiment;

[0028] Figure 7 It is a schematic flowchart of the steps of performing validity verification based on the participant data to obtain the validity verification result in an embodiment;

[0029] Figure 8 It is a schematic diagram of sub - key distribution in an embodiment;

[0030] Figure 9 It is a structural block diagram of the resource transfer device in an embodiment;

[0031] Figure 10 It is an internal structure diagram of a computer device in an embodiment. Detailed implementation manners

[0032] In order to make the objectives, technical solutions, and advantages of the present application clearer, the following further elaborates on the present application in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0033] The resource transfer method provided by the embodiments of the present application can be applied as Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or can be placed on the cloud or other network servers. The terminal 102 initiates a resource transfer request to the server 104 through the network, and the server 104 receives the resource transfer request for the target wallet; the resource transfer request includes the request content and the participant signatures of at least one participant; verify the validity of each participant signature; in the case where the number of participant signatures that pass the validity check reaches the first number, determine the wallet key according to the participant signatures that pass the validity check; perform a resource transfer operation according to the wallet key and the request content. The server 104 feeds back the resource transfer result to the terminal 102. Among them, the terminal 102 can be but is not limited to various personal computers, laptop computers, smart phones, tablet computers, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle-mounted devices (such as vehicle-mounted terminals), etc. The portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The server 104 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, 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. The terminal and the server can be directly or indirectly connected through wired or wireless communication methods, and this application does not make any restrictions here.

[0034] In an exemplary embodiment, as Figure 2 shown, a resource transfer method is provided. Taking the server in Figure 1 as an example for illustration, it can be understood that this method can also be applied to the server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps 202 to step 208. Among them:

[0035] Step 202, receive a resource transfer request for the target wallet; the resource transfer request includes the request content and the participant signatures of at least one participant.

[0036] Among them, the target wallet is an electronic wallet, specifically it can be a digital wallet or a software wallet, which is used to store resources existing in electronic form. In some embodiments, the target wallet can be a corporate wallet, or a special-purpose wallet for specific funds, etc. The request content is the resource transfer request content, which can specifically include the wallet address of the target wallet, the wallet address of the resource recipient, the amount of resource transfer, and the resource transfer details, etc. Among them, the resource transfer details can include information such as the resource transfer time, the purpose of resource transfer, or the reason description of resource transfer.

[0037] The participant is the object that holds one of the key shares, and the key share is the sub-key mentioned later. In this application, the participant can specifically be an enterprise member related to the target wallet in a certain enterprise. For example, if the wallet is a targeted expenditure wallet, the related enterprise members can be the members who execute the targeted expenditure and the members who approve the targeted expenditure.

[0038] The participant signature is the signature data generated by the object participating in the resource transfer, and it is the data obtained by signing the preset data with the public key of the participant. The preset data can specifically include the sub-key held by the participant, and at least one of the following: the pre-consent content of the participant, the signature time, the level to which the participant belongs, the participant signatures of other participants. Among them, other participants refer to other participants except itself.

[0039] Specifically, the server can receive the resource transfer request sent by the terminal where the initiator is located. The resource transfer request is used to request resource transfer with the target wallet as the resource transfer-out wallet. Then the server can extract the request content and the participant signatures of at least one participant from the resource transfer request. Among them, the initiator can be one of the participants or not a participant, and the embodiments of this application do not make any limitations in this regard.

[0040] It should be noted that the resource transfer method provided in this application is applicable to resource transfer that requires multiple participants to jointly participate, that is, resource transfer for the target wallet requires the consent of multiple participants.

[0041] Please refer to Figure 3 , Figure 3The initiation process of a resource transfer request in an embodiment is as follows. Taking the requester as one of the participating parties as an example: When a certain participating party wants to initiate a resource transfer request, it can initiate a request for approval through the internal system of the organization. The request for approval carries the content related to the resource transfer of this operation (the content related to the resource transfer, which is the pre-approved content after passing the approval). The request for approval will automatically flow to the pre-set approval nodes. After any approval node approves, it will sign the content related to the resource transfer and the sub-key it holds based on the private key of the participating party corresponding to this approval node, obtaining the participating party signature. The participating party signature may also include the current timestamp. During the process of the request for approval flowing, the content of the request for approval received by the subsequent approval node may include the participating party signature of the participating party corresponding to the previous approval node. This continues to flow until the request for approval is approved.

[0042] For example, each participating party can sign the content related to the resource transfer and the sub-key it holds through the public key of the participating party, obtaining the corresponding participating party signature, such as Figure 3 Signature 1, Signature 2, Signature 3... Signature n in []. During the continuous flow of the request for approval, it can carry the participating party signatures of the participating parties with earlier approval order. Therefore, when the last approval node completes the approval, n participating party signatures can be obtained. It can be understood that n here is greater than or equal to the first quantity k mentioned later, and k is the minimum quantity preset for reconstructing the wallet key.

[0043] After obtaining the n participating party signatures, the initiator generates a resource request based on these n participating party signatures and the request content, and sends the resource transfer request to the server.

[0044] Step 204, verify the validity of each participating party signature.

[0045] Specifically, for each participating party signature in the resource transfer request, the server can separately verify the validity of each participating party signature.

[0046] In some embodiments, verifying the validity of each participating party signature includes: decrypting each participating party signature to obtain the participating party data of each participating party; performing a validity check based on the participating party data to obtain a validity check result; the validity check result includes passing the validity check and / or not passing the validity check.

[0047] Specifically, for any participating party signature, the server can obtain the public key of the participating party and decrypt the participating party signature through the public key of the participating party to obtain the participating party data of the participating party. The participating party data includes the sub-key held by the participating party and at least one of the following: the pre-approved content of the participating party, the signature time, the level to which the participating party belongs, and the participating party signatures of other participating parties.

[0048] Further, the server can perform a validity check on the participant data of the participant, so as to obtain the validity check result of the participant's signature. The validity check result includes passing the validity check and / or failing the validity check.

[0049] In some embodiments, the server can perform a validity check on the participant's signature by verifying whether the participant data meets a preset condition. Among them, the preset condition can specifically be at least one of the following: whether the pre-agreed content of the participant matches the requested content, whether the signature time is within the validity period, whether the level to which the participant belongs is a preset level, etc.

[0050] Among them, whether the pre-agreed content of the participant matches the requested content is used to verify whether the content agreed by the participant is consistent with the requested content, so as to prevent the requester from forging a resource transfer request after obtaining the participant's signature. Whether the signature time is within the validity period is used to verify whether the signature time has expired, or whether the target wallet is within the validity period, etc. Whether the level to which the participant belongs is a preset level is used to verify whether the participant participating in this resource transfer request is a participant of a preset level.

[0051] It can be understood that the above preset conditions are only illustrative explanations. Based on actual business requirements, other preset conditions can also be set to judge the participant content, so as to determine whether the participant's signature is valid. The embodiments of the present application do not limit this.

[0052] In the above embodiments, the participant data is obtained by decrypting the participant's signature, and then the validity check is performed based on the participant data, so that the validity of the participant's signature can be accurately identified.

[0053] Step 206, when the number of participant signatures that pass the validity check reaches a first number, determine the wallet key according to the participant signatures that pass the validity check.

[0054] Specifically, the server can extract the sub-keys in the participant signatures that pass the validity check, and record the number of participant signatures that pass the validity check. When the number reaches the first number, reconstruct the wallet key according to the extracted first number of sub-keys.

[0055] In some embodiments, determining the wallet key according to the participant signatures that pass the validity check includes: obtaining the sub-keys in the participant signatures that pass the validity check; generating the wallet key according to the first number of sub-keys.

[0056] In some embodiments, for each signature of the participating party to be verified, after the signature of the participating party is verified and passed, the server may extract the sub-key therein and store it. When the number of stored sub-keys reaches the first number k, the wallet key can be reconstructed based on the first number of sub-keys.

[0057] In some embodiments, when the server verifies the signature of the participating party, it decrypts the signature of the participating party through the public key of the participating party to obtain the participating party data, and the participating party data may include sub-keys.

[0058] In some embodiments, the server can calculate based on k sub-keys through the Lagrange interpolation formula to obtain the wallet key. In some other embodiments, the server can use the difference interpolation method and calculate based on k sub-keys to obtain the wallet key. Or, the server can also obtain the wallet key through matrix operations based on k sub-keys. The specific reconstruction method is not limited in the embodiments of the present application.

[0059] It should be noted that multiple sub-keys can be obtained by pre-processing the wallet key in the following manner:

[0060] The server can construct a polynomial of degree k - 1, with the wallet key as the constant term. The polynomial of degree k - 1 is as follows: ; where s is the wallet key, a 1、 a2……a k-1 are the coefficients of the polynomial, P is a prime number, and mod(P) is the modulo operation with respect to P. The server can take N different x values and substitute them into F(x) to obtain N groups of sub-keys [x1, F(x1)], [x2, F(x2)], ……, [x N , F(x N )], and distribute these N groups of sub-keys to N participating parties for their respective custody.

[0061] After the server obtains k sub-keys, it can construct the following polynomial: , this polynomial is a deformation of the above polynomial, where x i is the x value in the i-th group of sub-keys, y i is the value of F(x i ) in the i-th group of sub-keys, and x j is the x value in the j-th group of sub-keys.

[0062] Furthermore, the server can take x = 0, substitute the k sub-keys into the polynomial respectively, and solve for F(0), which is also the value of the wallet key.

[0063] In some embodiments, the server can also generate a second number of sub-keys through other means using the wallet key, and then, through a reconstruction method matching the sub-key generation method, reconstruct the wallet key based on the first number of sub-keys. For example, the server can generate a second number of sub-keys based on the wallet key through Shamir secret sharing (a threshold secret sharing technique), Blakley secret sharing (a threshold secret sharing technique), or CRT (Chinese Remainder Theorem) secret sharing, etc., and then reconstruct the wallet key based on k sub-keys through a reconstruction method matching the sub-key generation method.

[0064] In the above embodiments, the sub-keys in the participant signatures that pass the validity check can be used to recover the wallet key. In this way, it is equivalent to reconstructing the wallet key through the sub-keys held by the first number of participants. Compared with the method of a single user holding the signature key, the risk of single point of failure is avoided; compared with the traditional multi-signature method that strictly requires multiple private keys for resource transfer, there is no need for users to manage multiple private keys by themselves. Each participant can manage their own sub-keys, and resource transfer can still be carried out even if some participants lose their sub-keys, making resource transfer more flexible and convenient.

[0065] Step 208, perform a resource transfer operation according to the wallet key and the request content.

[0066] Specifically, in the case of reconstructing the wallet key, the server can perform a resource transfer operation according to the wallet key and the request content.

[0067] In some embodiments, the server can determine the wallet address of the target wallet, the wallet address of the resource recipient, and the resource transfer amount in the request content, and transfer the resources of the resource transfer amount in the target wallet to the resource recipient's wallet through the wallet key. Alternatively, the server can mention the wallet key and the request content to the corresponding institution to implement the resource transfer operation through the institution.

[0068] The above resource transfer method receives a resource transfer request for a target wallet and verifies the validity of the participant signatures of all parties involved in the resource transfer request. Only when the number of participant signatures that pass the validity check reaches a first quantity can the wallet key be restored based on the first quantity of participant signatures, and then the resource transfer can be performed based on the wallet key. That is, in this application, the wallet key is divided into multiple shares. In the scenario where resource transfer is required, at least the first quantity of participants need to provide their respective shares to restore the wallet key. Even if some participants lose their shares, the wallet key can still be restored to complete the resource transfer, which can not only avoid the single point of failure problem but also greatly improve the security of resource transfer. This flexible and secure way of managing and using resources is particularly suitable for scenarios with high security requirements, such as large - amount asset management or organizational resource management, etc.

[0069] Reference Figure 4 , in some embodiments, the resource transfer method includes the following steps:

[0070] Step 402, receive a resource transfer request for a target wallet; the resource transfer request carries request content and at least one participant's participant signature.

[0071] Step 404, decrypt each participant signature to obtain each participant's participant data.

[0072] Step 406, perform a validity check based on the participant data to obtain a validity check result; the validity check result includes passing the validity check or not passing the validity check.

[0073] Step 408, when the number of participant signatures that pass the validity check reaches the first quantity, obtain the sub - keys in the participant signatures that pass the validity check, and generate a wallet key based on the first quantity of sub - keys.

[0074] Step 410, perform a resource transfer operation based on the wallet key and the request content.

[0075] In some embodiments, the participant data includes at least one of the participant's pre - consent content, signature time, or other participants' participant signatures, and the server can perform a validity check based on at least one of the pre - consent content, signature time, or other participants' participant signatures.

[0076] Reference Figure 5 , in some embodiments, the participant data includes the participant's pre - consent content and signature time. Performing a validity check based on the participant data, the obtained validity check result includes:

[0077] Step 502: For any participating party, match the pre-consent content of the targeted participating party with the request content in the resource transfer request to obtain a matching result.

[0078] Specifically, for any participating party, the server can perform validity verification in the following manner: The server can match the pre-consent content of the targeted participating party with the request content in the resource transfer request to determine whether the pre-consent content of the targeted participating party is consistent with the resource transfer-related content in the request content. If they are consistent, it indicates that the participating party agrees to this resource transfer operation. If they are inconsistent, it indicates that the request content of this resource transfer request is forged or incorrect and is not the content agreed by this participating party.

[0079] In some embodiments, the pre-consent content includes information such as the wallet addresses of the resource transferor and the resource recipient involved in the resource transfer operation, and the amount of resource transfer. The server can compare the wallet address of the target wallet, the wallet address of the resource recipient, and the amount of resource transfer in the request content with the pre-consent content to determine whether each item is consistent. If they are consistent, it is considered a successful match. If any one item is inconsistent, it indicates an unsuccessful match.

[0080] For example, if the pre-consent content of a participating party is to transfer 1000 yuan from wallet A to wallet B, while the request content is to transfer 999 yuan from wallet A to wallet B, then since the amount of resource transfer is different, it is considered an unsuccessful match. If the request content is to transfer 1000 yuan from wallet A to wallet B, which is consistent with the pre-consent content, it is considered a successful match.

[0081] Step 504: Verify the validity of the signature time of the targeted participating party.

[0082] Among them, the signature time of the participating party can be determined through the timestamp in the participating party's signature. That is, when the participating party generates the participating party's signature, the timestamp at that time can be added to the signature. In this way, the participating party data decrypted based on the participating party's signature will include the signature time of the participating party.

[0083] Furthermore, the server can verify the validity of the signature time of the targeted participating party based on a preset validity period range. For example, if the interval between the signature time of the participating party and the reception time of the resource transfer request is within the preset validity period range, it is determined that the signature time is valid; or, if the signature time of the participating party is within the preset validity period range of the target wallet, it is determined that the signature time is valid. Among them, the preset validity period range can be set based on actual business needs.

[0084] In some other embodiments, if no preset validity period range is set for the signature time, then it can be considered that the signature time is valid at any time.

[0085] Step 506, when the matching result indicates a successful match and the signature time is valid, determine that the participant signature of the targeted participant passes the validity check.

[0086] Specifically, when the pre-consent content of the participant matches the request content and the signature time is valid, the server can determine that the participant signature of the targeted participant passes the validity check.

[0087] It can be understood that for any participant signature, the server can perform the validity check in the above manner.

[0088] In the above embodiments, by discriminating the pre-consent content and signature time of the participant to identify whether the participant signature is valid, invalid participant signatures can be eliminated, ensuring that only valid participant signatures are used when reconstructing the wallet key later, and thus ensuring the security of the resource transfer process.

[0089] In some embodiments, the participant data includes the pre-consent content of the participant. Based on the participant data, a validity check is performed to obtain a validity check result, including: for any participant, matching the pre-consent content of the targeted participant with the request content in the resource transfer request to obtain a matching result; when the matching result indicates a successful match, determine that the participant signature of the targeted participant passes the validity check.

[0090] In some embodiments, for any participant, the server can perform the validity check in the following manner: the server can match the pre-consent content of the targeted participant with the request content in the resource transfer request to determine whether the pre-consent content of the targeted participant is consistent with the content related to resource transfer in the request content. If they are consistent, it means that the participant agrees to this resource transfer operation, and then it is determined that the participant signature passes the validity check. If they are inconsistent, it means that the request content of this resource transfer request is forged and is not the content agreed by this participant, and then it is determined that the participant signature fails the validity check.

[0091] In the above embodiments, by discriminating the pre-consent content of the participant to identify whether the participant signature is valid, invalid participant signatures can be eliminated, ensuring that only valid participant signatures are used when reconstructing the wallet key later, and thus ensuring the security of the resource transfer process.

[0092] In some embodiments, the participant data includes the signature time. Based on the participant data, a validity check is performed to obtain a validity check result, including: verifying the validity of the signature time of the targeted participant; when the signature time is valid, determine that the participant signature of the targeted participant passes the validity check.

[0093] In the above embodiments, by determining the signature time of the participating parties to identify whether the signature of a participating party is valid, invalid signatures of the participating parties can be eliminated, ensuring that only valid signatures of the participating parties are used when reconstructing the wallet key later, and thus ensuring the security of the resource transfer process.

[0094] In some embodiments, the resource transfer method includes the following steps:

[0095] Receive a resource transfer request for a target wallet, and extract the signature data and request content in the resource transfer request; decrypt the signature data to obtain the participating party data of one of the participating parties. If the participating party data includes the participating party signatures of other participating parties, decrypt the participating party signatures of other participating parties to obtain the participating party data of other participating parties. If the decrypted participating party data includes a participating party signature, continue to decrypt until the finally decrypted participating party data does not include any participating party signatures.

[0096] Perform a validity check on the participating party data obtained by decrypting each participating party signature to obtain a validity check result. When the number of participating party signatures passing the validity check reaches a first number, determine the wallet key according to the participating party signatures passing the validity check; perform a resource transfer operation according to the wallet key and the request content.

[0097] In some embodiments, the number of directly carried participating party signatures in the resource transfer request can be at least one. The server decrypts these at least one participating party signatures layer by layer to obtain multiple participating party signatures. For example, if the number of participating party signatures carried in the resource transfer request is p, decrypt these p participating party signatures respectively to obtain their respective participating party data, and the participating party data includes the participating party signatures of other participating parties. The server can decrypt the signatures again to obtain the participating party data. In this way, as long as the decrypted participating party data includes a participating party signature, decrypt it until the finally decrypted participating party data does not include a participating party signature. Therefore, multiple participating party signatures are obtained by decrypting the participating party signatures layer by layer.

[0098] Please refer to Figure 6 to understand the above layer-by-layer decryption process, Figure 6 which is the initiation process of the resource transfer request in yet another embodiment.

[0099] Taking the requester as one of the participating parties and the approver as the other participating party as an example: when a certain participating party wants to initiate a resource transfer request, it can initiate a request for approval through the internal system of the organization. The request for approval carries the content related to this resource transfer (the content related to this resource transfer is the pre-approved content after passing the approval). This request for approval will automatically flow to the pre-set approval nodes. After any approval node approves, it will sign the content related to this resource transfer, the participating party signature transmitted by the previous approval node, and the sub-key it holds based on the private key of the participating party corresponding to this approval node, to obtain the participating party signature of this approval node. This process continues until the request for approval is approved. When the request for approval is approved, the content related to the resource transfer in each participating party signature is the pre-approved content.

[0100] For example, for the initiator, it can sign the content related to the resource transfer and the sub-key 1 it holds through the public key of the participating party to obtain signature 1; the next approver can sign the participating party signature (i.e., signature 1) passed by the previous participating party, the content related to the resource transfer, and the sub-key 2 it holds through the public key of the participating party to obtain signature 2; the next approver can sign the participating party signature (i.e., signature 2) passed by the previous participating party, the content related to the resource transfer, and the sub-key 3 it holds through the public key of the participating party to obtain signature 3... and so on, until the nth participating party signs the participating party signature (i.e., signature n - 1) passed by the previous participating party, the content related to the resource transfer, and the sub-key n it holds to obtain signature n. It can be understood that n here is greater than or equal to the first quantity k mentioned above.

[0101] Furthermore, the initiator can construct a resource transfer request based on the participating party signature generated by the last approval node and send the resource transfer request to the server. Therefore, the server can obtain the participating party signatures of multiple participating parties through the layer-by-layer decryption method described above.

[0102] In some other embodiments, the resource transfer request may also carry the participating party signature generated each time. In this way, the server can directly extract the participating party signatures in the resource transfer request.

[0103] In view of this, please refer to Figure 7 , in some embodiments, the participating party data includes the pre-approved content of the participating party and the participating party signatures of other participating parties. Based on the participating party data, an effectiveness verification is performed to obtain an effectiveness verification result, including:

[0104] Step 702, for any participating party, match the pre-approved content of the targeted participating party with the request content in the resource transfer request to obtain a matching result.

[0105] Specifically, for the participant data obtained by layer-by-layer decryption, the server can determine the participants involved. For any participant, the server can perform validity verification in the following manner: The server can match the pre-consent content of the targeted participant with the request content in the resource transfer request to determine whether the pre-consent content of the targeted participant is consistent with the resource transfer-related content in the request content. If they are consistent, it indicates that the participant agrees to this resource transfer operation. If they are inconsistent, it indicates that the request content of this resource transfer request is forged or incorrect and is not the content consented to by this participant.

[0106] In some embodiments, the pre-consent content includes information such as the wallet addresses of the resource transferor and the resource recipient involved in the resource transfer operation, as well as the amount of resource transfer. The server can compare the wallet address of the target wallet, the wallet address of the resource recipient, and the amount of resource transfer in the request content with the pre-consent content to determine whether each item is consistent. If they are consistent, it is considered a successful match. If any one item is inconsistent, it indicates an unsuccessful match.

[0107] Step 704: Determine the participant signature included in the participant data of the targeted participant.

[0108] It should be noted that each participant has a corresponding level. The higher the level, the greater the approval authority of the participant corresponding to that level. The specific levels corresponding to different participants can be the levels in the organizational structure or the levels set for a specific project. The embodiments of the present application do not limit this.

[0109] Specifically, for the participant signature corresponding to any participant, the server can extract the participant signatures of other participants included therein from the decrypted participant data. Theoretically, the level of the participant from which the participant signature included in this participant data is derived should be lower than the level of the targeted participant.

[0110] Step 706: Detect whether the levels to which the other participants from which the included participant signatures are derived belong cover all levels lower than the level of the targeted participant.

[0111] Specifically, after the server decrypts layer by layer the participant signatures directly carried in the resource transfer request, it can determine which participants the resource transfer request specifically involves, and also obtain the inclusion relationship between different participant signatures through layer-by-layer decryption. Furthermore, for any participant, the server can detect whether the levels to which the other participants from which the participant signatures included in this participant data are derived belong cover all levels lower than the level of the targeted participant.

[0112] For example, the resource transfer request carries the party signature A' corresponding to party A. The party signature A' is decrypted by the party public key of party A to obtain the subkey of party A, the pre-agreed content, and the party signature B' of party B. The server decrypts the party signature B' by the party public key of party B to obtain the subkey of party B, the pre-agreed content, and the party signature C' of party C. The server decrypts the party signature C' by the party public key of party C to obtain the subkey and pre-agreed content of party C. Then, the inclusion relationship between the above party signatures is: the party signature A' contains the party signature B' and the party signature C'; the party signature B' contains the party signature C'.

[0113] The server can query the levels involved by the participants related to the resource transfer operation from the organizational structure. For example, the levels involved are from high to low: Level 1, Level 2 and Level 3. Among them, participant A corresponds to Level 1, participant B corresponds to Level 3, and participant C corresponds to Level 3. Then for participant signature A', it corresponds to Level 1, and the levels lower than Level 1 include Level 2 and Level 3, while participant signature A' contains participant signature B' and participant signature C', which only covers Level 3, that is, it does not cover the levels lower than the level of the targeted participant, so participant signature A' fails the validity check.

[0114] The server can query the levels involved by the participants related to the resource transfer operation from the organizational structure. For example, the levels involved are from high to low: Level 1, Level 2 and Level 3. Among them, participant A corresponds to Level 1, participant B corresponds to Level 2, and participant C corresponds to Level 3. Then for participant signature A', it corresponds to Level 1, and the levels lower than Level 1 include Level 2 and Level 3, and participant signature A' contains participant signature B' and participant signature C', which means that Level 2 and Level 3 are covered, that is, all levels lower than the level of the targeted participant are covered. For participant signature B', it contains participant signature C', which means that Level 3 is covered, and the levels lower than Level 2 include Level 3, so it is considered that all levels lower than the level of the targeted participant are covered.

[0115] If the levels of other participants from which the participant signatures are sourced contained in the participant data of the targeted participant do not cover all levels lower than the level of the targeted participant, it means that there is a cross-level signature in the signature, which is theoretically unreasonable and may be a malicious act. Therefore, this application determines the inclusion relationship between the signatures of the participants involved in the resource transfer process to eliminate such signatures, thereby ensuring the security of subsequent processing.

[0116] Step 708, if so, and the matching result indicates a successful match, determine that the participant signature of the targeted participant passes the validity check.

[0117] Specifically, if the level to which other participants to whom the participant signature source contained in the participant signature of any participant belongs covers each level lower than the level to which the targeted participant belongs, and the pre-consent content of this participant matches the request content in the resource transfer request, determine that the participant signature of this participant passes the validity check. Otherwise, if any condition is not met, the validity check cannot be passed.

[0118] In the above embodiments, by discriminating the pre-consent content of the participant and judging the inclusion relationship between the participant signatures involved in this resource transfer process, to identify whether the participant signature is valid, invalid participant signatures that miss necessary reviewing parties can be eliminated, ensuring that all participant signatures used in subsequent wallet key reconstruction are valid, thus ensuring the security of the resource transfer process.

[0119] In some embodiments, the participant data includes the participant signatures of other participants. Based on the participant data, a validity check is performed to obtain a validity check result, including: for any participant, determine the participant signature contained in the participant data of the targeted participant; detect whether the level to which other participants to whom the contained participant signature source belongs covers each level lower than the level to which the targeted participant belongs; if so, determine that the participant signature of the targeted participant passes the validity check.

[0120] In the above embodiments, by judging the inclusion relationship between the participant signatures involved in this resource transfer process, to identify whether the participant signature is valid, participant signatures that miss necessary reviewing parties can be eliminated, ensuring that all participant signatures used in subsequent wallet key reconstruction are valid, thus ensuring the security of the resource transfer process. In some embodiments, the participant data includes the pre-consent content of the participant, the signature time, and the participant signatures of other participants. Based on the participant data, a validity check is performed to obtain a validity check result, including: for any participant, match the pre-consent content of the targeted participant with the request content in the resource transfer request to obtain a matching result; verify the validity of the signature time of the targeted participant; determine the participant signature contained in the participant data of the targeted participant, and detect whether the level to which other participants to whom the contained participant signature source belongs covers each level lower than the level to which the targeted participant belongs; if so, and when the matching result indicates a successful match and the signature time is valid, determine that the participant signature of the targeted participant passes the validity check.

[0121] It should be noted that the execution order of the various verification methods, such as verifying based on the pre-consent content of the participating parties, verifying based on the signature time of the participating parties, and verifying based on the participating party signatures of other participating parties, mentioned in the above embodiments can be sequential or parallel, etc., and the embodiments of the present application do not limit this.

[0122] In some embodiments, when the number of participating party signatures that pass the validity verification reaches a first number, determining the wallet key according to the participating party signatures that pass the validity verification includes: when the number of participating party signatures that pass the validity verification reaches the first number and the levels of the participating parties from which the participating party signatures that pass the validity verification originate include a preset level, determining the wallet key according to the participating party signatures that pass the validity verification.

[0123] Although the resource transfer for the target signature can be determined by the first number of participating parties, in some special scenarios, it can be set that at least one participating party at a preset level must be included among the first number of participating parties to be responsible for this resource transfer operation.

[0124] Specifically, the server can determine the levels of the participating parties from which the participating party signatures that pass the validity verification originate. Only when the levels determined include a preset level and the number of participating party signatures that pass the validity verification reaches the first number, will the wallet key be determined according to the participating party signatures that pass the validity verification.

[0125] It should be noted that the present application embodiments do not limit the execution order of the above steps of judging the data of the participating party signatures that pass the validity verification and the step of judging whether the levels of the participating parties from which the participating party signatures that pass the validity verification originate include a preset level. It can be executed one after the other, simultaneously, or separately multiple times, etc.

[0126] In the above embodiments, only when the number of participating party signatures that pass the validity verification reaches the first number and the levels of the participating parties from which the participating party signatures that pass the validity verification originate include a preset level, will the wallet key be determined according to the participating party signatures that pass the validity verification, which can further ensure the reliability and security of the execution of this resource transfer operation.

[0127] In some embodiments, decrypting each participating party signature to obtain the participating party data of each participating party includes: determining the participating party identifier corresponding to each participating party respectively; obtaining the participating party public key that matches each participating party identifier; decrypting the corresponding participating party signature through the participating party public key to obtain the participating party data.

[0128] Among them, the participant identifier is used to uniquely identify a participant, and may specifically be a letter, text, number, or string, etc. In some embodiments, the server may pre-store participant public keys respectively corresponding to each participant. These participant public keys may be public keys of the participants, or may be keys transmitted by the participants to the server through a trusted communication environment.

[0129] In some embodiments, the server may associatively store the participant identifiers and participant public keys of each participant in the form of a table or a database, and then in a scenario where validity verification is required, obtain the participant public key according to the participant identifier.

[0130] Further, the server may decrypt the participant signature through the participant public key to obtain participant data. The participant data may include a sub-key of the participant. Then, the server may save the decrypted sub-key for subsequent processing.

[0131] In the above embodiments, when the participant transmits parameter party data, it may encrypt it through the participant private key to obtain signature data and transmit it in the form of signature data. Then, the participant signature may be decrypted through the participant public key to obtain participant data. This realizes the encrypted transmission of participant data and avoids the leakage of participant data.

[0132] In some embodiments, the method further includes a step of sub-key distribution, which specifically includes: obtaining a wallet key, generating a second number of sub-keys based on the wallet key; the second number is greater than the first number; transmitting the second number of sub-keys to the second number of participants; wherein each participant saves one of the sub-keys.

[0133] It should be noted that the steps of generating and distributing the sub-keys may be implemented by the server implementing the resource transfer method in this application, or may be implemented by other computer devices (other computer devices may be, for example, the terminal corresponding to the creator of the target wallet). The embodiments of this application do not limit this. Therefore, the following descriptions are all described through the implementation of computer devices:

[0134] In some embodiments, the wallet creator may generate a digital wallet as the target wallet and set a wallet key. The digital wallet may be used for scenarios such as directed expenditures within an enterprise or large-amount expenditures. The wallet creator may send a key distribution situation to the computer device. The request carries the wallet address of the target wallet, the wallet key of the target signature, and the participant addresses of N participants managing the target wallet.

[0135] The computer device may generate a second number of distinct sub-keys through the wallet key, and at least k sub-keys can be used to recover the wallet key.

[0136] Specifically, the computer device can construct a polynomial of degree k-1, with the wallet key as the constant term, as shown in the following formula: ; where s is the wallet key, and a 1、 a2……a k-1 are the coefficients of the polynomial, and P is a prime number. The computer device can substitute N different x values into F(x) to obtain N groups of sub-keys, and distribute these N groups of sub-keys to N participants for their respective custody.

[0137] Of course, the computer device can also generate multiple sub-keys based on the wallet key through other methods, such as Blakley secret sharing or CRT secret sharing, etc. The embodiments of the present application do not limit this.

[0138] Furthermore, please refer to Figure 8 . The computer device can transfer the second number of sub-keys to the second number of participants, and each participant stores one of the sub-keys.

[0139] In some embodiments, the computer device can distribute the sub-keys through a network security channel or a preset security protocol. Or, a hardware device can also be used to distribute the sub-keys. Each sub-key is separately stored in a different hardware device, such as a USB token, and then the hardware devices are distributed to different participants.

[0140] It should be noted that if the computer device in the present application executes the steps of generating and distributing the sub-keys, then the computer device can destroy the wallet key and each sub-key after distributing the sub-keys.

[0141] In the above embodiments, the wallet key is pre-divided into the second number of sub-keys, and then the second number of sub-keys are distributed to the second number of participants. In this way, each participant stores its own sub-key. When resource transfer is required, at least k sub-keys can be provided to recover the wallet key, thus realizing resource transfer. In the case where some participants lose their sub-keys, transactions can still be carried out, making the transactions more flexible and convenient.

[0142] In some embodiments, the computer device can transfer the sub-keys in the following manner, that is, any sub-key can be transferred in the following manner: receiving the key-encrypted data sent by the participant; the key-encrypted data is obtained by encrypting the first shared key with the participant's private key; decrypting the key-encrypted data with the participant's public key to obtain the first shared key; encrypting the sub-key with the first shared key and transferring the encrypted sub-key to the participant.

[0143] Specifically, before the sub-key is transmitted, the participating party can agree with the computer device on a shared key for encrypting the sub-key, that is, the first shared key, to ensure the security of the sub-key transmission through this first shared key. The participating party can generate a symmetric key, use this symmetric key as the first shared key, and then transmit this symmetric key to the computer device through a secure transmission method.

[0144] In some embodiments, the participating party can generate a symmetric key through an encryption algorithm and encrypt the symmetric key with its own private key of the participating party to obtain key encryption data. Then, the key encryption data is sent to the computer device. The computer device decrypts the key encryption data with the public key of the participating party to obtain the symmetric key, and uses this symmetric key as the first shared key. Then, the computer device can use this first shared key to encrypt the sub-key and send the encrypted sub-key to the participating party.

[0145] It should be noted that each participating party can negotiate a shared key with the computer device. When the computer device distributes the sub-key, it can encrypt the sub-key with the corresponding shared key and then distribute it, which can ensure the security of the sub-key distribution. Of course, it can also be that multiple participating parties share a shared key. When the computer device distributes the sub-key, it encrypts and distributes it through the same shared key to prevent the sub-key from being obtained by non-participating parties, which can also ensure the security of the sub-key transmission process.

[0146] In the above embodiments, the first shared key can be transmitted through the private key of the participating party, and then the sub-key can be securely transmitted through the first shared key, which can ensure the security of the sub-key transmission process and avoid potential security risks such as sub-key leakage or theft.

[0147] In some embodiments, the computer device can also distribute the sub-key through quantum key distribution. Specifically, it includes the following steps: obtaining a random bit string, for any bit value in the random bit string, randomly selecting a polarization basis, and encoding the targeted bit value according to the selected polarization basis to obtain quantum bits; sending each quantum bit to the participating party to instruct the participating party to measure each quantum bit based on the randomly selected polarization basis to obtain the measurement results of each quantum bit; obtaining the polarization bases selected by the participating party, and matching the locally selected polarization bases with the polarization bases selected by the participating party to determine the successfully matched polarization bases; determining the second shared key based on the bit values corresponding to the successfully matched polarization bases; encrypting the sub-key with the second shared key and transmitting the encrypted sub-key to the participating party.

[0148] Specifically, a computer device can utilize the properties of quantum mechanics to achieve secure sub-key distribution. The core idea is that certain properties of a quantum system are disturbed when measured, so any third party attempting to intercept or measure will inevitably disrupt the state of the qubits in transit, and this interference can be detected by the sender and receiver of the key.

[0149] The computer device can select a random bit string as the original information, randomly select a polarization basis within a preset range for each bit value in the random bit string (for example, a rectangular basis or a diagonal basis), and use the selected polarization basis to encode the bit value.

[0150] For example, if the random bit string has m bit values, such as A1A2A3A4...A m , then for each bit value, a polarization basis will be randomly selected to encode the bit value to obtain a qubit. These m polarization bases can be represented as: sequence L1L2L3L4...L m ; the m qubits can be represented as: B1B2B3B4...B m .

[0151] Furthermore, the computer device can send each qubit (i.e., the encoded bit data, whose manifestation can be a polarized photon) to the participating party.

[0152] After receiving each qubit, the participating party randomly selects a polarization basis to measure it. The participating party records the measurement result and the polarization basis used for each qubit, which can be denoted as sequence l1l2l3l4...l m .

[0153] The computer device and the participating party disclose the polarization bases they used respectively, but do not disclose the actual bit values. In this way, the computer device can, based on the polarization basis sequence l1l2l3l4...l m disclosed by the participating party, compare it with the polarization basis sequence L1L2L3L4...L m selected locally by itself. For example, if the polarization bases at the same serial number are the same, it is considered that the polarization bases corresponding to that serial number match successfully. Furthermore, the computer device can screen out the bit values corresponding to the serial numbers of the successfully matched polarization bases, discard the bit values with unmatched polarization bases, and then can construct a second shared key based on the screened-out bit values. Specifically, the screened-out bit values can be combined to form a shared key. Furthermore, the sub-key can be encrypted with this shared key to achieve the secure transmission of the sub-key.

[0154] In the above embodiments, by using the method of quantum key distribution to agree on a shared key with the participating party, and then encrypting the sub-key based on the shared key for the encrypted transmission of the sub-key, the security of the sub-key transmission process can be guaranteed, and the security risks of sub-key leakage or theft can be avoided.

[0155] Further, based on the bit values corresponding to the successfully matched polarization bases, a second shared key is determined, including: taking the bit values corresponding to the successfully matched polarization bases as target bit values; publicly disclosing some of the target bit values, and obtaining the partial data publicly disclosed by the participating parties; if the partial bit values locally disclosed are consistent with the partial data publicly disclosed by the participating parties, then determining the shared key based on the target bit values, otherwise discarding the target bit values, and returning to the step of obtaining a random bit string to continue execution until the second shared key is obtained and then stopping.

[0156] In some embodiments, to detect the risk of information leakage, the computer device and the participating parties can publicly disclose a part of the target bit values and compare them. If the publicly disclosed bit values match successfully, it is very likely that there is no risk of information leakage; if there are mismatched bit values, it indicates that there may be information leakage. If there is information leakage, the step of obtaining a random bit string can be returned to continue execution to re-obtain a secure shared key.

[0157] It can be understood that in the above embodiments, the computer device is used as the sender and the participating party is used as the receiver to negotiate the shared key. In actual applications, it can be that the computer device is used as the receiver and the participating party is used as the sender to negotiate the shared key, and the embodiments of the present application do not limit this.

[0158] It can be understood that the terms "first", "second", etc. used in the present application can be used in this article to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from another element. For example, without departing from the scope of the present application, the first shared key can be referred to as the second shared key.

[0159] In the above embodiments, by publicly disclosing some bit values to determine whether there is a risk of information leakage, and retaining the shared key without information leakage for subsequent encryption of the sub-key, the security of the sub-key encryption transmission process can be further guaranteed.

[0160] The resource transfer method provided by the present application can specifically be applied to scenarios of large-scale asset management or organizational resource management. In an exemplary scenario embodiment, the target wallet can specifically be a wallet for managing organizational resources. The participating parties can specifically be enterprise members related to the wallet in the enterprise. For example, if the wallet is a targeted expenditure wallet, the related enterprise members can be the members who execute the targeted expenditure and the members who approve the targeted expenditure.

[0161] The resource transfer method specifically includes the following steps:

[0162] The server receives a resource transfer request for a target wallet, where the resource transfer request includes a request content and the participation signatures of multiple participants; determines the participant identifiers corresponding to each participant respectively; obtains the participant public keys that match the participant identifiers; decrypts the corresponding participant signatures through the participant public keys to obtain participant data, where the participant data includes the pre-consent content and the signature time of the participant; for any participant, matches the pre-consent content of the targeted participant with the request content in the resource transfer request to obtain a matching result; verifies the validity of the signature time of the targeted participant; when the matching result indicates a successful match and the signature time is valid, determines that the participant signature of the targeted participant passes the validity check. When the number of participant signatures that pass the validity check reaches a first number and the levels of the participants from whom the participant signatures that pass the validity check originate include a preset level, obtains the sub-keys in the participant signatures that pass the validity check; generates a wallet key based on the first number of sub-keys. Performs a resource transfer operation based on the wallet key and the request content.

[0163] In another embodiment, the resource transfer method specifically includes the following steps:

[0164] The server receives a resource transfer request for a target wallet, extracts the signature data and the request content in the resource transfer request; determines the participant identifiers corresponding to each participant respectively; obtains the participant public keys that match the participant identifiers; decrypts the corresponding signature data through the participant public keys to obtain participant data. If the participant data of this parameter party includes the participation signatures of other participants, decrypts the participation signatures of other participants through the participant public keys of other participants to obtain the participant data of other participants. If the decrypted participant data includes a participation signature, continue to decrypt until the finally decrypted participant data does not include any participation signatures of any participants.

[0165] Among them, the participant data includes the pre-consent content of the participant and the participation signatures of the participants whose levels are lower than its own level. For any participant, matches the pre-consent content of the targeted participant with the request content in the resource transfer request to obtain a matching result; determines the participation signatures included in the participant data of the targeted participant; detects whether the levels to which the source parties of the included participation signatures belong cover all levels lower than the level to which the targeted participant belongs; if so, and the matching result indicates a successful match, determines that the participation signature of the targeted participant passes the validity check. When the number of participant signatures that pass the validity check reaches a first number and the levels of the participants from whom the participant signatures that pass the validity check originate include a preset level, determines a wallet key based on the participant signatures that pass the validity check; performs a resource transfer operation based on the wallet key and the request content.

[0166] In the above resource transfer method, a resource transfer request for a target wallet is received, and the validity of the participant signatures of multiple participants in the resource transfer request is verified. Only when the number of participant signatures that pass the validity verification reaches a first number, can the wallet key be recovered based on the first number of participant signatures, and then the resource transfer can be performed based on the wallet key. That is to say, in this application, the wallet key is divided into multiple shares. In the scenario where resource transfer is required, at least the first number of participants need to provide their respective shares (providing shares through participant signatures) to recover the wallet key. Even if some participants lose their shares, the wallet key can still be recovered (that is, even if some participants do not provide participant signatures, the signature key can still be recovered) to complete the resource transfer, which can not only avoid the single point of failure problem, but also greatly improve the security of resource transfer. This flexible and secure way of managing and using resources is particularly suitable for scenarios with high security requirements, such as large amount asset management or organizational resource management.

[0167] It should be understood that although the steps in the flowcharts involved in the above embodiments are sequentially shown according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same moment, but can be executed at different moments, and the execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0168] Based on the same inventive concept, an embodiment of the present application further provides a resource transfer device for implementing the above-mentioned resource transfer method. The implementation solution provided by this device to solve the problem is similar to the implementation solution described in the above method. Therefore, the specific limitations in one or more embodiments of the resource transfer device provided below can refer to the limitations on the resource transfer method in the above text, and will not be repeated here.

[0169] In an exemplary embodiment, as Figure 9 shown, a resource transfer device 900 is provided, including: a receiving module 901, a verification module 902, a determination module 903, and an execution module 904, where:

[0170] The receiving module is configured to receive a resource transfer request for a target wallet; the resource transfer request includes request content and participant signatures of at least one participant.

[0171] A verification module for verifying the validity of the signatures of each participating party.

[0172] A determination module for determining a wallet key based on the signatures of the participating parties that pass the validity verification when the number of signatures of the participating parties that pass the validity verification reaches a first quantity.

[0173] An execution module for performing a resource transfer operation according to the wallet key and the request content.

[0174] In some embodiments, the verification module is further configured to decrypt the signatures of each participating party to obtain the participating party data of each participating party; perform a validity verification based on the participating party data to obtain a validity verification result; the validity verification result includes passing the validity verification or failing the validity verification.

[0175] In some embodiments, the participating party data includes the pre-consent content and the signature time of the participating party. The verification module is further configured to, for any participating party, match the pre-consent content of the targeted participating party with the request content in the resource transfer request to obtain a matching result; verify the validity of the signature time of the targeted participating party; and determine that the signature of the targeted participating party passes the validity verification when the matching result indicates a successful match and the signature time is valid.

[0176] In some embodiments, the participating party data includes the pre-consent content of the participating party and the signatures of other participating parties. The verification module is further configured to, for any participating party, match the pre-consent content of the targeted participating party with the request content in the resource transfer request to obtain a matching result; determine the signatures of the participating parties included in the participating party data of the targeted participating party; detect whether the levels to which the other participating parties to which the included signatures of the participating parties belong cover all levels lower than the level to which the targeted participating party belongs; if so, and the matching result indicates a successful match, then determine that the signature of the targeted participating party passes the validity verification.

[0177] In some embodiments, the determination module is further configured to determine a wallet key based on the signatures of the participating parties that pass the validity verification when the number of signatures of the participating parties that pass the validity verification reaches a first quantity and the levels of the participating parties from which the signatures of the participating parties that pass the validity verification are sourced include a preset level.

[0178] In some embodiments, the verification module is further configured to determine the participating party identifier corresponding to each participating party respectively; obtain the public key of the participating party that matches each participating party identifier; and decrypt the corresponding signature of the participating party through the public key of the participating party to obtain the participating party data.

[0179] In some embodiments, the determination module is further configured to obtain the sub-keys in the signatures of the participating parties that pass the validity verification; and generate a wallet key according to the first quantity of sub-keys.

[0180] In some embodiments, the device further includes a transfer module configured to obtain a wallet key, generate a second quantity of sub-keys based on the wallet key; the second quantity is greater than the first quantity; transfer the second quantity of sub-keys to the second quantity of participants; wherein each participant stores one of the sub-keys.

[0181] In some embodiments, the transfer module is further configured to receive key-encrypted data sent by a participant; the key-encrypted data is obtained by encrypting a first shared key with the participant's private key; decrypt the key-encrypted data with the participant's public key to obtain the first shared key; encrypt the sub-key with the first shared key and transfer the encrypted sub-key to the participant.

[0182] In some embodiments, the transfer module is further configured to obtain a random bit string, for any bit value in the random bit string, randomly select a polarization basis, and encode the targeted bit value according to the selected polarization basis to obtain a quantum bit; send each quantum bit to a participant to instruct the participant to perform a measurement on each quantum bit based on the randomly selected polarization basis to obtain the measurement results of each quantum bit; obtain the polarization bases selected by the participant, and match the locally selected polarization bases with the polarization bases selected by the participant to determine the successfully matched polarization bases; determine a second shared key based on the bit values corresponding to the successfully matched polarization bases; encrypt the sub-key with the second shared key and transfer the encrypted sub-key to the participant.

[0183] In some embodiments, the transfer module is further configured to use the bit values corresponding to the successfully matched polarization bases as target bit values; disclose some of the target bit values and obtain some data disclosed by the participant; if the locally disclosed some bit values are consistent with the some data disclosed by the participant, determine a shared key based on the target bit values, otherwise discard the target bit values and return to the step of obtaining a random bit string to continue execution until a second shared key is obtained and then stop.

[0184] Each module in the above resource transfer device can be implemented in whole or in part by software, hardware, and their combination. Each of the above modules can be embedded in or independent of a processor in a computer device in the form of hardware, or stored in a memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0185] In an exemplary embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 10As shown in the figure. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store resource transfer-related data. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through a network connection. The computer program, when executed by the processor, implements a resource transfer method.

[0186] Those skilled in the art can understand that Figure 10 the structure shown in the figure is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0187] In one embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0188] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, the steps in the above method embodiments are implemented.

[0189] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by the processor, the steps in the above method embodiments are implemented.

[0190] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with relevant regulations.

[0191] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memories can include read-only memory (ROM), magnetic tapes, floppy disks, flash memories, optical memories, high-density embedded non-volatile memories, resistive random access memories (ReRAM), magnetoresistive random access memories (MRAM), ferroelectric random access memories (FRAM), phase change memories (PCM), graphene memories, etc. Volatile memories can include random access memory (RAM) or external cache memories, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logics, data processing logics based on quantum computing, etc., without limitation.

[0192] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0193] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A resource transfer method, characterized in that, The method includes: Receiving a resource transfer request for a target wallet; the resource transfer request includes a request content and the participation signatures of at least one participant; Verifying the validity of each of the participation signatures; When the number of participation signatures that pass the validity check reaches a first number, determining a wallet key based on the participation signatures that pass the validity check; Performing a resource transfer operation according to the wallet key and the request content.

2. The method according to claim 1, characterized in that, The verifying the validity of each of the participation signatures includes: Decrypting each of the participation signatures to obtain the participation data of each participant; Performing a validity check based on the participation data to obtain a validity check result; the validity check result includes passing the validity check or failing the validity check.

3. The method according to claim 2, characterized in that, The participation data includes the pre-consented content and the signature time of the participant. The performing a validity check based on the participation data to obtain a validity check result includes: For any participant, matching the pre-consented content of the targeted participant with the request content in the resource transfer request to obtain a matching result; Verifying the validity of the signature time of the targeted participant; When the matching result indicates a successful match and the signature time is valid, determining that the participation signature of the targeted participant passes the validity check.

4. The method according to claim 2, characterized in that, The participation data includes the pre-consented content of the participant and the participation signatures of other participants. The performing a validity check based on the participation data to obtain a validity check result includes: For any participant, matching the pre-consented content of the targeted participant with the request content in the resource transfer request to obtain a matching result; Determining the participation signatures included in the participation data of the targeted participant; Detecting whether the levels to which the other participants to which the included participation signatures belong cover all levels lower than the level to which the targeted participant belongs; If so, and the matching result indicates a successful match, determining that the participation signature of the targeted participant passes the validity check.

5. The method according to claim 2, characterized in that, The decrypting each of the participation signatures to obtain the participation data of each participant includes: Determining a participant identifier corresponding to each participant respectively; Obtaining a participant public key that matches each participant identifier; Decrypting the corresponding participation signature through the participant public key to obtain the participation data.

6. The method according to claim 1, characterized in that, The when the number of participation signatures that pass the validity check reaches a first number, determining a wallet key based on the participation signatures that pass the validity check includes: When the number of participation signatures that pass the validity check reaches a first number and the levels of the participants from which the participation signatures that pass the validity check originate include a preset level, determining a wallet key based on the participation signatures that pass the validity check.

7. The method according to any one of claims 1 to 6, characterized in that, The determining a wallet key based on the participation signatures that pass the validity check includes: Obtaining the sub-keys in the participation signatures that pass the validity check; Generating a wallet key according to the first number of sub-keys.

8. The method according to claim 7, characterized in that, The method further includes: Obtaining a wallet key and generating a second number of sub-keys based on the wallet key; the second number is greater than the first number; Transfer the second quantity of sub-keys to the second quantity of participants; wherein each participant stores one of the sub-keys.

9. The method according to claim 8, characterized in that, The transfer step of any one sub-key includes: Receive the key-encrypted data sent by the participant; the key-encrypted data is obtained by encrypting the first shared key with the participant's private key; Decrypt the key-encrypted data with the participant's public key to obtain the first shared key; Encrypt the sub-key with the first shared key and transfer the encrypted sub-key to the participant.

10. The method according to claim 8, wherein, The transfer step of any one sub-key includes: Obtain a random bit string. For any bit value in the random bit string, randomly select a polarization basis and encode the targeted bit value according to the selected polarization basis to obtain a quantum bit; Send each quantum bit to the participant to instruct the participant to perform measurements on each quantum bit based on the randomly selected polarization basis to obtain the measurement results of each quantum bit; Obtain the polarization bases selected by the participant and match the locally selected polarization bases with the polarization bases selected by the participant to determine the successfully matched polarization bases; Determine the second shared key based on the bit values corresponding to the successfully matched polarization bases; Encrypt the sub-key with the second shared key and transfer the encrypted sub-key to the participant.

11. The method according to claim 10, wherein, The determining the second shared key based on the bit values corresponding to the successfully matched polarization bases includes: Take the bit values corresponding to the successfully matched polarization bases as the target bit values; Disclose some of the target bit values and obtain the partial data disclosed by the participant; If the partial bit values disclosed locally are consistent with the partial data disclosed by the participant, determine the shared key based on the target bit values; otherwise, discard the target bit values and return to the step of obtaining the random bit string to continue execution until the second shared key is obtained and then stop.

12. A resource transfer device, wherein, The device includes: A receiving module, configured to receive a resource transfer request for a target wallet; the resource transfer request includes a request content and the participant signatures of at least one participant; A verification module, configured to verify the validity of each of the participant signatures; A determination module, configured to determine the wallet key according to the participant signatures that pass the validity verification when the number of participant signatures that pass the validity verification reaches the first quantity; An execution module, configured to perform a resource transfer operation according to the wallet key and the request content.

13. A computer device, including a memory and a processor, the memory stores a computer program, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, on which a computer program is stored, wherein, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 11.

15. A computer program product, including a computer program, wherein, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 11.

Images