Block chain withdrawal method and device

Abstract

The invention discloses a block chain withdrawal method and device, and the method comprises the steps: receiving an authorization certificate and a withdrawal request sent by an authorized party, the authorization certificate being granted to the authorized party under a chain by an authorization party and comprising a first sub-certificate and a second sub-certificate, the first sub-certificate being used for representing the identity information of the authorization party, and the second sub-certificate being used for representing the identity information of the authorization party; the second sub-proof is used for representing channel information that the authorization party authorizes to withdraw the cash to the authorized party, verifying whether the first sub-proof is passed or not according to the public key of the authorization party and the first random number, verifying whether the second sub-proof is passed or not according to the second random number and the channel information, and refusing the cash withdrawal request if the verification of any one of the sub-proof is not passed. By adopting the method, the privacy security in a third-party withdrawal scene can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain withdrawal method and apparatus. Background Technology

[0002] In recent years, the rapid development of blockchain technology has attracted widespread global attention. Its decentralized and immutable characteristics make it a promising solution for blockchain scalability. The payment sector, with its high demand for trust and efficiency, has become an important application scenario for blockchain technology, giving rise to blockchain payments.

[0003] In existing technical solutions, the channel owner and the channel counterparty create an off-chain joint account. The channel owner generates a withdrawal request and submits it to a validator on the blockchain, who then verifies the withdrawal request and executes the withdrawal. However, this solution only supports withdrawals initiated by the channel owner. In real-world scenarios, the need for third-party withdrawals is common. The existing solution lacks the functionality for third-party withdrawals, resulting in insufficient applicability in complex transaction scenarios and an inability to meet diverse business needs. Summary of the Invention

[0004] This application provides a blockchain withdrawal method and apparatus to improve privacy and security in third-party withdrawal scenarios.

[0005] In a first aspect, embodiments of this application provide a blockchain withdrawal method. This method is applied to a validator and can be executed by a blockchain withdrawal device. The method includes: receiving an authorization credential and a withdrawal request sent by an authorized party. The authorization credential is granted off-chain by the authenticator to the authorized party and includes a first sub-proof and a second sub-proof. The first sub-proof represents the identity information of the authenticator; the second sub-proof represents the channel information authorized by the authenticator for withdrawal to the authorized party; verifying whether the first sub-proof passes based on the authenticator's public key and a first random number; the first random number is sent by the validator to the authenticator when the authenticator generates the first sub-proof; verifying whether the second sub-proof passes based on a second random number and the channel information; the second random number is sent by the validator to the authenticator when the authenticator generates the second sub-proof; if any of the above sub-proofs fails verification, the withdrawal request is rejected.

[0006] Using the above method, based on the first random number, the authorizing party's public key, and the second random number, the first and second sub-proofs sent by the authorized party can be verified, thus verifying the correctness of the authorizing party's identity information and the channel information authorized by the authorizing party. The authorizing party's private key is always stored locally by the authorizing party, with zero risk of leakage, ensuring the security of the authorizing party's information from being leaked in third-party withdrawal scenarios.

[0007] In one possible implementation, the first sub-proof includes a first verification value and a second verification value; the second sub-proof includes a third verification value and a fourth verification value; verifying whether the first sub-proof passes based on the authorizing party's public key and a first random number includes: determining a first verification object using the first verification value, and comparing it with a second verification object determined using the first random number, the second verification value, and the authorizing party's public key to determine whether the first sub-proof passes; verifying whether the second sub-proof passes based on a second random number and the channel information includes: determining whether the second sub-proof passes based on a third verification object determined using the third verification value, and a fourth verification object determined using the fourth verification value, the second random number, and the channel information.

[0008] In one possible implementation, the method further includes: receiving a withdrawal signature sent by the authorized party, the withdrawal signature being generated based on the authorized party's private key, the withdrawal request, and the authorizing party's authorization statement; decrypting the withdrawal signature based on the authorized party's public key to obtain first verification information; decrypting the authorization credential based on the authorizing party's public key to obtain the authorizing party's authorization statement; obtaining second verification information based on the authorizing party's authorization statement and the withdrawal request; and rejecting the withdrawal request if the verification results corresponding to the first verification information and the second verification information fail.

[0009] Using the above method, after receiving the withdrawal signature, authorization certificate and withdrawal request sent by the authorized party, the verifier can verify the withdrawal signature. If the verification fails, it means that the signature has been tampered with, and the withdrawal request is rejected, thus ensuring the security of third-party withdrawal scenarios.

[0010] In one possible implementation, the method further includes: decrypting the authorization credential using the authorizing party's public key to obtain the authorizing party's authorization statement; verifying whether any withdrawal item in the withdrawal request matches the corresponding authorization item in the authorization statement; if they do not match, rejecting the withdrawal request; the authorization item in the authorization statement includes at least one of the following: withdrawal amount limit, withdrawal validity period, withdrawal frequency threshold, and authorization channel information; the withdrawal item in the withdrawal request includes at least one of the following: withdrawal amount, withdrawal request time, current withdrawal frequency, and withdrawal channel information.

[0011] By employing the above method, each withdrawal request in the authorization statement is verified to ensure it meets the authorization requirements, preventing the authorized party's withdrawal requests from exceeding the scope of the authorizing party's authorization. This safeguards the legitimacy of third-party withdrawal scenarios.

[0012] In one possible implementation, the method further includes: if all verification results pass, determining whether the withdrawal amount in the withdrawal request for the target withdrawal channel meets the balance of the target withdrawal channel; if it does, withdrawing funds from the target withdrawal channel, encrypting the withdrawn balance, and uploading it to the blockchain.

