Blockchain transfer transaction submission method and apparatus, and computer system

Abstract

This specification discloses a method, apparatus, and computer system for submitting blockchain transfer transactions. The method includes: first, based on a user-initiated transfer request for a privacy token, locking the resources of the user's blockchain account and retrieving the encrypted balance of the blockchain account from an off-chain storage module storing the blockchain world state; next, based on the plaintext transaction amount in the transfer request and the encrypted balance, submitting a transfer transaction invoking the privacy token contract to the blockchain and releasing the first lock; then, based on the assumption of successful execution of the transfer transaction, writing the updated encrypted balance into the off-chain storage module; finally, obtaining a transaction receipt for the transfer transaction and, if the receipt indicates successful transaction execution, ending the current process.

Description

1. Description of a Blockchain Transfer Transaction Submission Method, Apparatus, and Computer System Technical Field This specification relates to the field of blockchain technology, particularly to a blockchain transfer transaction submission method and apparatus, a computer system, and a computer-readable non-volatile storage medium. Background Technology Blockchain technology, with its decentralized and immutable data characteristics, has been widely used in finance, healthcare, and supply chain management. In practical applications, there exists a type of transaction with a partial order dependency. For example, in a blockchain transfer scenario, after user A transfers funds to user B, user B needs to transfer funds to user C. These two transactions have a causal dependency and must be executed sequentially. This partial order dependency limits the concurrent execution capability of transactions, significantly reducing the throughput of the blockchain system under high transaction load scenarios. Therefore, an optimization scheme is needed that can improve the overall performance of the blockchain system while handling partially order dependent transactions, for example, by increasing the upper limit of concurrent execution and increasing throughput. Summary of the Invention This specification describes a blockchain transfer transaction submission method, apparatus, and computer system, which can improve the concurrent execution capability of the blockchain system for privacy transfer transactions, thereby improving overall performance. According to a first aspect, a method for submitting a blockchain transfer transaction is provided. The method includes: based on a user-initiated transfer request for a privacy token, first locking the resources of the user's blockchain account, and retrieving the encrypted balance of the blockchain account from an off-chain storage module storing the state of the blockchain world; submitting a transfer transaction invoking a privacy token contract to the blockchain based on the plaintext transaction amount in the transfer request and the encrypted balance, and releasing the first lock; based on the assumption of successful execution of the transfer transaction, writing the updated encrypted balance into the off-chain storage module; obtaining a transaction receipt for the transfer transaction, and ending the current process if the receipt indicates successful transaction execution. According to a second aspect, a device for submitting a blockchain transfer transaction is provided. The device includes: a first locking module configured to lock the resources of a user's blockchain account based on a user-initiated transfer request for a privacy token; a local query module configured to query the encrypted balance of the blockchain account from an off-chain storage module storing the state of the blockchain world; a transaction submission module configured to submit a transfer transaction invoking the privacy token contract to the blockchain based on the plaintext transaction amount in the transfer request and the encrypted balance; a first unlocking module configured to unlock the first lock; a snapshot writing module configured to write the updated encrypted balance to the off-chain storage module based on the assumption of successful execution of the transfer transaction; a receipt acquisition module configured to acquire a transaction receipt for the transfer transaction; and a judgment processing module.The system is configured to terminate the current process if the transaction receipt indicates that the transaction was successfully executed. According to a third aspect, a computer system is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor; the processor performs the following steps: based on a user-initiated transfer request for a privacy token, it first locks the resources of the user's blockchain account and retrieves the encrypted balance of the blockchain account from an off-chain storage module storing the state of the blockchain world; based on the plaintext transaction amount in the transfer request and the encrypted balance, it submits a transfer transaction invoking the privacy token contract to the blockchain and releases the first lock; based on the assumption of successful execution of the transfer transaction, it writes the updated encrypted balance to the off-chain storage module; it obtains a transaction receipt for the transfer transaction and terminates the current process if the receipt indicates that the transaction was successfully executed. According to a fourth aspect, a computer-readable non-volatile storage medium is provided, wherein the storage medium stores a computer program that, when executed by a processor, implements the method described in the first aspect. In summary, by employing the methods, apparatus, and computer systems disclosed in the embodiments of this specification, multiple privacy transactions from the same account can be processed simultaneously by the blockchain and packaged into the same block, breaking the concurrency limit of 1 transaction / block. Brief Description of the Drawings: To more clearly illustrate the technical solutions of the embodiments of this invention, the drawings used in the following description of the embodiments are briefly introduced. Obviously, the drawings described below are only some embodiments of this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 shows the flow steps of a traditional generation and submission scheme for a transfer transaction. Figure 2 shows the flow steps of an off-chain storage module based on the world state of the scheme shown in Figure 1, as disclosed in the embodiments of this specification. Figure 3 shows the flow steps of a pre-computation scheme based on the scheme shown in Figure 2, as disclosed in the embodiments of this specification. Figure 4 shows the flow steps of a failure compensation mechanism based on the scheme shown in Figure 3, as disclosed in the embodiments of this specification. Figure 5 shows a functional module structure diagram of the blockchain transfer transaction submission device disclosed in the embodiments of this specification. HK 30135246 A 3 Figure 6 is a schematic diagram of the computer system provided in the embodiments of this specification. Detailed Implementation The following describes the scheme provided in this specification with reference to the accompanying drawings. To aid understanding, the main terms mentioned in the text are briefly explained first. 1) Key Pair: A private key sk and a corresponding public key pk are generated through a cryptographic algorithm. The party holding the private key sk can decrypt the original plaintext corresponding to the ciphertext encrypted using the public key pk. 2) Homomorphic Encryption: A form of encryption,Homomorphic encryption allows direct operation on the ciphertext corresponding to plaintext (the specific operation is designed based on target algebraic operations such as addition or multiplication, and there is no decryption throughout the process), resulting in an encrypted result. The decryption result is consistent with the result obtained by directly performing the target algebraic operation on the plaintext. The significance of homomorphic encryption lies in truly solving the confidentiality problem when data and its operations are entrusted to a third party. This paper uses Enc(pk, m) to represent the ciphertext obtained by homomorphically encrypting plaintext information m using public key pk. For redundant encryption (multiple public keys) or cases where the encryptor's public key is explicitly known, the pk parameter is omitted, i.e., Enc(m) represents the ciphertext obtained by homomorphically encrypting plaintext information m. Correspondingly, Dec(sk, Enc(pk, m)) represents decrypting the ciphertext Enc(pk, m) using the private key sk to obtain the plaintext m. Similarly, for redundant encryption (multiple public keys) or cases where the decryption party's private key is known, the sk and pk parameters are omitted in this paper, that is: Dec(Enc(m)) represents the plaintext m obtained after homomorphically decrypting the ciphertext Enc(m). 3) Homomorphic addition: The plaintext corresponding to the result of homomorphically adding two ciphertexts is the same as the result of directly adding the two corresponding plaintexts. 4) Homomorphic subtraction: The plaintext corresponding to the result of homomorphically subtracting two ciphertexts is the same as the result of directly subtracting the two corresponding plaintexts. 5) Zero-knowledge proof: A method where one party (the prover, such as a blockchain client) proves a proposition (such as the plaintext corresponding to the ciphertext of a transaction amount being non-negative) to another party (such as a smart contract). The characteristic is that no information is revealed during the process except for the fact that "the proposition is true". This article uses the notation `proof` to represent zero-knowledge proof, and the notation `proof(X, Y)` specifically refers to a zero-knowledge proof of the balance X and the transaction amount Y. The notation `prove(X, Y)` represents the generation process of a zero-knowledge proof. 6) Contract: In this article, "contract" refers to blockchain smart contracts, not commercial contracts. 7) Token contract: A smart contract deployed on a blockchain by a company, organization, or individual. This smart contract allows the issuer to issue (mint) or burn (burn) tokens to various users, and users can transfer tokens between each other. 8) Privacy token contract: A special type of token contract that provides encrypted protection for user balances and transaction amounts. HK 30135246 A 4 9) Concurrent In / Out Transfer Guarantee Mechanism for Privacy Token Contracts: A mechanism within the privacy token contract allows the same blockchain account to simultaneously receive transfer transactions and initiate transfer operations within the contract. Specifically,This mechanism ensures that even if the account's historical balance has been used to generate transfer transactions (including zero-knowledge proofs) that have not yet been confirmed by the blockchain, these zero-knowledge proofs remain valid for a certain period of time. The contract is designed to support the verification of zero-knowledge proofs generated based on the old state after the account state is updated (e.g., the balance increases), thus enabling simultaneous inflow and outflow operations. 10) Transfer: In the token contract, user A transfers assets to user B. Let the transfer amount be X, denoted as Transfer[A, B, X]. When the operation is successful, user A's balance decreases by X, and user B's balance increases by X. In the privacy token contract discussed in this paper, since the transaction amount is homomorphically encrypted, and user A needs to provide a zero-knowledge proof (proof) when initiating the transfer, this paper adjusts the notation of the transfer operation to Transfer[A, B, Enc(X), proof] to represent a transfer operation. 11) Blockchain Transaction Receipt: Contains a success or failure identifier for a blockchain transaction's world state change. 12) Transaction Hash: An identifier for a transaction. Users can use it to query detailed transaction information in the blockchain explorer, including transaction status (e.g., whether it was successfully confirmed), block number, initiator address, recipient address, transaction amount, transaction fee, and transaction receipt. The transaction hash is generated based on the specific data of the transaction and the blockchain algorithm, possessing uniqueness and immutability, ensuring the transparency and trustworthiness of the transaction. 13) Latest Privacy Balance Query: Accesses the latest packaged block of the blockchain to query the privacy-protected balance of address A, obtaining the ciphertext of the balance b after homomorphic encryption using A's public key pk. The operation is denoted as BalanceOf(A), and the query result is Enc(pk, b). 14) Lock: A concurrency control mechanism primarily used to manage access to shared resources to ensure resource consistency and integrity. Lock mechanisms typically control thread access permissions to resources through locking and unlocking operations. Off-chain application systems (or off-chain systems for short) use exclusive locks for concurrency control. The locking unit (or locking object) is a resource A that is subject to competition, denoted by Lock(A). Correspondingly, the thread holding the lock can release it, denoted by Unlock(A). When thread 1 holds lock Lock(A), thread 2's Lock(A) operation will be blocked until its Unlock(A) operation is completed, ensuring that only one thread operates on resource A at any given time. 15) Blockchain address lock: a type of lock.A locking unit is a specific blockchain address. The above explains the main terms. Next, we introduce the inventive concept of the transaction concurrency scheme proposed by the applicant. As mentioned earlier, an optimization scheme is needed, HK 30135246 A 5, which can increase the upper limit of concurrent execution and improve the throughput of the blockchain system while handling partially ordered dependent transactions. Specifically, partially ordered dependent transactions refer to transactions that have a causal dependency relationship and must be executed in a specific order. This dependency limits the processing capacity of concurrent transactions, especially in the application of privacy token contracts. Privacy token contracts can provide encrypted protection for user balances and transaction amounts, and are therefore widely used in various scenarios. However, their performance bottlenecks become apparent when handling a large number of concurrent transactions from the same account. To overcome this limitation, the industry has proposed a mechanism to ensure concurrent inflows and outflows from the same account. By adopting this mechanism, the privacy token contract itself already has the ability to support concurrent inflows and outflows from the same account, making it theoretically possible for multiple concurrent privacy token transactions from the same account to be packaged into the same block. However, in practical applications, off-chain systems need to employ locking mechanisms and strictly control the granularity of these mechanisms when submitting privacy token transactions to ensure the success rate of on-chain transactions. The primary target of locks is the resource state of a blockchain account, such as updates to account balances, writing transaction records, or other state changes. The purpose of locks is to prevent concurrent transactions from simultaneously modifying the resources of the same account, leading to data conflicts or inconsistencies. The granularity of the locking mechanism refers to the fineness of the scope of resource locking, such as whether to lock a single transaction, specific account resources, or the entire account. Currently, a common practice is to use a large lock granularity, locking account resources from the moment a transaction is submitted and continuing to lock them until the transaction is packaged into a block and a transaction receipt is successfully obtained. This long-term locking strategy ensures the security of transaction execution and the consistency of on-chain data, but it also significantly limits the system's concurrency capabilities. Due to the excessively large lock granularity, the transaction concurrency limit for the same account is limited to "one transaction per block," resulting in low throughput per block for privacy tokens within the same account, making it difficult to support scenarios where a large number of transactions from the same account are submitted simultaneously. Based on the above observations and analysis, this specification discloses a transaction concurrency scheme for privacy token contracts, which allows the off-chain system to further reduce the locking granularity when submitting transfer transactions that call privacy token contracts, breaking through the concurrency limit of "one transaction per block" and improving system throughput. The following section introduces the traditional transaction generation and submission scheme as the basis for the improvement, to help understand the improvements of the improved transaction concurrency scheme. Figure 1 shows the flow steps of a traditional transaction generation and submission scheme disclosed in this specification. It should be noted that, uniformly, all steps shown in the accompanying figures are executed by the off-chain system. As shown in Figure 1, the traditional scheme includes the following steps: Step S11,The Lock(A) method is executed to apply a lock. Specifically, based on the user's request to transfer privacy tokens, the resources of the user's blockchain account (or blockchain address) are locked for the first time. It should be noted that the terms "first" in "first lock," "second," "third," and similar terms used elsewhere in the text are for distinguishing similar items and do not have any ordering or other limiting effect. The transfer request mentioned above may include the initiator's address (denoted as blockchain address A), the recipient's address (denoted as blockchain address B), and the plaintext transaction amount Y (or transaction amount Y). Furthermore, blockchain address A, blockchain account A, and user account A can be used interchangeably as needed. Regarding the resources of the blockchain account, in one example, it could be the blockchain account itself; in another example, it could be the blockchain account balance; in yet another example, the transfer request may also include the currency corresponding to the transaction amount, in which case the account resources could be the blockchain account balance under that currency. It should be understood that locking is the behavior of implementing a locking mechanism. By locking blockchain address A, other threads cannot modify the resource simultaneously. Therefore, blockchain address A is locked by a specific thread. Step S12: Execute BalanceOf(A) to obtain the ciphertext Enc(X) of the on-chain balance of blockchain address A. Step S13: Execute Dec[Enc(X)] to obtain the plaintext X of the on-chain balance of blockchain address A. Specifically, Enc(X) can be decrypted using the private key corresponding to blockchain address A to obtain the plaintext balance X. Step S14: Execute Enc(Y) to obtain the ciphertext Enc(Y) of the transaction amount Y. Specifically, the encryption key used to encrypt the transaction amount Y in this step can be a multi-party public key, where the multi-party includes the initiator, recipient, and issuer of the privacy token. For example, the multi-party can also include the auditor (or regulator) performing the audit. Step S15: Execute `prove(X, Y)` to obtain a zero-knowledge proof `proof(X, Y)` regarding the plaintext account balance X and the transaction amount Y. It should be noted that `proof(X, Y)` may include one or more zero-knowledge proof data. In one embodiment, it includes first zero-knowledge proof data, which proves that the transaction amount Y corresponding to the ciphertext Enc(Y) is non-negative. In another embodiment, it includes second zero-knowledge proof data, which proves that the ciphertext Enc(Y) can be decrypted by multiple relevant parties to obtain the same original transaction amount Y. In yet another embodiment, it includes third zero-knowledge proof data, which proves that the plaintext (XY) corresponding to the ciphertext blockchain address A's balance ciphertext Enc(XY) after completing this transfer is non-negative. Additionally,The specific execution method of this step can be implemented using existing technology and will not be elaborated further. Step S16: Submit the transaction Transfer[A, B, Enc(Y), proof] to the privacy token contract deployed in the blockchain. It should be understood that this step can also be described as: submitting a transfer transaction that calls the privacy token contract to the blockchain. In addition, after submitting the transfer transaction to the privacy token contract, the transaction information will be packaged and broadcast to network nodes, generating the corresponding transaction hash. Step S17: Wait synchronously or asynchronously until a blockchain transaction receipt is obtained. In one embodiment, the transaction receipt can be obtained based on an active query mechanism, for example, using the transaction hash corresponding to HK 30135246 A 7 to query (e.g., poll) the blockchain to obtain the transaction receipt. In another embodiment, the transaction receipt can be obtained based on an event-driven mechanism, for example, after user A submits a transaction, the off-chain system will subscribe to the transaction completion event for a specific address A. Once the transaction is confirmed on-chain, the on-chain will automatically notify the off-chain system, along with the transaction receipt information. Step S18: Execute Unlock(A) to release the lock. It is understandable that after executing Unlock(A) to release the lock, the locked state of blockchain account A is released. The above, combined with Figure 1, introduces the traditional generation and submission scheme for privacy token transfer transactions (or simply privacy transactions, transfer transactions). It should be understood that the subsequent steps of determining the success or failure of the transaction based on the transaction receipt and completing the corresponding business logic are omitted. When multiple transfer transactions are initiated from the same blockchain address A, due to the existence of the account lock Lock(A), these transfer transactions must be processed sequentially, resulting in each block containing at most one transfer transaction initiated by account A, significantly wasting the remaining block capacity. Furthermore, the blockchain struggles to achieve high throughput for privacy transactions from the same account. Based on the above traditional scheme, the applicant proposes a transaction concurrency scheme, specifically including an off-chain storage module for the world state, and a pre-computation and failure compensation scheme design. This allows the generation process of privacy transactions to be independent of the real-time world state on the chain, and the lock release time can be advanced. Once a privacy transaction is submitted to the blockchain, it can proceed to process the next privacy transaction from the same account without waiting for a block to be generated. This allows multiple privacy transactions from the same account to be processed by the blockchain simultaneously and packaged into the same block. The following section details the transaction concurrency solution. I. Off-chain Storage Module for World State The off-chain storage module for world state refers to the process where, when generating a transfer transaction, the program does not directly retrieve the user's encrypted balance from the blockchain smart contract, but instead reads it from an off-chain storage module. It's important to understand that any system capable of data storage can act as an off-chain storage module, such as an off-chain cache (e.g., a distributed cache) or a database system.And so on. The operation `ReadSnapshot(A)` is defined to retrieve a snapshot of the previously written ciphertext balance of account A from the off-chain storage module. The operation returns the most recently stored snapshot of A's ciphertext balance, `Enc(b)`, in the off-chain storage module, along with the write time `t`. If there is no data in the cache, it returns "empty". The operation `WriteSnapshot(A, t, Enc(b))` is defined to write a snapshot of A's ciphertext balance, `Enc(b)`, at time `t`. The operation `ClearSnapshot(A, t)` is defined to clear all ciphertext snapshots of A's balance balance at and after time `t`. The operation `TimeOfClearSnapshot(A)` is defined to read the time when the last `ClearSnapshot` operation was performed on address A. Compared to the traditional scheme described above, which queries the encrypted balance from the blockchain in real time, this scheme transforms all encrypted balance queries into reading from the off-chain storage module via a ReadSnapshot operation. If the operation returns "empty", BalanceOf(A) is executed, and the result is written to the cache via a WriteSnapshot operation. This operation is not described in detail in this scheme. After applying the off-chain storage module for the world state based on the traditional scheme described above, the generation and submission of the Transfer transaction can be described as the following steps shown in Figure 2: Step S21, execute Lock(A) to apply a lock. Step S22, execute ReadSnapshot(A) to obtain the encrypted balance Enc(X) of the local cache of blockchain address A. Step S23, execute Dec[Enc(X)] to obtain the plaintext X of the local cache of address A. Step S24, execute Enc(Y) to obtain the encrypted balance Enc(Y) of the transaction balance Y. Step S25: Execute prove(X, Y) to obtain a zero-knowledge proof proof(X, Y) regarding the account balance X and transaction amount Y. Step S26: Submit the transaction Transfer[A, B, Enc(Y), proof] to the privacy token contract. Step S27: Execute Unlock(A) to release the lock. Step S28: Wait synchronously or asynchronously until a blockchain transaction receipt is obtained. Comparing the steps shown in Figure 2 with the steps of the traditional scheme in Figure 1, the main differences are: 1) In step S12 shown in Figure 1, the balance ciphertext Enc(X) is queried from the chain in real time by executing BalanceOf(A), while in step S22 shown in Figure 2, the balance ciphertext Enc(X) is queried by executing ReadSnapshot(A).Obtain the locally cached balance ciphertext Enc(X). 2) In steps S17 and S18 shown in Figure 1, the blockchain transaction receipt is obtained first, and then Unlock(A) is executed to release the lock. In steps S27 and S28 shown in Figure 2, Unlock(A) is executed first to release the lock, and then the blockchain transaction receipt is obtained. Thus, compared with the traditional scheme shown in Figure 1, the Unlock(A) operation in Figure 2 can be completed in advance before the transaction is packaged into a block. The above describes the application of the off-chain storage module of the world state in the traditional scheme. II. Pre-computation Pre-computation refers to the fact that after the transfer transaction is generated and submitted to the blockchain, the system program adopts the heuristic assumption that "this transfer operation will be successful on the chain" by default, and directly uses the encrypted balance after the operation to update the off-chain storage module of the world state, so that subsequent transfer transactions can be directly calculated offline based on the world state after the end of this transfer. Based on Figure 2, after applying the pre-computation scheme, the steps for generating and submitting a transfer transaction can be described as shown in Figure 3 as follows: HK 30135246 A 9 Step S31: Execute Lock(A) to apply a lock. Step S32: Execute ReadSnapshot(A) to obtain the ciphertext Enc(X) of the local cache balance of blockchain address A. Step S33: Execute Dec[Enc(Y)] to obtain the plaintext X of the local cache balance of blockchain address A. Step S34: Execute Enc(Y) to obtain the ciphertext Enc(Y) of the transaction balance Y. Step S35: Execute prove(X, Y) to obtain the zero-knowledge proof proof(X, Y) of the account balance X and transaction amount Y. Step S36: Submit the transaction Transfer[A, B, Enc(Y), proof] to the privacy token contract and record the current time t. Step S37: Execute WriteSnapshot(A, t, Enc(XY)) to write a snapshot of the balance ciphertext Enc(XY) of blockchain address A. This snapshot includes blockchain address A, the transaction submission time t, and the updated balance ciphertext Enc(XY) assuming the transaction was successful. Step S38: Execute Unlock(A) to release the lock. Step S39: Wait synchronously or asynchronously until a blockchain transaction receipt is obtained. Compared to the steps shown in Figure 2, the steps shown in Figure 3 include an update step for the off-chain storage module of the world state and a record of the submission time before executing Unlock(A), for use in subsequent transaction generation. For example, between steps S38 and S39...The off-chain system can also submit another privacy transaction initiated by user A to the blockchain. This privacy transaction and the same-account privacy transaction submitted in step S36 can then be packaged into the same block. It should be noted that the Lock(B) operation is not required in Figure 3, nor is it necessary to write a ciphertext snapshot of the balance of address B. This is because B is the recipient, and due to the concurrent transfer guarantee mechanism of the privacy token contract, it will not affect the transfer in or out transaction of address B. The above description applies pre-computation in the method steps shown in Figure 2. III. Failure Compensation Failure compensation refers to the compensation mechanism that rolls back the off-chain storage module when the off-chain system synchronously or asynchronously receives a transaction receipt belonging to a submitted transfer transaction and, through parsing, finds that the transfer operation failed. Failure compensation is a new addition to the compensation logic and does not require modification of the original process in Figure 3. The new compensation logic can be implemented as shown in the following steps in Figure 4: Step S41, if the transaction receipt indicates "transfer successful," then the procedure ends. Step S42: Execute Lock(A) to apply the lock. Step S43: Read the submission time t_submit of the blockchain transaction corresponding to the previously recorded current transaction receipt. Step S44: Execute TimeOfClearSnapshot(A) to obtain the last cache clear time t_clear. Step S45: If t_clear > t_submit, execute Unlock(A) to release the lock and end the program. Step S46: If t_clear ≤ t_submit, execute ClearSnapshot(A, t_submit) to clear all ciphertext snapshots of the balance of A at time t_submit and later (including time t). Step S47: Execute BalanceOf(A) to obtain the on-chain balance ciphertext Enc(X) of blockchain address A. Step S48: Execute WriteSnapshot(A, t, Enc(X)), writing a ciphertext snapshot of A's balance, Enc(X), to the off-chain storage module at the current time t. Step S49: Execute Unlock(A) to release the lock. The failure compensation mechanism described above can be executed after the method steps shown in Figure 2 or Figure 3. Regarding the transaction concurrency scheme described above, it should be noted that the lock used in the transaction concurrency scheme is not limited to an exclusive lock based on a distributed cache. The specific lock implementation depends on the deployment mode of the off-chain system. In single-machine mode, it can be a thread-level reentrant lock; in cluster mode, it can be a distributed pessimistic lock.This can be implemented using databases or other distributed storage solutions. The following analysis examines the beneficial effects of the transaction concurrency solution compared to traditional solutions. Assume: the block time of the blockchain is p, and the total time for off-chain operations excluding locking is q. In the original solution, after locking, the lock must be released only after synchronously waiting for a block to be generated (until a transaction receipt can be obtained from the blockchain based on the transaction hash). Therefore, the lock duration in the original solution is necessarily greater than p + q. Multiple transfer transactions initiated by the same account need to be processed sequentially using the original solution, so at most one transaction is packaged in each block. In the transaction concurrency solution (i.e., the improved solution), all operations after locking do not need to synchronously wait for a block to be generated. Therefore, the lock duration in the improved solution is only greater than q. Multiple Transfer transactions initiated by the same account still need to be processed sequentially by the transaction concurrency solution, but compared to the block time, off-chain operations are usually faster (q << p). Therefore, under ideal conditions, the improved scheme can generate floor(p / q) transactions and submit them to the chain within each block cycle, thus packaging at most floor(p / q) transactions in each block. Here, floor represents the rounding operation. As can be seen, compared to the original scheme, the improved scheme allows for further reduction in the granularity of locking in the off-chain system, increasing the concurrency limit for privacy transactions within the same account from 1 to floor(p / q), thereby improving the overall throughput of the system. In summary, the transaction concurrency scheme disclosed in the embodiments of this specification, by analyzing the partial order dependency relationship of the world state, proposes an off-chain storage module for the world state and a pre-computation and failure compensation scheme design, enabling the generation process of privacy transactions to be independent of the real-time world state on the chain, and allowing the lock release time to be advanced. After a privacy transaction is submitted to the chain, it can continue to process the next privacy transaction within the same account without waiting for its block to be produced, allowing multiple privacy transactions within the same account to be processed by the blockchain simultaneously and packaged into the same block, breaking the concurrency limit of 1 transaction / block. HK 30135246 A 11 The improved off-chain system can further narrow the locking scope and improve system throughput. The above description of the transaction concurrency solution mainly introduces the submission method for blockchain transfer transactions. This solution also provides a corresponding submission device. See Figure 5, which shows that the submission device 500 includes the following functional modules: a first locking module 501, configured to lock the resources of the user's blockchain account based on a user-initiated transfer request for privacy tokens; a local query module 502, configured to query the encrypted balance of the blockchain account from an off-chain storage module storing the blockchain world state; a transaction submission module 503, configured to submit a transfer transaction invoking the privacy token contract to the blockchain based on the plaintext transaction amount in the transfer request and the encrypted balance; and a first unlocking module 504.The system is configured to: unlock the first lock; a snapshot writing module 505, configured to write an updated balance ciphertext into the off-chain storage module based on the assumption of successful execution of the transfer transaction; a receipt acquisition module 506, configured to acquire a transaction receipt for the transfer transaction; and a judgment processing module 507, configured to end the current process if the transaction receipt indicates that the transaction was successfully executed. In some embodiments, the snapshot writing module 505 is specifically configured to: write a first balance ciphertext snapshot into the off-chain storage module, which includes the updated balance ciphertext, the submission time of the transfer transaction, and the blockchain account. The submission device 500 further includes: a second locking module 508, configured to perform a second lock on the resource if the transaction receipt indicates that the transaction failed; a clearing time reading module 509, configured to read the last clearing time for cache clearing of the blockchain account from the off-chain storage module; and a second lock release module 510, configured to release the second lock if it is determined that the submission time is before the last clearing time. Furthermore, in a specific embodiment, the submission device 500 further includes: a snapshot clearing module 511, configured to clear the encrypted balance snapshots of the blockchain account at and after the submission time in the off-chain storage module when it is determined that the submission time is not before the last clearing time; an on-chain query module 512, configured to obtain the real-time encrypted balance of the blockchain account from the blockchain and write the corresponding second encrypted balance snapshot into the off-chain storage module; and a second lock release module, configured to release the second lock. In one embodiment, the submission device is integrated into an off-chain system. The off-chain system is deployed in a single-machine mode, and the first lock is implemented based on a thread-level reentrant lock; or, the off-chain system is deployed in a cluster mode, and the first lock is implemented based on a distributed pessimistic lock; or, the first lock is completed through an exclusive lock implemented by a distributed cache in the off-chain system. In one embodiment, the transaction submission module 503 is specifically configured to: encrypt the plaintext of the transaction amount to obtain ciphertext of the transaction amount; decrypt the ciphertext of the balance to obtain plaintext of the balance; generate zero-knowledge proof data, which is used to prove that the plaintext of the transaction amount corresponding to the ciphertext of the transaction amount is non-negative and does not exceed the plaintext of the balance corresponding to the ciphertext of the balance; generate a first transfer transaction based on the ciphertext of the transaction amount and the zero-knowledge proof data, HK 30135246 A 12, and submit it to the blockchain. It should be understood that, for ease of description, the above apparatus is described by functionally as various modules. Of course, in implementing this specification, the functions of each module can be implemented in one or more software and / or hardware. This specification also provides a computer-readable non-transitory storage medium.The storage medium stores a computer program that, when executed by a processor, can be used to perform one or more steps of one or more methods described or illustrated herein, or to provide the functionality described or illustrated herein. Here, one or more computer-readable non-transitory storage media may include one or more semiconductor-based or other integrated circuits (ICs) (e.g., field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs)), hard disk drives (HDDs), hybrid hard disk drives (HHDs), optical disks, optical disk drives (ODDs), magneto-optical disks, magneto-optical disk drives, floppy disks, floppy disk drives (FDDs), magnetic tape, solid-state drives (SSDs), RAM drives, secure digital cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. The computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. This specification also provides a computer system. Figure 6 illustrates an exemplary computer system 600. In a particular embodiment, one or more computer systems 600 perform one or more steps of one or more methods described or illustrated herein. In a particular embodiment, one or more computer systems 600 provide the functionality described or illustrated herein. In a particular embodiment, software running on one or more computer systems 600 performs one or more steps of one or more methods described or illustrated herein, or provides the functionality described or illustrated herein. The particular embodiment includes one or more portions of one or more computer systems 600. Herein, references to computer systems may include computing devices and vice versa, where appropriate. Furthermore, references to computer systems may include one or more computer systems, where appropriate. This disclosure contemplates any suitable number of computer systems 600. This disclosure envisions computer systems 600 taking any suitable physical form. By way of example and not limitation, computer system 600 may be an embedded computer system, a system-on-a-chip (SOC), a single-board computer system (SBC) (e.g., a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a computer system network, a mobile phone, a personal digital assistant (PDA), a server, a tablet computer system, or a combination of two or more of these. Where appropriate, computer system 600 may include one or more computer systems 600; single or distributed; spanning multiple locations; spanning multiple machines; spanning multiple data centers; or residing in the cloud, which may include one or more cloud components in one or more networks. Where appropriate,One or more computer systems 600 may perform one or more steps of one or more methods described or illustrated herein without material space or time limitations. HK 30135246 A 13 By way of example and not limitation, one or more computer systems 600 may perform one or more steps of one or more methods described or illustrated herein in real time or in batch mode. Where appropriate, one or more computer systems 600 may perform one or more steps of one or more methods described or illustrated herein at different times or in different locations. In a particular embodiment, computer system 600 includes processor 602, memory 604, storage 606, input / output (I / O) interface 608, communication interface 610, and bus 612. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement. In a particular embodiment, processor 602 includes hardware for executing instructions, such as instructions constituting a computer program. By way of example and not limitation, in order to execute instructions, processor 602 may retrieve (or fetch) instructions from internal registers, internal caches, memory 604, or memory 606; decode and execute them; and then write one or more results to internal registers, internal caches, memory 604, or memory 606. In certain embodiments, processor 602 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates that processor 602 may include any appropriate number of appropriate internal caches where appropriate. By way of example and not limitation, processor 602 may include one or more instruction caches, one or more data caches, and one or more translation back-of-care buffers (TLBs). Instructions in the instruction cache may be copies of instructions in memory 604 or memory 606, and the instruction cache may accelerate the retrieval of those instructions by processor 602. The data in the data cache may be a copy of the data in memory 604 or memory 606 for instruction operations executed at processor 602; the result of a previous instruction executed at processor 602 for subsequent instructions executed at processor 602 to access or write to memory 604 or memory 606; or other suitable data. The data cache can accelerate read or write operations of processor 602. The TLB can accelerate virtual address translation of processor 602. In a particular embodiment,Processor 602 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates that processor 602 may include any suitable number of suitable internal registers where appropriate. Where appropriate, processor 602 may include one or more arithmetic logic units (ALUs), may be a multi-core processor, or may include one or more processors 602. Although this disclosure describes and illustrates specific processors, this disclosure contemplates any suitable processor. In a particular embodiment, memory 604 includes main memory for storing instructions to be executed by processor 602 or data to be operated on by processor 602. By way of example and not limitation, computer system 600 may load instructions from memory 606 or another source (e.g., another computer system 600) into memory 604. Processor 602 may then load instructions from memory 604 into internal registers or internal caches. To execute instructions, processor 602 may retrieve instructions from internal registers or internal caches and decode them. During or after instruction execution, processor 602 may write one or more results (which may be intermediate or final results) to internal registers or internal caches. Processor 602 may then write one or more of these results to memory 604. In a particular embodiment, processor 602 executes only the instructions in one or more internal registers or internal caches or memory 604 (as opposed to memory 606 or elsewhere) and operates only on the data in one or more internal registers or internal caches or memory 604 (as opposed to memory 606 or elsewhere). One or more memory buses (each memory bus may include an address bus and a data bus) couple processor 602 to memory 604. As described below, bus 612 may include one or more memory buses. In a particular embodiment, one or more memory management units (MMUs) reside between processor 602 and memory 604 and facilitate access to memory 604 requested by processor 602. In a particular embodiment, memory 604 includes random access memory (RAM). Where appropriate, the RAM may be volatile memory. Where appropriate, the RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Furthermore, where appropriate, the RAM may be single-port or multi-port RAM. This disclosure contemplates any suitable RAM. Where appropriate, memory 604 may include one or more memories 604. Although this disclosure describes and illustrates specific memories,However, this disclosure contemplates any suitable memory. In a particular embodiment, memory 606 includes a large-capacity memory for data or instructions. By way of example and not limitation, memory 606 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 606 may include removable or non-removable (or fixed) media. Where appropriate, memory 606 may be internal or external to computer system 600. In a particular embodiment, memory 606 is a non-volatile solid-state memory. In a particular embodiment, memory 606 includes read-only memory (ROM). Where appropriate, the ROM may be a mask-programmable ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically changeable ROM (EAROM), or flash memory, or a combination of two or more of these. This disclosure contemplates a large-capacity memory 606 in any suitable physical form. Where appropriate, storage 606 may include one or more storage control units that facilitate communication between processor 602 and storage 606. Where appropriate, storage 606 may include one or more storage units 606. Although this disclosure describes and illustrates specific storage, this disclosure contemplates any suitable storage. In a particular embodiment, I / O interface 608 includes hardware, software, or both, providing one or more interfaces for communication between computer system 600 and one or more I / O devices. Where appropriate, computer system 600 may include one or more of these I / O devices. One or more of these I / O devices can enable communication between a person and computer system 600. By way of example and not limitation, I / O devices may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, graphics tablet, touchscreen, trackball, camera, other suitable I / O devices, or combinations of two or more of these devices. I / O devices may include one or more sensors. This disclosure contemplates any suitable I / O devices and any suitable I / O interface 608 for them. Where appropriate, I / O interface 608 may include one or more devices or software drivers that enable processor 602 to drive one or more of these I / O devices. Where appropriate, I / O interface 608 may include one or more I / O interfaces 608. Although this disclosure describes and illustrates specific I / O interfaces,However, this disclosure contemplates any suitable I / O interface. In a particular embodiment, communication interface 610 includes hardware, software, or both, providing one or more interfaces for communication (e.g., packet-based communication) between computer system 600 and one or more other computer systems 600 or one or more networks. By way of example and not limitation, communication interface 610 may include a network interface controller (NIC) or network adapter for communicating with Ethernet or other wired networks, or a wireless NIC (WNIC) or wireless adapter for communicating with wireless networks such as Wi-Fi networks. This disclosure contemplates any suitable network and any suitable communication interface 610 for that network. By way of example and not limitation, computer system 600 may communicate with one or more portions of an ad hoc network, personal area network (PAN), local area network (LAN), wide area network (WAN), metropolitan area network (MAN), or the Internet, or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 600 may communicate with a wireless PAN (WPAN) (e.g., Bluetooth WPAN), a Wi-Fi network, a Wi-Fi Max network, a cellular telephone network (e.g., a Global System for Mobile Communications (GSM) network), or other suitable wireless networks, or a combination of two or more of these networks. Where appropriate, computer system 600 may include any suitable communication interface 610 for any of these networks. Where appropriate, communication interface 610 may include one or more communication interfaces 610. Although specific communication interfaces are described and illustrated in this disclosure, any suitable communication interface is contemplated in this disclosure. In a particular embodiment, bus 612 includes hardware, software, or both, that couples components of computer system 600 to each other. By way of example and not limitation, bus 612 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), an HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a Serial Advanced Technology Accessory (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or another suitable bus, or a combination of two or more of these buses. Where appropriate, bus 612 may include one or more buses 612. Although this disclosure describes and illustrates specific buses, this disclosure contemplates any suitable bus or interconnect. Those skilled in the art will appreciate that...In one or more of the above examples, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this invention. It should be understood that the above descriptions are merely specific embodiments of this invention and are not intended to limit the scope of protection of this invention. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this invention should be included within the scope of protection of this invention. HK 30135246 A 1 Claim 1. A method for submitting a blockchain transfer transaction, comprising: First locking the resources of the user's blockchain account based on a transfer request for a privacy token initiated by the user, and retrieving the encrypted balance of the blockchain account from an off-chain storage module storing the state of the blockchain world; Submitting a transfer transaction invoking a privacy token contract to the blockchain based on the plaintext transaction amount in the transfer request and the encrypted balance, and releasing the first lock; Writing the updated encrypted balance to the off-chain storage module based on the assumption of successful execution of the transfer transaction; Obtaining a transaction receipt for the transfer transaction, and ending the current process if the receipt indicates successful transaction execution. 2. The method according to claim 1, wherein writing the updated balance ciphertext into the off-chain storage module comprises: writing a first balance ciphertext snapshot into the off-chain storage module, which includes the updated balance ciphertext, the submission time of the transfer transaction, and the blockchain account; wherein, after obtaining a transaction receipt for the transfer transaction, the method further comprises: if the transaction receipt indicates that the transaction execution failed, performing a second lock on the resource, and reading the last clearing time for cache clearing of the blockchain account from the off-chain storage module; and releasing the second lock if it is determined that the submission time is before the last clearing time. 3. The method according to claim 2, further comprising: if it is determined that the submission time is not before the last clearing time, clearing the balance ciphertext snapshots of the blockchain account at and after the submission time in the off-chain storage module; obtaining the real-time balance ciphertext of the blockchain account from the blockchain, and writing the corresponding second balance ciphertext snapshot into the off-chain storage module; and releasing the second lock. 4. The method according to claim 1, wherein the method is executed by an off-chain system; wherein the off-chain system is deployed in a single-machine mode, and the first lock is implemented based on a thread-level reentrant lock; or, the off-chain system is deployed in a cluster mode.The first lock is implemented based on a distributed pessimistic lock; or, the first lock is completed through an exclusive lock implemented by a distributed cache in the off-chain system. 5. The method according to claim 1, wherein submitting a transfer transaction invoking a privacy token contract to the blockchain based on the plaintext of the transaction amount in the transfer request and the ciphertext of the balance includes: encrypting the plaintext of the transaction amount to obtain the ciphertext of the transaction amount; decrypting the ciphertext of the balance to obtain the plaintext of the balance; generating zero-knowledge proof data, which is used to prove that the plaintext of the transaction amount corresponding to the ciphertext of the transaction amount is non-negative and does not exceed the plaintext of the balance corresponding to the ciphertext of the balance; generating a first transfer transaction based on the ciphertext of the transaction amount and the zero-knowledge proof data, and submitting it to the blockchain. 6. A blockchain transfer transaction submission device, comprising: a first locking module configured to lock the resources of a user's blockchain account based on a user-initiated transfer request for a privacy token; a local query module configured to query the encrypted balance of the blockchain account from an off-chain storage module storing the state of the blockchain world; a transaction submission module configured to submit a transfer transaction invoking a privacy token contract to the blockchain based on the plaintext transaction amount in the transfer request and the encrypted balance; a first unlocking module configured to unlock the first locking; a snapshot writing module configured to write an updated encrypted balance into the off-chain storage module based on the assumption of successful execution of the transfer transaction; a receipt acquisition module configured to acquire a transaction receipt for the transfer transaction; and a judgment processing module configured to terminate the current process if the transaction receipt indicates that the transaction was successfully executed. HK 30135246 A 1 Instruction Manual Figure S11: Execute Lock(A) to apply a lock. S12: Execute BalanceOf(A) to obtain the ciphertext Enc(X) of the on-chain balance of blockchain address A. S13: Execute Dec[Enc(X)] to obtain the plaintext X of the on-chain balance of blockchain address A. S14: Execute Enc(Y) to obtain the ciphertext Enc(Y) of the transaction amount Y. S15: Execute prove(X, Y) to obtain the zero-knowledge proof proof(X, Y) of the plaintext X of the account balance and the transaction amount Y. S16: Submit the transaction Transfer[A, B, Enc(Y), proof] to the privacy token contract deployed in the blockchain. S17: Wait synchronously or asynchronously until the blockchain transaction receipt is obtained. S18: Execute Unlock(A) to release the lock. Figure 1 HK 30135246 A 2 S21: Execute Lock(A) to apply a lock. S22: Execute ReadSnapshot(A).S23: Execute Dec[Enc(X)] to obtain the on-chain balance plaintext X of blockchain address A. S24: Execute Enc(Y) to obtain the transaction amount ciphertext Enc(Y) of transaction amount Y. S25: Execute prove(X, Y) to obtain the zero-knowledge proof proof(X, Y) of account balance plaintext X and transaction amount Y. S26: Submit the transaction Transfer[A, B, Enc(Y), proof] to the privacy token contract deployed in the blockchain. S28: Wait synchronously or asynchronously until the blockchain transaction receipt is obtained. S27: Execute Unlock(A) to release the lock. Figure 2 HK 30135246 A 3 S31: Execute Lock(A) to apply the lock. S32: Execute ReadSnapshot(A) to obtain the local cache balance ciphertext Enc(X) of blockchain address A. S33: Execute Dec[Enc(X)] to obtain the on-chain balance plaintext X of blockchain address A. S34: Execute Enc(Y) to obtain the ciphertext of the transaction amount Y, Enc(Y). S36: Submit the transaction Transfer[A, B, Enc(Y), proof] to the privacy token contract deployed in the blockchain, recording the current time t. S38: Execute Unlock(A) to release the lock. S37: Execute WriteSnapshot(A, t, Enc(XY)) to write the ciphertext snapshot of the balance of blockchain address A, Enc(XY). S35: Execute prove(X, Y) to obtain the zero-knowledge proof proof(X, Y) of the plaintext account balance X and the transaction amount Y. S39: Wait synchronously or asynchronously.Until the blockchain transaction receipt is obtained, Figure 3 HK 30135246 A 4 Does the transaction receipt indicate that the transfer was successfully executed? Yes No S42: Execute Lock(A) to apply the lock S43: Read t_submit S44: Read t_clear t_clear>t_submit Yes S46: Execute ClearSnapshot (A, t_submit) S47: Query the on-chain balance ciphertext Enc(X) S48: Execute WriteSnapshot (A,t,Enc(X)) S49: Execute Unlock(A) to release the lock Figure 4 HK 30135246 A 5 Local query module 502 Transaction submission module 503 Submission device 500 First unlock module 504 First lock module 501 Second lock module 508 Clear time reading module 509 Second lock release module 510 Judgment processing module 507 Snapshot writing module 505 Receipt acquisition module 506 Snapshot clearing module 511 On-chain query module 512 Figure 5 Computer System 600 Processor 602 I / O Interface 608 Memory 604 Storage 606 Communication Interface 610 Figure 6 HK 30135246 A

Images