Submission management method for blockchain transaction, computer system, and storage medium

Abstract

This specification provides a blockchain transaction submission management method, computer system, and storage medium. The method is executed by an off-chain target device. The method includes: determining target transaction data to be processed; the target transaction data corresponding to a target account in the blockchain; obtaining transaction count information corresponding to the target account from locally pre-stored data; determining the current transaction count value corresponding to the target account based on the transaction count information; and sending the target transaction to the blockchain based on the transaction count value and the target transaction data.

Description

PAR2612072HK Specification 1 Blockchain Transaction Submission Management Method, Computer System, and Storage Medium Technical Field This specification relates to the blockchain field through one or more embodiments, and particularly to a blockchain transaction submission management method, computer system, and storage medium. Background Technology Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain, data blocks are sequentially linked to form a chain-like data structure according to time order, and cryptographic methods are used to ensure that the data blocks are immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and application. In recent years, the rapid development of blockchain technology has led to the emergence of various businesses based on blockchain management. Summary of the Invention This specification provides a blockchain transaction submission management method, computer system, and storage medium. According to a first aspect, a method for submitting and managing blockchain transactions is provided, the method being executed by an off-chain target device; the method includes: determining target transaction data to be processed; the target transaction data corresponding to a target account in the blockchain; obtaining transaction count information corresponding to the target account from locally pre-stored data; determining a transaction count value corresponding to the current target account based on the transaction count information; and sending a target transaction to the blockchain based on the transaction count value and the target transaction data. According to a second aspect, a computer system is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, performs the following target operation at least once, achieving the following steps: determining target transaction data to be processed; the target transaction data corresponding to a target account in the blockchain; obtaining transaction count information corresponding to the target account from locally pre-stored data; determining a transaction count value corresponding to the current target account based on the transaction count information; and sending a target transaction to the blockchain based on the transaction count information and the target transaction data. According to a third aspect, a computer-readable storage medium is provided, the storage medium storing a computer program, which, when executed by a processor, implements the method described in any one of the first aspects. The technical solutions provided by the embodiments of this specification may include the following beneficial effects: The blockchain transaction submission management scheme provided by the embodiments of this specification, when a target account in the blockchain submits a transaction to the blockchain, firstly determines the target transaction data corresponding to the target account, obtains the transaction count information corresponding to the target account from the locally pre-stored data, and sends the target transaction to the blockchain based on the transaction count information and the target transaction data.This achieves unified management of transaction counts for different accounts (HK 30135838 A PAR2612072HK Specification 2), which not only improves transaction submission efficiency but also ensures a high success rate for transaction submission. It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this application. Brief Description of the Drawings: To more clearly illustrate the technical solutions of the embodiments of this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 is a schematic diagram of a blockchain system according to an exemplary embodiment of this specification. Figure 2A is a schematic diagram of a blockchain transaction submission management scenario according to an exemplary embodiment of this specification. Figure 2B is a schematic diagram of another blockchain transaction submission management scenario according to an exemplary embodiment of this specification. Figure 3 is a flowchart of a blockchain transaction submission management method according to an exemplary embodiment of this specification. Figure 4 is a schematic diagram of a computer system according to an exemplary embodiment of this specification. Detailed Description of Embodiments To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments in this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain, data blocks are sequentially linked to form a chain-like data structure according to time order, and cryptographic methods are used to ensure that the data blocks are immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and application. In recent years, the rapid development of blockchain technology has led to the emergence of various businesses based on blockchain management. In a blockchain, each account has an associated nonce as a transaction count value, which can be used to identify the number of transactions initiated by that account. Transactions initiated by an account need to carry the latest transaction count value. Transaction counts can be used to sequence transactions and prevent replay attacks. In related technologies, before an account submits a transaction to the blockchain, it pre-queries the transaction count corresponding to that account with the blockchain nodes so that the submitted transaction includes that count. However, due to data access latency, transaction submission efficiency is affected.Furthermore, due to data synchronization delays, the transaction count values ​​retrieved from different nodes of the blockchain (HK 30135838 A PAR2612072HK Specification 3) may be inconsistent, making it impossible to guarantee the success rate of transaction submission. This specification provides a blockchain transaction submission management scheme. When a target account submits a transaction to the blockchain, the target transaction data corresponding to the target account is first determined. The transaction count information corresponding to the target account is obtained from locally pre-stored data. Based on the transaction count information and the target transaction data, the target transaction is sent to the blockchain. This achieves unified management of transaction count values ​​for different accounts, improving transaction submission efficiency and ensuring a high success rate. Figure 1 is a schematic diagram of a blockchain system according to an exemplary embodiment. As shown in Figure 1, the blockchain system may include a blockchain 101, at least one user 102, and a transaction management platform 103. Both the user 102 and the transaction management platform 103 can establish a communication connection with the blockchain 101 through their respective devices. The blockchain 101 may contain, for example, eight nodes: node 1 to node 8. Each node can be implemented as any device, server, or equipment cluster with computing and processing capabilities. It is understood that although Figure 1 shows eight nodes in blockchain 101, this embodiment is not limited to this and may include other numbers of nodes. Each node in blockchain 101 can generate the same state in the blockchain by executing the same transaction, and each node stores the same state database. Blockchain 101 can provide various blockchain-based services to multiple users 102. For example, the services provided by blockchain 101 may include, but are not limited to, notarization services, digital asset management services, and supply chain management services. Each user 102 holds an account, and any user 102 can send transactions to the blockchain through its account to use the services provided by the blockchain. The database of blockchain 101 stores transaction data and state data corresponding to the accounts held by each user 102. Transaction management platform 103 is a platform capable of providing transaction management services to one or more users 102. Transaction management platform 103 can manage transaction submissions for different accounts. Any user 102 can send transaction data used to generate a transaction to the transaction management platform 103. The transaction management platform 103 then generates a corresponding transaction for that account based on the transaction data and submits the transaction to the blockchain 101. The transaction management platform 103 can also store and manage the transaction execution results returned by the blockchain 101 for user 102 to view. The transaction management platform is described in detail below with reference to Figures 2A and 2B. Figure 2A is a schematic diagram illustrating a blockchain transaction submission management scenario according to an exemplary embodiment.As shown in Figure 2A, the transaction management platform may include a transaction receiving module, a transaction submission module, a transaction management module, a lock management module, a transaction compensation module, and a transaction count verification module. The transaction receiving module receives pending transaction data from multiple accounts; the lock management module manages the concurrent locks of each account; the transaction submission module submits transactions to the blockchain based on the transaction data sent by the account; the transaction management module manages the transaction data and transaction counts submitted by each account to the blockchain; the transaction compensation module resubmits previously submitted but unaccepted transactions to the blockchain; and the transaction count verification module verifies whether the transaction count managed by the transaction management module matches the on-chain transaction count. For example, taking user data storage on the blockchain as an example, a specific application scenario could be: First, the user sends transaction data D to the transaction management platform through their account. Transaction data D may include the data to be stored, account information, and the contract address used for storage. The transaction receiving module in the transaction management platform receives transaction data D and locates the first data table corresponding to the account based on transaction data D. This first data table records multiple transaction data submitted by the account sequentially. The transaction receiving module stores transaction data D in the order of submission. The transaction submitting module retrieves transaction data from the first data table corresponding to the account, in the order of submission. After retrieving transaction data D, the transaction submitting module requests a concurrent lock corresponding to the account from the lock management module. If the concurrent lock is not yet released, the transaction submitting module can continue to wait. After a preset period, it can re-request the concurrent lock corresponding to the account from the lock management module for transaction data D. If the concurrent lock has been released, the transaction submitting module successfully acquires the concurrent lock. After acquiring the concurrent lock, the transaction submitting module obtains the transaction count value corresponding to the account from the transaction management module, generates a transaction TX for evidence storage based on transaction data D and the transaction count value, and sends the transaction TX to the blockchain. Simultaneously, the transaction submission module can store the relevant data of transaction TX in a second data table managed by the transaction management module, and instruct the transaction management module to update the transaction count value corresponding to the account recorded in the second data table. The second data table also records the acceptance status information of each of the multiple transactions submitted by the account to the blockchain. After storing the relevant data of transaction TX in the second data table, the acceptance status information corresponding to transaction TX can be recorded as the initial state.After a blockchain transaction TX is successfully or unsuccessfully accepted, its acceptance status can be returned to the transaction submission module. The transaction submission module then instructs the transaction management module to update the acceptance status of the corresponding transaction TX and release the concurrent lock corresponding to the account to the lock management module. The transaction compensation module can scan the acceptance status of each transaction in the second data table at preset intervals. If the transaction TX is in its initial state, the transaction compensation module can resubmit it to the blockchain until it receives the acceptance status information for the transaction TX from the blockchain. At this point, the transaction compensation module can release the concurrent lock corresponding to the account to the lock management module. Additionally, at regular intervals, the transaction count verification module can query the latest first transaction count value of the account from the blockchain and simultaneously obtain the second transaction count value recorded in the second data table for that account from the transaction management module. The first and second transaction count values ​​are compared. If the difference between them is less than or equal to a preset value, the verification is considered successful. If the difference is greater than the preset value, the verification is considered unsuccessful, and further warning and alert operations can be performed. Figure 2B is a schematic diagram of another blockchain transaction submission management scenario according to an exemplary embodiment. As shown in Figure 2B, the transaction management platform can include a transaction receiving module, a transaction submission module, and a transaction management module. The transaction receiving module receives pending transaction data from multiple accounts. The transaction submission module submits transactions to the blockchain based on the transaction data sent by the accounts. The transaction management module manages the transaction data and transaction counts submitted by each account to the blockchain. For example, taking user data storage on the blockchain as an example, the specific application scenario is as follows: First, the user sends transaction data D to the transaction management platform through their account. Transaction data D may include the data to be stored, account information, and the contract address used for storage. The transaction receiving module in the transaction management platform receives transaction data D and finds the first data table corresponding to the account. This first data table records multiple transaction data submitted by the account sequentially. The transaction receiving module stores transaction data D in the first data table according to the order of transaction data submission. The transaction submission module retrieves transaction data from the first data table corresponding to the account, according to the order of transaction data submission. After the transaction submission module obtains the transaction data D, it can first determine whether a thread exists for allocating transaction count values. If no target thread exists for allocating transaction count values, a thread can be selected from multiple candidate threads as the target thread, and the target thread can then obtain the transaction count value corresponding to the account from the transaction management module.If a target thread exists for allocating transaction count values ​​and is in a waiting state, the transaction count value corresponding to the account can be directly obtained from the transaction management module through the target thread. If a target thread exists for allocating transaction count values ​​but is in a working state, the transaction count value corresponding to the account can be obtained from the transaction management module through the target thread after it completes its current task. Finally, the transaction submission module can generate a transaction TX for evidence storage based on the transaction data D and the transaction count value, and send the transaction TX to the blockchain. At the same time, the transaction submission module can store the relevant data of the transaction TX in a second data table managed by the transaction management module, and instruct the transaction management module to update the transaction count value corresponding to the account recorded in the second data table. The solution provided in this specification will be described in detail below with reference to specific embodiments. As shown in Figure 3, Figure 3 is a flowchart of a blockchain transaction submission management method according to an exemplary embodiment, which can be executed by a service platform, which can be implemented as any device, server, or device cluster with computing and processing capabilities. The method includes the following steps: In step 301, the target transaction data to be processed is determined; in step 302, the transaction count information corresponding to the target account is obtained from the locally pre-stored data; in step 303, the transaction count value corresponding to the current target account is determined based on the transaction count information; and in step 304, the target transaction is sent to the blockchain based on the transaction count value and the target transaction data. In this embodiment, the service platform involved can be connected to the devices of multiple users. Each user holds one or more blockchain accounts. Any user can use their held account to submit a transaction to the blockchain through the service platform to use the services provided by the blockchain (the services provided by the blockchain may include, but are not limited to, transfer services, evidence storage services, and auditing services). Therefore, the service platform can manage multiple accounts simultaneously. Specifically, taking the target account as an example, when a user submits a transaction to the blockchain through the target account, the transaction data used to generate the transaction can first be sent to the service platform. After receiving the transaction data, the service platform can store the transaction data in the first data set corresponding to the target account according to the submission order. The first data set stores at least one set of transaction data sent sequentially by the target account to the service platform. Transaction data can be retrieved from the first data set in sequence, and corresponding transactions can be submitted to the blockchain based on the transaction data. If the target transaction data is retrieved from the first data set, the transaction count information corresponding to the target account can be obtained from the locally pre-stored data. The transaction count information may include the previous transaction count value corresponding to the target account.In one implementation, it can be first determined whether a specified target thread exists. If a specified target thread exists, it can be used to retrieve the transaction count information corresponding to the target account from locally stored data. If a specified target thread does not exist, a target thread can be determined from multiple candidate threads, and then the target thread can be used to retrieve the transaction count information corresponding to the target account from locally stored data. For example, after the service platform receives transactions 1, 2, and 3 from account A, it needs to submit transactions 1, 2, and 3 to the blockchain using threads 1, 2, and 3 respectively. Threads 1, 2, and 3 can be used as candidate threads. Through locking or consensus election, one thread can be selected as the target thread, and the target thread can retrieve the transaction count information corresponding to account A for transactions 1, 2, and 3 respectively. It should be noted that if there are no transactions to be submitted to the blockchain, the target thread can enter a dormant state. After a preset dormant time, the target thread can terminate, and a new target thread needs to be specified subsequently. This embodiment improves the timeliness of transaction count information allocation and increases system throughput and transaction submission success rate by retrieving transaction count information from locally pre-stored data through a designated target thread. In another implementation, a concurrent lock corresponding to the target account can be requested for the target transaction data. This concurrent lock can be a distributed lock; the service platform maintains one concurrent lock for each account. When a set of transaction data submitted by an account is being processed, the concurrent lock corresponding to that account is held. If the concurrent lock corresponding to an account is held, other transaction data submitted by that account cannot acquire the lock and cannot be processed until the lock is released. After acquiring the concurrent lock, the transaction count information corresponding to the target account can be retrieved from locally pre-stored data. In this embodiment, the service platform also stores a second data set corresponding to the target account. The second data set may include the transaction count information corresponding to the target account and transaction data from at least one set of transaction data submitted by the target account that has successfully acquired a distributed lock. Therefore, after acquiring the distributed lock, the target transaction data can be stored in a second data set. Based on the target transaction data and the transaction count information recorded in the second data set, the target transaction is sent to the blockchain. Simultaneously, the transaction count information corresponding to the target account in the second data set is updated by incrementing the previous transaction count value for the target account. Additionally, the second data set may also include a status identifier corresponding to the target transaction data.Before sending the target transaction to the blockchain, the status identifier corresponding to the target transaction data indicates the initial state. Therefore, after acquiring the distributed lock, while storing the target transaction data in the second data set, the status identifier corresponding to the target transaction data (HK 30135838 A PAR2612072HK Specification 7) can be recorded, and this status identifier indicates the initial state. Finally, if it is determined that the target transaction has been accepted, the concurrent lock is released. In this embodiment, after sending the target transaction to the blockchain, the acceptance status information returned by the blockchain for the target transaction can be obtained. This status information may include whether the target transaction was successfully accepted or failed to be accepted. Then, based on this acceptance status information, the status identifier corresponding to the target transaction data is updated from indicating the initial state to indicating a non-initial state. The non-initial state may include a successful acceptance state or a failed acceptance state. Whether the target transaction is successfully accepted or failed to be accepted, it is considered that the target transaction has been accepted. However, if the blockchain has not returned acceptance status information after the target transaction is submitted to the blockchain, and the status identifier corresponding to the target transaction data is in the initial state, it is considered that the target transaction has not been accepted. Therefore, when the status identifier corresponding to the target transaction data indicates a non-initial state, the target transaction is deemed accepted. After the target transaction is accepted, the concurrency lock is released. Furthermore, due to potential communication blockages and data loss, transactions submitted to the blockchain may not be accepted, and the concurrency lock may also fail to be released. Therefore, the status identifiers corresponding to each transaction data included in the second data set can be scanned at a preset period. If a status identifier indicating an initial state exists, the transaction data corresponding to this status identifier can be identified as retry transaction data, and the transaction can be resent to the blockchain based on this retry transaction data, thereby avoiding data loss and the inability to release the concurrency lock. Furthermore, to ensure that the transaction count value on each account's blockchain remains basically consistent with the transaction count value recorded in the service platform, a verification of the transaction count value can be performed periodically. Specifically, the transaction count information currently recorded in the second data set corresponding to the target account can be obtained as the first count information. The transaction count value corresponding to the current target account can be obtained from the blockchain as the second count information. The first and second count information can be compared, and verification can be performed based on the comparison result. For example, if the comparison result indicates that the difference between the value corresponding to the first count information and the value corresponding to the second count information is less than or equal to a preset threshold, the verification can be determined to be successful. If the comparison result indicates that the difference between the value corresponding to the first count information and the value corresponding to the second count information is greater than the preset threshold, the verification can be determined to be unsuccessful, and an early warning reminder operation can be performed.It should be noted that, due to the time difference between obtaining the first and second count information, and the fact that the updates of the first and second count information are not strictly synchronized, a small difference between the first and second count information is allowed. The allowed range of this difference can be set empirically, and this embodiment does not limit this aspect. The blockchain transaction submission management method provided in this embodiment first determines the target transaction data corresponding to the target account when the target account submits a transaction to the blockchain. Then, it obtains the transaction count information corresponding to the target account from locally pre-stored data and sends the target transaction to the blockchain based on the transaction count information and the target transaction data. This achieves unified management of transaction count values ​​for different accounts, improving transaction submission efficiency and ensuring a high success rate. It should be noted that although the operations of the method in the above embodiments are described in a specific order, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Instead, the steps depicted in the flowchart can be executed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps. For ease of description, the above apparatus is described in terms of functionality, divided into various modules. Of course, in implementing this specification, the functions of each module may be implemented in one or more software and / or hardware. This specification also provides a computer-readable non-transitory storage medium storing 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 shown herein, or to provide the functions described or shown 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. Computer-readable non-transitory storage media can be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. This specification also provides a computer system. Figure 4 illustrates an exemplary computer system 1000.In certain embodiments, one or more computer systems 1000 perform one or more steps of the methods described or illustrated herein. In certain embodiments, one or more computer systems 1000 provide the functionality described or illustrated herein. In certain embodiments, software running on one or more computer systems 1000 performs one or more steps of the methods described or illustrated herein, or provides the functionality described or illustrated herein. Certain embodiments include one or more portions of one or more computer systems 1000. 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 1000. This disclosure envisions computer systems 1000 taking any suitable physical form. By way of example and not limitation, computer system 1000 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 1000 may include one or more computer systems 1000; 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 1000 may perform one or more steps of one or more methods described or illustrated herein without substantial spatial or temporal limitations. By way of example and not limitation, one or more computer systems 1000 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 1000 may perform one or more steps of the methods described or illustrated herein at different times or in different locations. In a particular embodiment, computer system 1000 includes a processor 1002, a memory 1004, a storage 1006, an input / output (I / O) interface 1008, a communication interface 1010, and a bus 1012. 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 1002 includes hardware for executing instructions, such as instructions constituting a computer program. By way of example, and not limitation, to execute instructions, processor 1002 may retrieve (or fetch) instructions from internal registers, internal caches, memory 1004, or memory 1006; decode and execute them; and then write one or more results to internal registers, internal caches, memory 1004, or memory 1006. In a particular embodiment, processor 1002 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates that processor 1002 may include any appropriate number of appropriate internal caches where appropriate. By way of example, and not limitation, processor 1002 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 1004 or memory 1006, and the instruction cache may accelerate the retrieval of those instructions by processor 1002. The data in the data cache may be a copy of data in memory 1004 or memory 1006 for instruction operations executed at processor 1002; the result of a previous instruction executed at processor 1002 for subsequent instructions executed at processor 1002 to access or write to memory 1004 or memory 1006; or other suitable data. The data cache can accelerate read or write operations of processor 1002. The TLB can accelerate virtual address translation of processor 1002. In a particular embodiment, processor 1002 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates that processor 1002 may include any suitable number of suitable internal registers where appropriate. Where appropriate, processor 1002 may include one or more arithmetic logic units (ALUs), may be a multi-core processor, or may include one or more processors 1002. Although this disclosure describes and illustrates specific processors, this disclosure contemplates any suitable processor. In a particular embodiment, memory 1004 includes main memory for storing instructions to be executed by processor 1002 or data to be operated by processor 1002. By way of example and not limitation, computer system 1000 may load instructions from memory 1006 or another source (e.g., another computer system 1000) into memory 1004. Processor 1002 may then load instructions from memory 1004 into internal registers or internal cache. To execute instructions, processor 1002 may retrieve instructions from internal registers or internal cache and decode them.During or after instruction execution, processor 1002 may write one or more results (which may be intermediate or final results) to internal registers or internal caches. Processor 1002 may then write one or more of these results to memory 1004. In a particular embodiment, processor 1002 executes only the instructions in one or more internal registers or internal caches or memory 1004 (as opposed to memory 1006 or elsewhere) and operates only on the data in one or more internal registers or internal caches or memory 1004 (as opposed to memory 1006 or elsewhere). One or more memory buses (each memory bus may include an address bus and a data bus) may couple processor 1002 to memory 1004. As described below, bus 1012 may include one or more memory buses. In a particular embodiment, one or more memory management units (MMUs) reside between processor 1002 and memory 1004 and facilitate access to memory 1004 requested by processor 1002. In a particular embodiment, memory 1004 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 1004 may include one or more memories 1004. Although this disclosure describes and illustrates specific memories, this disclosure contemplates any suitable memory. In a particular embodiment, storage 1006 includes mass storage for data or instructions. By way of example and not limitation, storage 1006 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, storage 1006 may include removable or non-removable (or fixed) media. Where appropriate, storage 1006 may be internal or external to computer system 1000. In a particular embodiment, storage 1006 is a non-volatile solid-state memory. In a particular embodiment, storage 1006 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 storage 1006 in any suitable physical form. Where appropriate, storage 1006 may include one or more storage control units facilitating communication between processor 1002 and storage 1006. Where appropriate, storage 1006 may include one or more storage units 1006. Although this disclosure describes and illustrates specific storage, this disclosure contemplates any suitable storage. In a particular embodiment, I / O interface 1008 includes hardware, software, or both, providing one or more interfaces for communication between computer system 1000 and one or more I / O devices. Where appropriate, computer system 1000 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 1000. 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 1008 for them. Where appropriate, I / O interface 1008 may include one or more devices or software drivers that enable processor 1002 to drive one or more of these I / O devices. Where appropriate, I / O interface 1008 may include one or more I / O interfaces 1008. Although this disclosure describes and illustrates specific I / O interfaces, this disclosure contemplates any suitable I / O interface. HK 30135838 A PAR2612072HK Specification 11 In a particular embodiment, the communication interface 1010 includes hardware, software, or both, providing one or more interfaces for communication (e.g., packet-based communication) between computer system 1000 and one or more other computer systems 1000 or one or more networks. By way of example and not limitation, the communication interface 1010 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 1010 for such network. By way of example and not limitation, computer system 1000 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. By way of example, computer system 1000 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 1000 may include any suitable communication interface 1010 for any of these networks. Where appropriate, communication interface 1010 may include one or more communication interfaces 1010. Although this disclosure describes and illustrates specific communication interfaces, this disclosure contemplates any suitable communication interface. In a particular embodiment, bus 1012 includes hardware, software, or both, that couple components of computer system 1000 to each other. By way of example and not limitation, bus 1012 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), 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 Attachment (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 1012 may include one or more buses 1012. Although this disclosure describes and illustrates specific buses, this disclosure contemplates any suitable bus or interconnect. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. HK 30135838 A PAR2612072HK Specification 12 The above descriptions are merely embodiments of this specification and are not intended to limit this specification. For those skilled in the art, this specification can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this application. HK 30135838 A PAR2612072HK Claims 1 1. A method for submitting and managing blockchain transactions, the method being executed by an off-chain target device; the method comprising: determining target transaction data to be processed; the target transaction data corresponding to a target account in the blockchain; obtaining transaction count information corresponding to the target account from locally pre-stored data; determining a transaction count value corresponding to the current target account based on the transaction count information; and sending the target transaction to the blockchain based on the transaction count value and the target transaction data. 2. The method according to claim 1, wherein determining the target transaction data to be processed comprises: receiving at least one set of transaction data submitted by the target account; storing the at least one set of transaction data in a first data set corresponding to the target account in the order of submission; the first data set including the target transaction data; and determining the target transaction data to be processed from the first data set based on the submission order. 3. The method according to claim 1, wherein the transaction count information includes the previous transaction count value corresponding to the target account, wherein determining the current transaction count value corresponding to the target account based on the transaction count information comprises: incrementing the previous transaction count value by one to obtain the current transaction count value corresponding to the target account. 4. According to the method of claim 1, wherein obtaining the transaction count information corresponding to the target account from locally pre-stored data includes: determining whether a specified target thread exists; if the specified target thread exists, obtaining the transaction count information corresponding to the target account from locally pre-stored data using the target thread; if the specified target thread does not exist, determining a target thread from multiple candidate threads, and obtaining the transaction count information corresponding to the target account from locally pre-stored data using the target thread.5. The method according to claim 1, wherein obtaining the transaction count information corresponding to the target account from locally pre-stored data includes: requesting to acquire a concurrency lock corresponding to the target account for the target transaction data; after acquiring the concurrency lock, obtaining the transaction count information corresponding to the target account from locally pre-stored data; wherein, after sending the target transaction to the blockchain, the method further includes: releasing the concurrency lock when it is determined that the target transaction has been accepted. 6. The method according to claim 5, wherein the transaction count information is recorded in a second data set corresponding to the target account locally; the second data set includes at least one set of transaction data submitted by the target account for which a concurrency lock has been successfully acquired; after acquiring the concurrency lock, the method further includes: storing the target transaction data in the second data set. 7. According to claim 6, the method further includes a status identifier corresponding to the target transaction data; before sending the target transaction to the blockchain, the status identifier corresponding to the target transaction data indicates an initial state; after sending the target transaction to the blockchain, the method further includes: obtaining acceptance status information returned by the blockchain for the target transaction; and updating the status identifier corresponding to the target transaction data from indicating the initial state to indicating a non-initial state based on the acceptance status information. 8. According to claim 7, the method further includes: scanning the status identifiers corresponding to each transaction data included in the second data set according to a preset period; determining retry transaction data; the status identifier corresponding to the retry transaction data indicates an initial state; and resending the transaction to the blockchain based on the retry transaction data. 9. According to claim 7, determining that the target transaction is accepted includes: determining that the status identifier corresponding to the target transaction data indicates a non-initial state. 10. According to the method of claim 6, the method further includes: obtaining transaction count information currently recorded in a second data set corresponding to the target account as first count information; obtaining the count value of the transaction corresponding to the target account from the blockchain as second count information; comparing the first count information and the second count information; and performing verification based on the comparison result.11. A computer system comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, performs the following target operation at least once, thereby achieving the following steps: determining target transaction data to be processed; the target transaction data corresponding to a target account in a blockchain; obtaining transaction count information corresponding to the target account from locally pre-stored data; determining a transaction count value corresponding to the current target account based on the transaction count information; and sending the target transaction to the blockchain based on the transaction count information and the target transaction data. HK 30135838 A PAR2612072HK Manual Appendix 1 103 101 102 Figure 1 HK 30135838 A PAR2612072HK Manual Appendix 2 Transaction Compensation Module Lock Management Module Transaction Receiving Module Transaction Management Module Transaction Submission Module Transaction Count Value Verification Module Send Transaction Data D Get Transaction Data D Request Concurrent Lock Update Transaction Count Value, Record Relevant Data of Transaction TX Submit Transaction TX Transaction TX Acceptance Status Update Transaction TX Acceptance Status Release Concurrent Lock Confirm Transaction TX Not Accepted Resubmit Transaction TX Get Current Second Transaction Count Value Get Current First Transaction Count Value Release Concurrent Lock Figure 2A HK 30135838 A PAR2612072HK Manual Appendix 3 Figure 2B HK 30135838 A PAR2612072HK Manual Appendix 4 Get Transaction Count Information Corresponding to Target Account from Locally Pre-stored Data 301 Determine Target Transaction Data to be Processed 302 Based on the transaction count information, determine the transaction count value corresponding to the current target account 303. Based on the transaction count value and the target transaction data, send the target transaction to the blockchain 304. Figure 3 Computer system 1000 Processor 1002 Input / output (I / O) interface 1008 Memory 1004 Storage 1006 Communication interface 1010 Figure 4 HK 30135838 A.

Images