[0013] Using the above method, the verifier receives the authorization certificate, withdrawal request, and withdrawal signature off-chain. That is, the authorization certificate, withdrawal request, and withdrawal signature are all transmitted off-chain, avoiding privacy leaks caused by on-chain disclosure. Furthermore, only the final balance is stored on-chain in encrypted form, reducing the number of on-chain interactions, lowering on-chain load, avoiding on-chain congestion, and balancing privacy protection and authorization confirmation efficiency in third-party withdrawal scenarios.

[0014] In one possible implementation, the method further includes: receiving an authorization revocation statement sent by the authorizing party and storing the authorization revocation statement in the revocation record of the blockchain; the authorization revocation statement includes an identifier of the revoked authorization statement and a revocation timestamp; after receiving the authorization credential and withdrawal request sent by the authorized party, the method further includes: determining whether the authorization statement corresponding to the authorization credential is included in the revocation record, and whether the withdrawal timestamp in the withdrawal request is later than the revocation timestamp; if so, the withdrawal request is rejected.

[0015] Using the above method, it is also possible to receive authorization revocation statements sent by the authorizing party. After receiving the authorization certificate and withdrawal request sent by the authorized party, it is also necessary to verify whether the authorization statement applicable to the authorized party's withdrawal has been revoked, which further protects the validity of the authorizing party's authorization and prevents the authorized party from making withdrawals when the authorization statement has expired.

[0016] Secondly, this application provides another blockchain withdrawal method. This method is applied to an authorized party and executed by a blockchain withdrawal device. The method includes: obtaining an authorization credential granted by an authorizing party off-chain; the authorization credential includes a first sub-proof and a second sub-proof; the first sub-proof represents the identity information of the authorizing party; the second sub-proof represents the channel information authorized by the authorizing party for withdrawal to the authorized party; generating a withdrawal request that satisfies the authorization credential; and sending the withdrawal request and the authorization credential to a verifier in the blockchain; wherein the first sub-proof is generated by the authorizing party based on its private key and a first random number, the first random number being sent by the verifier; and the second sub-proof is generated by the authorizing party based on a second random number, the second random number being sent by the verifier.

[0017] In one possible implementation, the method further includes: signing the withdrawal request and the authorization statement sent by the authorizing party using its own private key to obtain a withdrawal signature; and sending the withdrawal signature to the verifying party.

[0018] Thirdly, this application provides another blockchain withdrawal method. This method is applied to an authorizing party and executed by a blockchain withdrawal device. The method includes: sending a first request and a second request to a verifier; receiving a first random number generated by the verifier based on the first request and a second random number generated based on the second request; generating a first sub-proof based on the first random number and its own private key; generating a second sub-proof based on the second random number and channel information authorized to the authorized party for withdrawal; generating an authorization certificate based on the first sub-proof, the second sub-proof, and the authorization statement, and sending it to the authorized party off-chain; wherein the authorization statement is generated based on the authorized project authorized to the authorized party.

[0019] In one possible implementation, generating a first sub-proof based on the first random number and the user's private key includes: generating a first verification value based on a generator and a first prime number; generating a second verification value based on the user's private key, the first random number, and the first prime number; the first sub-proof includes the first verification value and the second verification value. Generating a second sub-proof based on the second random number and channel information authorized for withdrawal by the authorized party includes: generating a third verification value based on the generator and the second prime number; generating a fourth verification value based on the second random number, the channel information, and the second prime number; the second sub-proof includes the third verification value and the fourth verification value.

[0020] Fourthly, this application provides a blockchain withdrawal device, comprising: a receiving module for receiving an authorization certificate and a withdrawal request sent by an authorized party, wherein the authorization certificate is granted off-chain by the authorizing party to the authorized party and includes a first sub-proof and a second sub-proof; the first sub-proof is used to characterize the identity information of the authorizing party; the second sub-proof is used to characterize the channel information authorized by the authorizing party for withdrawal to the authorized party; a verification module for verifying whether the first sub-proof passes based on the authorizing party's public key and a first random number; the first random number is sent by the verification party to the authorizing party when the authorizing party generates the first sub-proof; and verifying whether the second sub-proof passes based on a second random number and the channel information; the second random number is sent by the verification party to the authorizing party when the authorizing party generates the second sub-proof; and a processing module for rejecting the withdrawal request if any of the above sub-proofs fails verification.

[0021] In one possible implementation, the first sub-proof includes a first verification value and a second verification value; the second sub-proof includes a third verification value and a fourth verification value; the verification module is specifically used to: determine a first verification object using the first verification value, and determine whether the first sub-proof passes by comparing it with a second verification object determined using the first random number, the second verification value, and the public key of the authorizing party; and determine whether the second sub-proof passes by comparing the third verification object determined by the third verification value with a fourth verification object determined by the fourth verification value, the second random number, and the channel information.

[0022] In one possible implementation, the receiving module is further configured to: receive a withdrawal signature sent by the authorized party, the withdrawal signature being generated based on the authorized party's private key, the withdrawal request, and the authorizing party's authorization statement; the verification module is further configured to: decrypt the withdrawal signature based on the authorized party's public key to obtain first verification information; decrypt the authorization credential based on the authorizing party's public key to obtain the authorizing party's authorization statement; obtain second verification information based on the authorizing party's authorization statement and the withdrawal request; and if the verification results corresponding to the first verification information and the second verification information fail, then the withdrawal request is rejected.

[0023] In one possible implementation, the verification module is further configured to: decrypt the authorization credential based on the authorizing party's public key to obtain the authorizing party's authorization statement; verify whether any withdrawal item in the withdrawal request matches the corresponding authorization item in the authorization statement; if they do not match, reject the withdrawal request; the authorization item in the authorization statement includes at least one of the following: withdrawal amount limit, withdrawal validity period, withdrawal frequency threshold, and authorization channel information; the withdrawal item in the withdrawal request includes at least one of the following: withdrawal amount, withdrawal request time, current withdrawal frequency, and withdrawal channel information.

[0024] In one possible implementation, if all verification results pass, the verification module is further configured to determine whether the withdrawal amount in the withdrawal request for the target withdrawal channel meets the balance of the target withdrawal channel; the processing module is further configured to, if it meets the requirement, perform a withdrawal on the target withdrawal channel, encrypt the withdrawal balance after withdrawal, and upload it to the blockchain.

[0025] In one possible implementation, the receiving module is further configured to receive an authorization revocation statement sent by the authorizing party, and the processing module is further configured to store the authorization revocation statement in the revocation record of the blockchain; the authorization revocation statement includes an identifier of the revoked authorization statement and a revocation timestamp; the verification module is further configured to determine whether the authorization statement corresponding to the authorization credential is included in the revocation record, and whether the withdrawal timestamp in the withdrawal request is later than the revocation timestamp; if so, the withdrawal request is rejected.

[0026] Fifthly, this application embodiment also provides a blockchain withdrawal device, the device comprising: an acquisition module, configured to acquire an authorization credential granted by an authorizing party through off-chain means, the authorization credential including a first sub-proof and a second sub-proof; the first sub-proof being used to characterize the identity information of the authorizing party; the second sub-proof being used to characterize the channel information authorized by the authorizing party for withdrawal to the authorized party; a generation module, configured to generate a withdrawal request that satisfies the authorization credential; and a sending module, configured to send the withdrawal request and the authorization credential to a verifier in the blockchain; wherein, the first sub-proof is generated by the authorizing party based on its own private key and a first random number, the first random number being sent by the verifier; the second sub-proof is generated by the authorizing party based on a second random number, the second random number being sent by the verifier.

[0027] In one possible implementation, the device further includes a signature module, which is used to sign the withdrawal request and the authorization statement sent by the authorizing party according to its own private key to obtain a withdrawal signature; the sending module is further used to send the withdrawal signature to the verifying party.

[0028] Sixthly, embodiments of this application also provide a blockchain withdrawal device, the device comprising a sending module for sending a first request and a second request to a verifier; a receiving module for receiving a first random number generated by the verifier based on the first request and a second random number generated based on the second request; a generating module for generating a first sub-proof based on the first random number and its own private key; generating a second sub-proof based on the second random number and channel information authorized to the authorized party for withdrawal; and generating an authorization certificate based on the first sub-proof, the second sub-proof, and the authorization statement; the sending module is further configured to send the certificate to the authorized party off-chain; wherein the authorization statement is generated based on the authorized project authorized to the authorized party.

[0029] In one possible implementation, the generation module is specifically configured to: generate a first verification value based on the generator and a first prime number; generate a second verification value based on the private key, the first random number, and the first prime number; the first sub-proof includes the first verification value and the second verification value; generate a third verification value based on the generator and the second prime number; generate a fourth verification value based on the second random number, the channel information, and the second prime number; and the second sub-proof includes the third verification value and the fourth verification value.

[0030] In a seventh aspect, embodiments of this application provide a blockchain withdrawal device, which includes a memory and a processor. The memory is used to store computer programs or instructions; the processor is used to call the computer programs or instructions stored in the memory to execute the methods in any of the possible implementations of the first to third aspects.

[0031] Eighthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when read and executed by a computer, cause the computer to perform a method as described in any of the possible implementations of the first to third aspects.

[0032] Ninthly, embodiments of this application provide a computer program product storing instructions that, when read and executed by a computer, cause the computer to perform a method as described in any of the possible implementations of the first to third aspects. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram of a blockchain withdrawal method provided in an embodiment of this application; Figure 2 This application provides a three-party interaction flowchart corresponding to a blockchain withdrawal method. Figure 3 This application provides an embodiment of a blockchain withdrawal device with internal modules as shown in the schematic diagram. Figure 4 A schematic diagram of the internal modules of another blockchain withdrawal device provided in this application embodiment; Figure 5 A schematic diagram of the internal modules of another blockchain withdrawal device provided in this application embodiment; Figure 6 This is a schematic diagram of a blockchain withdrawal device provided in an embodiment of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] With the commercialization of blockchain technology, blockchain withdrawal technology has also developed rapidly. In existing technical solutions, the roles involved in blockchain withdrawals only include the channel owner and the validator. The channel owner constructs a withdrawal request and submits it to the validator, who verifies the request. If the verification is successful, the withdrawal is executed, and the balance of the withdrawal channel is updated. However, in real-world scenarios, requests requiring third-party participation in withdrawals are common. For example, a company may have dozens of off-chain payment channels and need to authorize its finance team members to manage withdrawal operations for different channels; or an individual user may hold earnings on an off-chain payment platform and need to authorize the platform to automatically withdraw to a designated account. In scenarios involving third-party withdrawals, if authorization is granted to a third party through private key sharing, there is a risk of private key leakage, and this risk increases exponentially with the number of people sharing the key. If authorization is granted to a third party through on-chain registration of authorization records, there is a risk of leakage of sensitive information such as channel identifiers and authorized amounts.

[0037] Based on this, this application provides a blockchain withdrawal method to improve privacy and security in third-party withdrawal scenarios.

[0038] In this embodiment of the application, the roles involved in blockchain withdrawal include the authorizing party, the authorized party, and the verifying party. The authorizing party is the owner of the off-chain payment channel, such as a company; the authorized party is a third party, such as the company's financial personnel; the verifying party is the on-chain smart contract or the channel counterparty; and the payment channel is the off-chain joint account of the authorizing party and the channel counterparty.

[0039] The blockchain withdrawal method in this application involves four stages. Figure 1 This is a schematic diagram illustrating a blockchain withdrawal method provided in an embodiment of this application. Figure 1 As can be seen, the method includes four stages: the generation and transmission of authorization credentials by the authorizing party; the generation of withdrawal requests by the authorized party; the verification and execution by the verifying party; and the revocation of authorization by the authorizing party.

[0040] exist Figure 1Based on the first three stages provided, this application offers a three-party interaction flowchart corresponding to a blockchain withdrawal method, such as... Figure 2 As shown, each party can be executed by a blockchain withdrawal device. Figure 2 As shown, the process includes the following steps: (I) First stage: Generation and transmission of authorization credentials The first stage involves off-chain operations by the authorizing party, the core of which is for the authorizing party to generate a valid authorization certificate and securely transmit it to the authorized party.

[0041] Step 201: The authorizing party sends a first request and a second request to the verifying party, and receives a first random number generated by the verifying party based on the first request and a second random number generated by the verifying party based on the second request.

[0042] Specifically, when generating the first sub-proof or before generating the first sub-proof, the authorizing party sends a first request to the verifying party. The random number in the first request is used to prove the authorizing party's identity information. When generating the second sub-proof or before generating the second sub-proof, the authorizing party sends a second request to the verifying party. The random number in the second request is used to prove the channel information that the authorizing party authorized the authorized party to withdraw funds. For example, the authorizing party sends the first request to the verifying party, and the verifying party generates a first random number e. The authorizing party sends a second request to the verifying party, and the verifying party generates a second random number f. , Let be the set of non-zero integers modulo q. The verifier sends the first and second random numbers it generates to the authorizing party.

[0043] Step 202: The authorizing party generates a first sub-proof based on the first random number and its own private key; and generates a second sub-proof based on the second random number and the channel information authorized to the authorized party for withdrawal.

[0044] For example, generating a first sub-proof based on a first random number and one's own private key includes: generating a first verification value based on a generator and a first prime number, and generating a second verification value based on one's own private key, the first random number, and the first prime number. The first sub-proof includes the first verification value and the second verification value.

[0045] Specifically, the licensor randomly selects ， calculate The authorizing party calculates s = (a - e) sk_A) mod q, generating the first sub-proof π1 = (A1, s). Where sk_A is the authorizing party's private key, g is the generator in the ElGamal algorithm, q is a large prime number in the ElGamal algorithm, A1 is the first verification value, and A2 is the second verification value.

[0046] The process of generating the second sub-proof based on the second random number and the channel information authorized to the authorized party for withdrawal includes: generating the third verification value based on the generator and the second prime number, and generating the fourth verification value based on the second random number, the channel information, and the second prime number. The second sub-proof includes the third verification value and the fourth verification value.

[0047] Specifically, each authorized channel The licensor randomly selects ,calculate ;calculate Where I is an indicator function, if If q is a large prime number, then I=1; otherwise, I=0. The second sub-proof π² = ({B_β_A,X, B_β_A,Y}, {s_β_A,X, s_β_A,Y}) is generated. g is the generator in the ElGamal algorithm, q is a large prime number in the ElGamal algorithm, and the large prime number used to generate the second sub-proof can be different from the large prime number used to generate the first sub-proof. B_β_A,X and B_β_A,Y are the third verification values, and s_β_A,X and s_β_A,Y are the fourth verification values. When there is one authorized channel, both the third and fourth verification values ​​are one; when there are two authorized channels, both the third and fourth verification values ​​are two.

[0048] Step 203: The authorizing party generates an authorization credential based on the first sub-proof, the second sub-proof, and the authorization statement, and sends it to the authorized party off-chain.

[0049] Specifically, the authorization statement is generated by the authorizing party based on the authorized project authorized to the authorized party. For example, the authorization statement includes the authorizing party's public key: pk_A = 0x5F3a8b2d...; the authorized party's public key: pk_B = 0x9C4e...; the channel list: CH = [0x8D2b..., 0x3E7c...]; the maximum amount: m_max = 1000 USDT; the validity period: [1759315200, 1761993600]; the maximum number of uses: cnt_max = 3; and the statement generation timestamp: t_S = 1759228800 (2025-09-30 00:00:00). The authorizing party calculates the hash value H(S) = SHA-256(S) of the authorization statement S, and merges the first sub-proof, the second sub-proof, and H(S) to obtain the final proof. By using the above method, the scope of authorization, such as the maximum withdrawal amount, the validity period of withdrawal, the number of withdrawals, and the withdrawal channel, is converted into verifiable mathematical constraints, thereby refining the permission constraints and improving the controllability of authorization.

[0050] The authorizing party packages the authorization statement S and the proof π to generate the authorization credential Voucher = (S, π). Since the authorizing party and the authorized party can obtain each other's public keys, the authorizing party uses the authorized party's public key pk_B and its own private key sk_A to calculate a temporary shared value. The authorized party uses its own private key sk_B and the authorizing party's public key pk_A to calculate the same temporary shared value. Both parties then perform hashing and other processing on this identical temporary shared value to obtain the shared key K. Further, the authorizing party uses the shared key K to encrypt the authorization credential Voucher using the AES-256-GCM algorithm, generating the encrypted Voucher_enc, and sends it to the authorized party through an off-chain channel, such as an internal enterprise encrypted communication system.

[0051] (ii) Second stage: The authorized party generates a withdrawal request

[0052] The authorized party obtains the authorization credential granted by the licensor through off-chain methods. The authorization credential includes a first sub-proof and a second sub-proof. The first sub-proof represents the licensor's identity information, and the second sub-proof represents the channel information authorized by the licensor for withdrawals to the authorized party. The first sub-proof is generated by the licensor using its own private key and a first random number sent by the verifier; the second sub-proof is generated by the licensor using a second random number sent by the verifier.

[0053] Step 204: The authorized party generates a withdrawal request that satisfies the authorization certificate and sends the withdrawal request and authorization certificate to the verifier in the blockchain.

[0054] Specifically, the authorized party uses the shared key to decrypt the encrypted authorization credential, obtains the authorization credential Voucher (S,π), confirms that the current time t_request=1760524800, i.e., 2025-10-15 00:00:00, is within the validity period, and plans to withdraw the amount. Target channel Further, the authorized party generates a withdrawal request R that satisfies the authorization credentials. For example, the withdrawal request R consists of: target channel identifier: β_target = 0x8D2b...; withdrawal amount: m_withdraw = 800 USDT; current withdrawal count: cnt_current = 1; request timestamp: t_request = 1760524800; authorized party public key: pk_B = 0x9C4e... The authorized party then sends the generated withdrawal request and authorization credentials to the validator in the blockchain.

[0055] Step 205: The authorized party signs the withdrawal request and the authorization statement sent by the authorizing party using its own private key to obtain the withdrawal signature, and sends the withdrawal signature to the verifier.

[0056] Specifically, in one possible implementation, the authorized party calculates a hash value based on the withdrawal request R and the authorization statement S. Then, the authorized party signs the hash value using its own private key to generate a withdrawal signature σ_B = ECDSA (sk_B, H (R||H (S))). The authorized party then sends the withdrawal signature to the verifier, or the withdrawal signature can be sent simultaneously with the withdrawal request and authorization certificate.

[0057] (III) Third stage: Verification and execution by the verification party

[0058] The system receives authorization credentials and withdrawal requests from the authorized party. The authorization credentials are granted off-chain by the authorizing party and include a first sub-proof and a second sub-proof. The first sub-proof represents the authorizing party's identity information, and the second sub-proof represents the channel information authorized by the authorizing party for withdrawals. The system also receives a withdrawal signature from the authorized party, generated based on the authorized party's private key, the withdrawal request, and the authorizing party's authorization statement.

[0059] Specifically, since the verifier has pre-stored the authorizing party's public key and channel parameters, the verifier can decrypt the shared key K using the authorizing party's public key, and then decrypt the encrypted authorization credential to obtain the authorization credential Voucher (S, π), which includes an authorization statement.

[0060] Step 206: The verifier verifies whether the first sub-proof passes based on the authorizer's public key and the first random number, and verifies whether the second sub-proof passes based on the second random number and channel information. If either sub-proof fails verification, the withdrawal request is rejected.

[0061] The first random number is sent by the verifier to the authorizing party when the authorizing party generates the first sub-proof; the second random number is sent by the verifier to the authorizing party when the authorizing party generates the second sub-proof. The first sub-proof includes a first verification value and a second verification value, and the second sub-proof includes a third verification value and a fourth verification value.

[0062] Verifying whether the first sub-proof passes specifically includes determining the first verification object using the first verification value, and determining whether the first sub-proof passes by comparing it with the second verification object determined using the first random number, the second verification value, and the authorizing party's public key.

[0063] For example, the first verification object is determined by the first verification value A1, such as the first verification object being... The second verification object is determined by the first random number, the second verification value, and the authorizing party's public key. For example, the second verification object is... Based on the first and second verification objects, determine whether the first sub-proof passes, for example, verifying g^s. Does pk_A^e ≡ A1 mod q hold true? If the equation holds, the first sub-proof is verified; if the equation does not hold, the first sub-proof fails. A successful first sub-proof proves that the licensee's authorization was indeed granted by the licensor A, and not by any other licensor.

[0064] Optionally, the first verification object can be the first verification value, i.e., A1; the second verification object can be... In this case, if the calculation result of the second verification object is equal to the first verification value, then the first sub-proof is verified; if the calculation result of the second verification object is not equal to the first verification value, then the first sub-proof is not verified.

[0065] Verifying whether the second sub-proof passes specifically includes determining whether the second sub-proof passes by comparing the third verification object determined by the third verification value with the fourth verification object determined by the fourth verification value, the second random number, and the channel information.

[0066] For example, the third verification object determined based on the third verification value is The fourth verification object, determined based on the fourth verification value, the second random number, and the channel information, is... Calculate the value of the fourth verification object. If the value of the fourth verification object is equal to the value of the third verification object, the second sub-proof passes verification; if the value of the fourth verification object is not equal to the value of the third verification object, the second sub-proof fails verification. If either the first or second sub-proof fails verification, the authorized party's withdrawal request is rejected.

[0067] Step 207: The verifier decrypts the withdrawal signature using the authorized party's public key to obtain the first verification information; and obtains the second verification information based on the authorizing party's authorization statement and withdrawal request; if the verification results corresponding to the first and second verification information fail, the withdrawal request is rejected.

[0068] Specifically, due to withdrawal signature Therefore, the verifier decrypts the withdrawal signature using the authorized party's public key to obtain the first verification information, which is... Based on the authorization statement and withdrawal request from the authorizing party, the second verification information is obtained as follows: If the first verification information and the second verification information are the same, it proves that the signature has not been tampered with; if the first verification information and the second verification information are different, it proves that the signature has been tampered with, the withdrawal request is invalid, and the withdrawal request is rejected.

[0069] Step 208: The verifier verifies whether any withdrawal item in the withdrawal request matches the corresponding authorized item in the authorization statement. If they do not match, the withdrawal request is rejected.

[0070] The authorization statement includes at least one of the following: maximum withdrawal amount, withdrawal validity period, withdrawal frequency threshold, and authorized channel information. The withdrawal request includes at least one of the following: withdrawal amount, withdrawal request time, current withdrawal frequency, and withdrawal channel information. Verify whether any withdrawal item in the withdrawal request satisfies the corresponding authorization item in the authorization statement.

[0071] For example, the verification process includes: verifying whether the withdrawal amount is less than or equal to the maximum withdrawal amount; verifying whether the withdrawal request time falls within the withdrawal validity period; verifying whether the current number of withdrawals is less than or equal to the withdrawal number threshold; and verifying whether the target withdrawal channel's identifier belongs to the authorized channel list. If any of these conditions are not met, the verification party may reject the withdrawal request.

[0072] It should be noted that this application does not specify the order of the verification processes in steps 206, 207 and 208.

[0073] Step 209: If all verification results pass, the verifier determines whether the withdrawal amount in the withdrawal request for the target withdrawal channel meets the balance of the target withdrawal channel.

[0074] Specifically, the verifier invokes the security comparison protocol to read the current encrypted balance ciphertext C of the target channel β_A,X, and verifies whether the plaintext balance bal corresponding to ciphertext C is greater than or equal to the withdrawal amount.

[0075] In this application, only the balance of the target withdrawal channel and the withdrawal amount are compared, without disclosing the specific value of the target withdrawal channel; if the balance is less than the withdrawal amount, the authorized party's withdrawal request is rejected because the target withdrawal channel's balance is insufficient. If the balance is greater than or equal to the withdrawal amount, the authorized party's withdrawal request can be accepted.

[0076] Step 210: If the conditions are met, the verifier will withdraw funds from the target withdrawal channel and encrypt the withdrawn balance before uploading it to the blockchain.

[0077] Specifically, if the target withdrawal channel has a balance of 1500 USDT and the authorized party withdraws 800 USDT, then the target withdrawal channel will have a balance of 700 USDT after the withdrawal. The withdrawal balance is encrypted using the ElGamal algorithm and written to the smart contract storage area, completing the on-chain confirmation of the balance. Simultaneously, the verifier updates the authorized party's withdrawal count.

[0078] Step 211: Verify that the authorized party has returned a notification of successful withdrawal.

[0079] (iv) Fourth stage: Revocation of authorization

[0080] In one possible implementation, if the authorizing party needs to terminate the authorization to the authorized party early, such as when the authorized financial personnel leave the company, the authorizing party can initiate an authorization revocation statement and send it to the verifier. The authorization revocation statement includes an identifier of the revoked authorization statement and a revocation timestamp. For example, in the authorization revocation statement, the identifier of the revoked authorization statement is id_S = H(S) = SHA-256(S) = 0x4B...; this id_S is consistent with H(S) in the proof π; the revocation timestamp is t_rev = 1760956800. Furthermore, the authorizing party can also sign the hash value of the revoked authorization statement's identifier id_S and the revocation timestamp using its own private key to obtain a revocation signature, which is then sent to the verifier.

[0081] After receiving the authorization revocation statement from the authorizing party, the verifier stores the authorization revocation statement in the revocation record of the blockchain. Specifically, if the authorizing party sends a revocation signature to the verifier, the verifier uses the authorizing party's public key to verify the validity of the revocation signature. If the verification passes, the verifier stores the authorization revocation statement in the revocation record of the blockchain, triggers a revocation event, and notifies the relevant nodes.

[0082] Therefore, in one possible implementation, after receiving the authorization certificate and withdrawal request from the authorized party (i.e., after step 204), the verifier determines whether the authorization statement corresponding to the authorization certificate is included in the revocation record. If it is included, the verifier further verifies whether the withdrawal timestamp in the withdrawal request is later than the revocation timestamp. If it is later, it means that the licensor had terminated the authorization to the authorized party before the authorized party initiated the withdrawal request. Therefore, the withdrawal request initiated by the authorized party is invalid, and the verifier needs to reject the withdrawal request.

[0083] In one possible implementation, the authorization revocation statement needs to wait for blockchain block confirmation after being uploaded to the blockchain, which takes about 10-30 seconds. There is a potential risk of a time lag between the initiation of the authorization revocation statement and its upload to the blockchain, where the authorized party might initiate a withdrawal request. To address this, an off-chain pre-notification mechanism can be used. After initiating the authorization revocation statement, the authorizing party first sends an off-chain revocation notification to commonly used smart contracts and channel counterparties. Upon receiving this notification, the verifier temporarily stores it in a pending revocation list. Only after the authorization revocation statement is uploaded to the blockchain is the actual revocation statement stored in the blockchain's revocation record. In this way, after receiving the authorization certificate and withdrawal request from the authorized party, the verifier can also determine whether the authorization statement corresponding to the authorization certificate is included in the pending revocation list, thus shortening the risk window to less than or equal to 1 second.

[0084] Figure 3 This is a schematic diagram of the internal modules of a blockchain withdrawal device 3000 provided in an embodiment of this application. Figure 3 As shown, the system includes a receiving module 301, used to receive an authorization credential and a withdrawal request sent by the authorized party. The authorization credential is granted off-chain by the authorizing party to the authorized party and includes a first sub-proof and a second sub-proof. The first sub-proof is used to represent the identity information of the authorizing party. The second sub-proof is used to represent the channel information authorized by the authorizing party for withdrawal to the authorized party. A verification module 302 is used to verify whether the first sub-proof passes based on the authorizing party's public key and a first random number. The first random number is sent to the authorizing party by the verification party when the authorizing party generates the first sub-proof. The system also verifies whether the second sub-proof passes based on a second random number and the channel information. The second random number is sent to the authorizing party by the verification party when the authorizing party generates the second sub-proof. A processing module 303 is used to reject the withdrawal request if any of the above sub-proofs fails verification.

[0085] In one possible implementation, the first sub-proof includes a first verification value and a second verification value; the second sub-proof includes a third verification value and a fourth verification value; the verification module 302 is specifically used to: determine a first verification object using the first verification value, and determine whether the first sub-proof passes by comparing it with a second verification object determined using the first random number, the second verification value, and the public key of the authorizing party; and determine whether the second sub-proof passes by comparing it with a third verification object determined using the third verification value, and a fourth verification object determined using the fourth verification value, the second random number, and the channel information.

[0086] In one possible implementation, the receiving module 301 is further configured to: receive a withdrawal signature sent by the authorized party, the withdrawal signature being generated based on the authorized party's private key, the withdrawal request, and the authorizing party's authorization statement; the verification module 301 is further configured to: decrypt the withdrawal signature based on the authorized party's public key to obtain first verification information; decrypt the authorization credential based on the authorizing party's public key to obtain the authorizing party's authorization statement; obtain second verification information based on the authorizing party's authorization statement and the withdrawal request; and reject the withdrawal request if the verification results corresponding to the first verification information and the second verification information fail.

[0087] In one possible implementation, the verification module 302 is further configured to: decrypt the authorization credential based on the authorizing party's public key to obtain the authorizing party's authorization statement; verify whether any withdrawal item in the withdrawal request matches the corresponding authorization item in the authorization statement; if they do not match, reject the withdrawal request; the authorization item in the authorization statement includes at least one of the following: withdrawal amount limit, withdrawal validity period, withdrawal frequency threshold, and authorization channel information; the withdrawal item in the withdrawal request includes at least one of the following: withdrawal amount, withdrawal request time, current withdrawal frequency, and withdrawal channel information.

[0088] In one possible implementation, if all verification results pass, the verification module 302 is further configured to determine whether the withdrawal amount in the withdrawal request for the target withdrawal channel meets the balance of the target withdrawal channel; the processing module 303 is further configured to, if it meets the requirement, perform a withdrawal on the target withdrawal channel, encrypt the withdrawal balance after withdrawal, and upload it to the blockchain.

[0089] In one possible implementation, the receiving module 301 is further configured to receive an authorization revocation statement sent by the authorizing party, and the processing module 303 is further configured to store the authorization revocation statement in the revocation record of the blockchain; the authorization revocation statement includes an identifier of the revoked authorization statement and a revocation timestamp; the verification module 302 is further configured to determine whether the authorization statement corresponding to the authorization certificate is included in the revocation record, and whether the withdrawal timestamp in the withdrawal request is later than the revocation timestamp; if so, the withdrawal request is rejected.

[0090] Figure 4 This is a schematic diagram of the internal modules of another blockchain withdrawal device 4000 provided in an embodiment of this application. Figure 4 As shown, the system includes an acquisition module 401, used to acquire an authorization credential granted by an authorizing party through off-chain methods. The authorization credential includes a first sub-proof and a second sub-proof. The first sub-proof is used to represent the identity information of the authorizing party. The second sub-proof is used to represent the channel information authorized by the authorizing party for withdrawal to the authorized party. A generation module 402 is used to generate a withdrawal request that satisfies the authorization credential. A sending module 403 is used to send the withdrawal request and the authorization credential to a verifier in the blockchain. The first sub-proof is generated by the authorizing party based on its own private key and a first random number, which is sent by the verifier. The second sub-proof is generated by the authorizing party based on a second random number, which is sent by the verifier.

[0091] In one possible implementation, the device further includes a signature module 404, which is used to sign the withdrawal request and the authorization statement sent by the authorizing party according to its own private key to obtain a withdrawal signature; the sending module 403 is further used to send the withdrawal signature to the verifying party.

[0092] Figure 5 This is a schematic diagram of the internal modules of another blockchain withdrawal device 5000 provided in an embodiment of this application. Figure 5 As shown, the system includes a sending module 501, used to send a first request and a second request to the verifier; a receiving module 502, used to receive a first random number generated by the verifier based on the first request and a second random number generated based on the second request; a generating module 503, used to generate a first sub-proof based on the first random number and its own private key; and generate a second sub-proof based on the second random number and the channel information authorized to the authorized party for withdrawal; and generate an authorization credential based on the first sub-proof, the second sub-proof, and the authorization statement; the sending module 501 is also used to send the authorization credential to the authorized party off-chain; wherein the authorization statement is generated based on the authorized project authorized to the authorized party.

[0093] In one possible implementation, the generation module 503 is specifically configured to: generate a first verification value based on the generator and the first prime number; generate a second verification value based on the private key, the first random number, and the first prime number; the first sub-proof includes the first verification value and the second verification value; generate a third verification value based on the generator and the second prime number; generate a fourth verification value based on the second random number, the channel information, and the second prime number; and the second sub-proof includes the third verification value and the fourth verification value.

[0094] Figure 6 A schematic diagram 6000 of a blockchain withdrawal device structure is provided for an embodiment of this application. For example... Figure 6 As shown, it includes at least one processor 601 and a memory 602 connected to at least one processor 601. In this embodiment, the specific connection medium between the processor 601 and the memory 602 is not limited. Figure 6 Taking the connection between the processor 601 and the memory 602 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0095] In this embodiment of the application, the memory 602 stores instructions that can be executed by at least one processor 601. By executing the instructions stored in the memory 602, the at least one processor 601 can implement the steps of the blockchain withdrawal method described above.

[0096] The processor 601 is the control center of the computer device, capable of connecting various parts of the computer device via various interfaces and lines. It performs resource configuration by running or executing instructions stored in the memory 602 and accessing data stored in the memory 602. Optionally, the processor 601 may include one or more processing units. The processor 601 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601. In some embodiments, the processor 601 and the memory 602 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0097] Processor 601 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0098] Memory 602, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 602 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 602 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 602 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0099] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0100] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0101] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0102] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0103] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A blockchain withdrawal method, characterized in that, The method is applied to the verification party, and the method includes: The system receives authorization credentials and withdrawal requests from the authorized party. The authorization credentials are granted off-chain by the authorizing party and include a first sub-proof and a second sub-proof. The first sub-proof is used to represent the identity information of the authorizing party, and the second sub-proof is used to represent the channel information authorized by the authorizing party for withdrawal to the authorized party. The verification method verifies whether the first sub-proof passes based on the authorizing party's public key and a first random number; the first random number is sent by the verifier to the authorizing party when the authorizing party generates the first sub-proof. The second sub-proof is verified based on the second random number and the channel information; the second random number is sent by the verifier to the authorizing party when the authorizing party generates the second sub-proof. If any of the above sub-proofs fails verification, the withdrawal request will be rejected.

2. The method according to claim 1, characterized in that, The first sub-proof includes a first verification value and a second verification value; the second sub-proof includes a third verification value and a fourth verification value. Verifying whether the first sub-proof passes based on the authorizing party's public key and the first random number includes: The first verification object is determined by the first verification value, and the second verification object is determined by the first random number, the second verification value, and the public key of the authorizing party to determine whether the first sub-proof is successful. Based on the second random number and the channel information, verify whether the second sub-proof passes, including: Based on the third verification object determined by the third verification value, and the fourth verification object determined by the fourth verification value, the second random number, and the channel information, it is determined whether the second sub-proof passes.

3. The method according to claim 1, characterized in that, The method further includes: Receive a withdrawal signature sent by the authorized party, the withdrawal signature being generated based on the authorized party's private key, the withdrawal request, and the authorizing party's authorization statement; The withdrawal signature is decrypted using the authorized party's public key to obtain the first verification information; The authorization credential is decrypted using the authorizing party's public key to obtain the authorizing party's authorization statement; Based on the authorization statement of the authorizing party and the withdrawal request, the second verification information is obtained; If the verification results corresponding to the first verification information and the second verification information fail, the withdrawal request is rejected.

4. The method according to claim 1, characterized in that, The method further includes: The authorization credential is decrypted using the authorizing party's public key to obtain the authorizing party's authorization statement; Verify whether any withdrawal item in the withdrawal request matches the corresponding authorized item in the authorization statement; if they do not match, reject the withdrawal request. The authorization items in the authorization statement include at least one of the following: withdrawal limit, withdrawal validity period, withdrawal frequency threshold, and authorized channel information; the withdrawal items in the withdrawal request include at least one of the following: withdrawal amount, withdrawal request time, current withdrawal frequency, and withdrawal channel information.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: If all verification results pass, then determine whether the withdrawal amount in the withdrawal request for the target withdrawal channel meets the balance of the target withdrawal channel; If the conditions are met, the withdrawal will be processed through the target withdrawal channel, and the withdrawn balance will be encrypted and uploaded to the blockchain.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The system receives an authorization revocation statement from the authorizing party and stores the authorization revocation statement in the revocation record of the blockchain; the authorization revocation statement includes the identifier of the revoked authorization statement and the revocation timestamp; After receiving the authorization credentials and withdrawal request from the authorized party, the process also includes: Determine whether the authorization statement corresponding to the authorization certificate is included in the revocation record, and whether the withdrawal timestamp in the withdrawal request is later than the revocation timestamp; if so, reject the withdrawal request.

7. A blockchain withdrawal method, characterized in that, The method is applied to the authorized party, and the method includes: The authorization credential granted by the authorizing party is obtained off-chain. The authorization credential includes a first sub-proof and a second sub-proof. The first sub-proof is used to represent the identity information of the authorizing party. The second sub-proof is used to represent the channel information for withdrawal authorized by the authorizing party to the authorized party. Generate a withdrawal request that satisfies the authorization certificate, and send the withdrawal request and the authorization certificate to the verifier in the blockchain; The first sub-proof is generated by the authorizing party based on its own private key and a first random number, which is sent by the verifying party; the second sub-proof is generated by the authorizing party based on a second random number, which is sent by the verifying party.

8. The method according to claim 7, characterized in that, The method further includes: The withdrawal request and the authorization statement sent by the authorizing party are signed using the user's private key to obtain a withdrawal signature; The withdrawal signature is sent to the verifier.

9. A blockchain withdrawal method, characterized in that, The method is applied to the licensor, and the method includes: Send the first and second requests to the verification party; Receive the first random number generated by the verification party based on the first request and the second random number generated based on the second request; Generate a first sub-proof based on the first random number and its own private key; A second sub-proof is generated based on the second random number and the channel information authorized to the authorized party for withdrawal; Based on the first sub-proof, the second sub-proof, and the authorization statement, an authorization credential is generated and sent to the authorized party off-chain; wherein, the authorization statement is generated based on the authorized project authorized to the authorized party.

10. The method according to claim 9, characterized in that, Generate a first sub-proof based on the first random number and its own private key, including: A first verification value is generated based on the generator and the first prime number; a second verification value is generated based on the private key, the first random number, and the first prime number; the first sub-proof includes the first verification value and the second verification value; A second sub-proof is generated based on the second random number and the channel information authorized to the authorized party for withdrawal, including: A third verification value is generated based on the generator and the second prime number; a fourth verification value is generated based on the second random number, the channel information, and the second prime number; the second sub-proof includes the third verification value and the fourth verification value.

Images