Transaction caching method and blockchain node

Abstract

Embodiments of the present application provide a transaction caching method and a blockchain node. The method is executed by the blockchain node, and the blockchain node comprises n transaction pool shards for caching transactions. The method comprises: receiving a transaction Tx1, the transaction Tx1 comprising a sender account Sender1 (S501); on the basis of the sender account Sender1, determining a target transaction pool shard to which the transaction Tx1 belongs among the n transaction pool shards (S503); and caching the transaction Tx1 to the target transaction pool shard (S505). Sharding and scalable deployment are performed on a transaction pool, and sender accounts of transactions are used as the basis for determining transaction pool shards to which the transactions belong, such that the throughput and performance of the transaction of each transaction pool shard are ensured, thus enabling a blockchain system to support ultra-large-scale accounts and extremely high CTPS, achieving extremely high transaction processing performance.

Description

Transaction caching method and blockchain node

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on October 31, 2023, with application number 202311439598.X and application name “Transaction Caching Method and Blockchain Node”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of this specification belong to the field of blockchain technology, and in particular to a transaction caching method and a blockchain node. Background Art

[0003] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain, data blocks are linked sequentially in chronological order to form a chain-like data structure, and cryptography is used to ensure that these blocks cannot be tampered with or forged. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application.

[0004] Summary of the Invention

[0005] The purpose of this invention is to provide a transaction caching solution that enables the blockchain system to support ultra-large-scale accounts and extremely high CTPS (Confirmed Transactions Per Second), thereby achieving extremely high transaction processing performance.

[0006] In a first aspect, the present specification provides a transaction caching method, which is executed by a blockchain node, wherein the blockchain node includes n transaction pool shards for caching transactions. The method includes: receiving a first transaction, wherein the first transaction includes a first sender account; based on the first sender account, determining a target transaction pool shard among the n transaction pool shards to which the first transaction belongs; and caching the first transaction in the target transaction pool shard.

[0007] According to a second aspect of the present specification, a blockchain node is provided, comprising n transaction pool shards for caching transactions, the blockchain node comprising: a receiving unit configured to receive a first transaction, wherein the first transaction includes a first sender account; a determining unit configured to determine, based on the first sender account, a target transaction pool shard to which the first transaction belongs among the n transaction pool shards; and a storage unit configured to cache the first transaction in the target transaction pool shard.

[0008] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

[0009] A fourth aspect of this specification provides a computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0010] A fifth aspect of this specification provides a computer program product, which, when executed in a computer, causes the computer to execute the method described in the first aspect.

[0011] In the solution provided in the embodiments of this specification, the transaction pool can be sharded and scalably deployed, and the sender account of the transaction is used as the basis for determining the transaction pool shard to which the transaction belongs, thereby ensuring the throughput and performance of transactions in each transaction pool shard. This enables the blockchain system to support ultra-large-scale accounts and extremely high CTPS, achieving extremely high transaction processing performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0013] FIG1 is a diagram of a blockchain system architecture in one embodiment;

[0014] FIG2 is a schematic diagram of the structure of a blockchain node in one embodiment;

[0015] FIG3 is a schematic diagram of the structure of the cache process in an embodiment of this specification;

[0016] FIG4 is a schematic diagram of a resource sharing mode of a transaction pool shard in an embodiment of this specification;

[0017] FIG5 is a flow chart of a transaction caching method according to an embodiment of the present specification;

[0018] FIG6 is a flow chart of a transaction caching method according to an embodiment of the present specification;

[0019] FIG7 is a schematic diagram of a transaction caching process including a transaction verification process in an embodiment of this specification;

[0020] FIG8 is a schematic diagram of the structure of a blockchain node in an embodiment of this specification. DETAILED DESCRIPTION

[0021] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0022] Figure 1 illustrates a blockchain system architecture diagram in one embodiment. In the blockchain system architecture diagram shown in Figure 1, the blockchain system includes N nodes, with nodes 1 through 8 schematically illustrated. The lines connecting the nodes schematically represent connections between them, such as TCP connections, for example, for transmitting data between nodes. These nodes can store the full ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain system can generate the same state by executing the same transactions, and each node in the blockchain system can store the same state database.

[0023] A transaction in the blockchain world refers to a unit of work executed and recorded within a blockchain system. A transaction typically includes a sender (From), a receiver (To), and a data field (Data). For example, in a transfer transaction, the From field indicates the address of the account initiating the transaction (i.e., initiating a transfer to another account), the To field indicates the address of the account receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0024] Figure 2 shows a schematic diagram of the blockchain node architecture in one embodiment. As shown in Figure 2, a blockchain node may include a cache process for providing cache services. A process is a computer program's execution of a data set. It serves as the fundamental unit of resource allocation and the foundation of the operating system's architecture. This cache process can also be implemented as a transaction pool module. Existing cache processes typically include a single transaction pool, which can be a memory area used to cache transactions received by the blockchain node before being uploaded. As the core process for transaction lifecycle management in a blockchain system, the cache process must provide basic functions such as transaction verification, deduplication, and caching. In secure and high-performance scenarios, it also requires capabilities such as transaction flow control, DDoS (Distributed Denial of Service) attack protection, and account caching.

[0025] In addition, blockchain nodes may also include multiple processes that can call cached processes, such as the consensus process for providing consensus services and the execution process for executing transactions, as shown in Figure 2. The consensus process can, for example, read a batch of pending transactions or transaction information for that batch of transactions from the cached process's transaction pool, generate a consensus proposal based on the read batch of transactions or transaction information, and then reach consensus on the consensus proposal with the consensus processes of other blockchain nodes. After successfully reaching consensus on the consensus proposal, the execution process can, for example, read and execute the batch of transactions from the transaction pool.

[0026] Because all of the aforementioned processes in blockchain nodes require the use of cache processes, a single-instance transaction pool becomes a performance bottleneck in scenarios with extremely large account sizes and extremely high transaction throughput requirements (such as digital resource transactions). This requires caching / reading a vast amount of account information and verifying / caching / forwarding a vast number of transactions. The physical resources of a single machine, including the CPU (Central Processing Unit), memory, network, and IO (Input / Output), all become bottlenecks restricting transaction throughput. Therefore, a high-performance, scalable cache process is needed for this scenario to overcome the limitations of a single machine's physical resources.

[0027] In order to meet the transaction processing / caching requirements of scenarios with extremely large accounts (e.g., more than one billion accounts) and extremely high CTPS (e.g., hundreds of thousands of CTPS), the solution provided in the embodiments of this specification can shard and scalably deploy the existing single-instance transaction pool. Specifically, as shown in Figure 3, n transaction pool shards can be divided in the cache process for caching transactions. Figure 3 is a schematic diagram of the structure of the cache process in the embodiments of this specification. Any of the n transaction pool shards can be called a transaction pool instance or transaction pool, which can specifically be a memory area used to cache transactions received by blockchain nodes to be uploaded to the chain.

[0028] The number n of transaction pool shards is a natural number greater than 1. In addition, n can be determined based on the maximum scalability expected of the cache process. In one example, n can be an even number, such as an even number within (1, 256], or an even number within (256, 65536], etc. Furthermore, n can be 256. After n transaction pool shards are divided, numbers can be assigned to the n transaction pool shards. As an example, the number of any transaction pool shard among the n transaction pool shards can be an integer within [0, n-1]. Taking n = 256 as an example, the number of any transaction pool shard among the 256 transaction pool shards divided can be an integer within [0, 255].

[0029] Under different deployment modes, the transaction pool shards can share or exclusively share the resources of the cache process. For example, when the cache process is deployed on n devices, n transaction pool shards can be deployed on different devices among the n devices, so that a single transaction pool shard can exclusively share the resources of the cache process, as shown by label 401 in Figure 4. Among them, Figure 4 is a schematic diagram of the resource sharing mode of the transaction pool shards in the embodiment of this specification. When the cache process is deployed on multiple devices and the number of the multiple devices is less than n, n transaction pool shards can be deployed on the multiple devices, and some of the n transaction pool shards can be deployed on different devices, so that more than two (including two) of the n transaction pool shards can share the resources of the cache process, for example, as shown by label 402 in Figure 4, n transaction pool shards can share resources in two shards. In addition, when the cache process is deployed on a single device, n transaction pool shards can be deployed on the single device, so that the n transaction pool shards can share the resources of the cache process. For example, when n=256, as shown in label 403 in Figure 4, 256 transaction pool shards can share system resources.

[0030] In one embodiment, in order to improve the security and performance of the entire blockchain system, before the received transaction Tx1 to be on-chain is cached in the corresponding transaction pool shard, a verification process can be performed on the transaction Tx1. The verification process may need to verify the transaction Tx1 based on the account status of the sender of the transaction Tx1 and / or the transaction information of the transaction Tx2 sent by the sender and successfully verified. In order to improve the efficiency of transaction verification, the cache process can be made to cache part of the account status and part of the transaction information. Based on this, the cache process can also be divided into n first cache shards (for example, the n account cache shards shown in Figure 3) and n second cache shards (for example, the n anti-replay meta-information shards shown in Figure 3).

[0031] The n transaction pool shards can correspond to different account cache shards and different anti-replay meta-information shards. That is, one transaction pool shard can be bound to one account cache shard and one anti-replay meta-information shard. The account cache shard can be used to cache the account status of the sender of transactions in its corresponding transaction pool shard. This account status may include, for example, the sender's account, the public key corresponding to the sender's account, and the account balance. The anti-replay meta-information shard can be used to cache transaction information for successfully verified transactions Tx2 sent by the sender of transactions in its corresponding transaction pool shard (e.g., sent within a set time period). The set time period can be, for example, 5 minutes or 10 minutes, and can be set based on actual needs and is not specifically limited here. Transaction Tx2 refers to one or more transactions Tx2. The transaction information of transaction Tx2 can be referred to as transaction meta-information or anti-replay meta-information, and may include any of the following: the hash value of transaction Tx2, or multiple pieces of information in transaction Tx2, including at least the sender's account and nonce value. The nonce value may represent the number of transactions sent from the sender account. Furthermore, the multiple pieces of information may also include a timestamp.

[0032] Additionally, the account cache shard and the anti-replay meta-information shard can reside on the same device as their corresponding transaction pool shard. It is understood that the account cache shard can share or exclusively use the cache process's resources, as shown in Figure 4; the anti-replay meta-information shard can also share or exclusively use the cache process's resources, as shown in Figure 4.

[0033] In one embodiment, the above-mentioned verification process can be used to check transaction flow control. In order to implement transaction flow control for the transaction pool shard, capacity thresholds can be configured for each of the n transaction pool shards, thereby performing transaction flow control on the transaction pool shard based on the capacity threshold of the transaction pool shard. As an example, the sources of transactions can be divided into those sent by user devices, those forwarded by other blockchain nodes, and those synchronized by other blockchain nodes. Among them, transactions from the first two sources are transactions that are not on the chain and do not participate in consensus, and are refusalable transactions. Transactions from the last source may be transactions that are not on the chain but are participating in consensus, and are non-refusalable transactions. Based on this, a first threshold and a second threshold can be configured for the transaction pool shard. The first threshold can be a capacity threshold for performing transaction flow control on transactions received from user devices, and the second threshold can be a capacity threshold for performing transaction flow control on transactions forwarded by other blockchain nodes. In one example, the second threshold can be greater than the first threshold.

[0034] The foregoing text introduces a high-performance, scalable cache process designed in accordance with the embodiments of this specification in conjunction with FIG. 3 and FIG. 4 , which can break through the limitations of physical resources on a single machine.

[0035] Based on the caching process shown in Figure 3, embodiments of this specification provide a transaction caching method. This method can be executed by a blockchain node that includes n transaction pool shards for caching transactions. For example, the caching process in the blockchain node includes n transaction pool shards for caching transactions. The method can include steps S501-S505 as shown in Figure 5. Figure 5 is a flow chart of the transaction caching method in embodiments of this specification.

[0036] As shown in FIG5 , in step S501 , a transaction Tx1 is received, and the transaction Tx1 includes a sender account Sender1 .

[0037] Specifically, in step S501, one or more transactions Tx1 may be received. Any transaction Tx1 may be received from a user device or from another blockchain node. In the case where the transaction Tx1 is received from another blockchain node, the transaction Tx1 may be forwarded by the other blockchain node or synchronized by the other blockchain node.

[0038] In step S503, based on the sender account Sender1, the target transaction pool shard to which the transaction Tx1 belongs among the n transaction pool shards is determined.

[0039] Specifically, in one embodiment, when the sender account Sender1 included in the transaction Tx1 is a hexadecimal string, the characters at the target position (e.g., the first m bytes, etc.) in the sender account Sender1 can be converted into a decimal number, where m can be determined based on n. For example, when n is within (1, 256], m may be 1; when n is within (256, 65536], m may be 2. Subsequently, the target transaction pool shard to which transaction Tx1 belongs among the n transaction pool shards may be determined based on the decimal number obtained by conversion. In one example, when the decimal number is less than n, the transaction pool shard with the same number as the decimal number among the n transaction pool shards may be determined as the target transaction pool shard to which transaction Tx1 belongs; when the decimal number is greater than or equal to n, the decimal number may be modulo n to obtain the remainder, and the transaction pool shard with the same number as the remainder among the n transaction pool shards may be determined as the target transaction pool shard to which transaction Tx1 belongs. In another example, after obtaining the decimal number, the decimal number may be directly modulo n to obtain the remainder, and the transaction pool shard with the same number as the remainder among the n transaction pool shards may be determined as the target transaction pool shard to which transaction Tx1 belongs.

[0040] In another embodiment, the sender account Sender1 included in the transaction Tx1 can be hashed to obtain a hash value h1. For example, the sender account Sender1 can be hashed using a determined and consistent random hash algorithm to obtain a hash value h1. Thereafter, the target transaction pool shard to which the transaction Tx1 belongs among the n transaction pool shards can be determined based on the hash value h1. In practice, the hash value is generally a hexadecimal string. In the case where the hash value h1 is a hexadecimal string, when determining the target transaction pool shard to which the transaction Tx1 belongs among the n transaction pool shards based on the hash value h1, the characters at the target position of the hash value h1 (e.g., the first m bytes, etc.) can be converted into a decimal number, and then based on the decimal number obtained by the conversion, the target transaction pool shard to which the transaction Tx1 belongs among the n transaction pool shards can be determined; wherein, the specific determination process can refer to the two examples listed in the previous paragraph, which will not be repeated here.

[0041] For example, consider the hash value h1 as "0x7f8c8e9f...", the target position as the first m bytes, n = 256, and m = 1. The "0x" in "0x7f8c8e9f..." represents hexadecimal, and "7f" represents the first byte. To determine the target transaction pool shard for transaction Tx1 among the n transaction pool shards based on "0x7f8c8e9f...", the first byte "7f" of "0x7f8c8e9f..." can be converted to the decimal number 127. Then, the remainder 127 is calculated by taking the remainder from n (e.g., 127% n). The target transaction pool shard for transaction Tx1 can then be determined as the transaction pool shard numbered 127.

[0042] It should be noted that using the sender account in a transaction as the basis for determining the target transaction pool shard to which the transaction belongs can ensure that the account size and anti-replay metadata set size of a single transaction pool shard are within a reasonable range, ensuring the throughput and performance of transactions in each transaction pool shard.

[0043] In step S505, transaction Tx1 is cached to the target transaction pool shard.

[0044] Among them, when the transaction Tx1 consists of multiple transactions Tx1, the multiple transactions Tx1 can be cached in the target transaction pool shards to which they belong. In one example, the transaction pool shard may include a transaction set, which may be an unordered set; when caching the transaction Tx1 in the target transaction pool shard to which it belongs, the transaction Tx1 can be specifically cached in the transaction set in the target transaction pool shard to which it belongs. It should be noted that by receiving multiple transactions Tx1 and caching the multiple transactions Tx1 in the target transaction pool shards to which they belong, batch caching of transactions can be achieved, which can improve the throughput efficiency of the caching process.

[0045] In one embodiment, the consensus process in a blockchain node may include a memory area for caching transaction-related information. After caching transaction Tx1 in the target transaction pool shard to which transaction Tx1 belongs, the blockchain node may provide the transaction-related information of transaction Tx1 to the consensus process, so that the consensus process caches the transaction-related information in the memory area. The transaction-related information may include the number of the target transaction pool shard to which transaction Tx1 belongs, the sender account Sender1, the nonce value, and the timestamp in transaction Tx1, etc. The transaction-related information in the memory area may be arranged in ascending order based on the timestamp. In addition, the transaction-related information cached in the memory area can be used by the consensus process to determine which transactions to package into the same consensus proposal for consensus, and to identify which transaction pool shard each of these transactions belongs to.

[0046] The solution provided by the embodiment corresponding to Figure 5 can ensure the throughput and performance of transactions in each transaction pool shard by sharding and scalable deployment of the transaction pool, and use the sender account of the transaction as the basis for determining the target transaction pool shard to which the transaction belongs. This enables the blockchain system to support ultra-large-scale accounts and extremely high CTPS, achieving extremely high transaction processing performance.

[0047] As mentioned above, in order to improve the security and performance of the entire blockchain system, a verification process can be performed on the received transaction Tx1 before caching it in the corresponding target transaction pool shard.

[0048] The following further describes a transaction caching method including a transaction verification process, in conjunction with Figure 6. Figure 6 is a flow chart of the transaction caching method according to an embodiment of this specification. This method can be executed by a blockchain node, which can include n transaction pool shards for caching transactions. Furthermore, the blockchain node can also include n account cache shards and n anti-replay meta-information shards. The n transaction pool shards can correspond to different account cache shards and different anti-replay meta-information shards.

[0049] As shown in FIG6 , in step S601 , a transaction Tx1 is received, and the transaction Tx1 includes a sender account Sender1 .

[0050] In step S603, based on the sender account Sender1, the target transaction pool shard to which the transaction Tx1 belongs among the n transaction pool shards is determined.

[0051] Among them, for the explanation of steps S601 and S603, please refer to the relevant explanation of steps S501 and S503 in the previous text, which will not be repeated here.

[0052] In step S605, a verification process is performed on transaction Tx1.

[0053] The verification process may involve one or more aspects of the verification process. In one embodiment, the verification process may include sub-process sp3 for transaction replay verification, sub-process sp4 for transaction integrity verification, and / or sub-process sp5 for account balance verification, described below. For explanations of sub-processes sp3, sp4, and sp5, please refer to the relevant description below.

[0054] In another embodiment, when the verification process involves multiple checks, the verification process may include a sub-process sequence formed by multiple sub-processes. These multiple sub-processes are used to check different aspects; in other words, these multiple sub-processes correspond to different check items. A single check item may include any of the following, for example: transaction flow control check, transaction legitimacy check, transaction replay check, transaction integrity check, account balance check, etc.

[0055] When the verification process includes a sub-process sequence, the sub-processes in the sub-process sequence can be executed sequentially for transaction Tx1 along the direction from the head to the tail of the sub-process sequence. Specifically, for any i-th sub-process in the sub-process sequence, if transaction Tx1 fails to pass the inspection of the i-th sub-process, it can be determined that transaction Tx1 has failed verification. If transaction Tx1 passes the inspection of the i-th sub-process and there is a next sub-process of the i-th sub-process in the sub-process sequence, the next sub-process can be executed for transaction Tx1. If transaction Tx1 passes the inspection of the i-th sub-process and there is no next sub-process of the i-th sub-process in the sub-process sequence, it can be determined that transaction Tx1 has been successfully verified. Wherein, i is a natural number in [1, s], and s is the number of sub-processes in the sub-process sequence.

[0056] It should be noted that when the sub-process sequence includes a sub-process sp1 for transaction flow control checks, sub-process sp1 may include: in response to transaction Tx1 being received from a user device, determining whether the number of transactions cached in the target transaction pool shard to which transaction Tx1 belongs reaches a capacity threshold corresponding to the target transaction pool shard; if the determination result is yes, determining that transaction Tx1 has failed the check; if the determination result is no, determining that transaction Tx1 has passed the check. In one example, the capacity threshold may be the first threshold described above. Furthermore, sub-process sp1 may also include: in response to transaction Tx1 being forwarded by another blockchain node, determining whether the number of transactions cached in the target transaction pool shard to which transaction Tx1 belongs reaches a second threshold corresponding to the target transaction pool shard; if the determination result is yes, determining that transaction Tx1 has failed the check; if the determination result is no, determining that transaction Tx1 has passed the check. Optionally, sub-process sp1 may also include: in response to transaction Tx1 being synchronized by another blockchain node, determining that transaction Tx1 has passed the check.

[0057] When the sub-process sequence includes a sub-process sp2 for checking the legitimacy of a transaction, the sub-process sp2 may include: determining whether the structure of transaction Tx1 is a structure supported by the blockchain node; if the determination result is yes, determining that transaction Tx1 passes the check; if the determination result is no, determining that transaction Tx1 fails the check.

[0058] When the sub-process sequence includes a sub-process sp3 for transaction replay check, the sub-process sp3 may include: determining whether transaction Tx1 is a replayed transaction based on the transaction information cached in the anti-replay meta-information shard corresponding to the target transaction pool shard to which transaction Tx1 belongs; if the determination result is yes, determining that transaction Tx1 has failed the check; if the determination result is no, determining that transaction Tx1 has passed the check.

[0059] When determining whether transaction Tx1 is a replay transaction based on the transaction information cached in the anti-replay meta-information shard, in one example, when the cached transaction information includes the hash value h2 of the corresponding transaction Tx2, the hash value h3 of transaction Tx1 can be calculated, and a determination can be made as to whether target transaction information with the same hash values ​​h2 and h3 exists in the anti-replay meta-information shard. If such target transaction information exists, transaction Tx1 can be determined to be a replay transaction; otherwise, transaction Tx1 can be determined to be not a replay transaction. In another example, when the cached transaction information includes a sender account (sender2) and a nonce value, a determination can be made as to whether target transaction information with the same sender account and nonce value as the sender account and nonce value in transaction Tx1 exists in the anti-replay meta-information shard. If such target transaction information exists, transaction Tx1 can be determined to be a replay transaction; otherwise, transaction Tx1 can be determined to be not a replay transaction. In another example, when the cached transaction information includes the sender account sender2, nonce value and timestamp, it can be determined whether there is target transaction information in the anti-replay meta-information shard whose sender2, nonce value and timestamp are the same as the sender1, nonce value and timestamp in transaction Tx1. If it is determined that the target transaction information exists, it can be determined that transaction Tx1 is a replay transaction; otherwise, it can be determined that transaction Tx1 is not a replay transaction.

[0060] In one embodiment, when the transaction Tx1 is successfully verified, the transaction information of the transaction Tx1 may be cached in the anti-replay meta-information shard.

[0061] When the sub-process sequence includes a sub-process sp4 for transaction integrity check, the sub-process sp4 may include: searching for the sender account Sender1 in transaction Tx1 in the account cache shard corresponding to the target transaction pool shard to which transaction Tx1 belongs; if Sender1 is found, reading the public key associated with Sender1 from the account cache shard; if Sender1 is not found, or the public key is not read from the account cache shard, searching for the account state of Sender1 in the state database, and reading the public key from the account state; based on the read public key, verifying the signature based on the private key of the sender of transaction Tx1 included in transaction Tx1; if the signature passes verification, determining that transaction Tx1 passes the check; if the signature fails verification, determining that transaction Tx1 fails the check.

[0062] In one embodiment, when the public key associated with Sender1 is read from the state database, after the transaction Tx1 is successfully verified, the public key associated with Sender1 can be written into the account cache shard.

[0063] When the sub-process sequence includes a sub-process sp5 for account balance checking, the sub-process sp5 may include: searching for the sender account Sender1 in transaction Tx1 from the account cache shard corresponding to the target transaction pool shard to which transaction Tx1 belongs; if Sender1 is found, reading the account balance associated with Sender1 from the account cache shard; if Sender1 is not found, or the account balance is not read from the account cache shard, searching for the account status of Sender1 in the status database, and reading the account balance from the account status; determining whether the total amount of resources (gas limit) corresponding to transaction Tx1 included in transaction Tx1 is greater than the read account balance; if the determination result is yes, determining that transaction Tx1 has failed the check; if the determination result is no, determining that transaction Tx1 has passed the check.

[0064] In one embodiment, when reading the account balance associated with Sender1 from the state database, after transaction Tx1 is successfully verified, the account balance read can be updated based on transaction Tx1, for example, the account balance is reduced by the total amount of resources corresponding to transaction Tx1, and then the updated account balance is associated with Sender1 and written to the account cache shard. It should be noted that when the account balance read is reduced by the total amount of resources corresponding to transaction Tx1, when transaction Tx1 fails to execute, the account balance associated with Sender1 cached in the account cache shard can be increased by the total amount of resources; or, after transaction Tx1 is executed, in response to the actual resource consumption of transaction Tx1 being less than the total amount of resources, the difference between the total amount of resources and the actual resource consumption can be determined, and the account balance associated with Sender1 cached in the account cache shard can be increased by the difference.

[0065] In one embodiment, in order to cope with DDos attacks and improve verification efficiency, the sub-process sequence can be formed by arranging the above-mentioned multiple sub-processes in order of execution cost from low to high. As an example, when the above-mentioned multiple sub-processes include the sub-process sp1, sub-process sp2, sub-process sp3, sub-process sp4 and sub-process sp5 as described above, and the sub-process sequence is formed by arranging the above-mentioned multiple sub-processes in order of execution cost from low to high, along the direction from the head to the tail of the sub-process sequence, the sub-processes in the sub-process sequence can be as shown in Figure 7, which are sub-process sp1 (represented by transaction flow control check in Figure 7), sub-process sp2 (represented by transaction legitimacy check in Figure 7), sub-process sp3 (represented by transaction replay check in Figure 7), sub-process sp4 (represented by transaction integrity check in Figure 7), and sub-process sp5 (represented by account balance check in Figure 7). Among them, Figure 7 is a schematic diagram of the transaction caching process including the transaction verification process in the embodiment of this specification. As shown in FIG7 , when executing the verification process for transaction Tx1 , the sub-processes in the sub-process sequence may be executed sequentially for transaction Tx1 starting from sub-process sp1 .

[0066] In step S607, in response to successful verification of transaction Tx1, transaction Tx1 is cached to the target transaction pool shard.

[0067] Specifically, as shown in FIG7 , in response to successful verification of transaction Tx1, transaction Tx1 is cached to the target transaction pool shard to which it belongs.

[0068] The solution provided by the embodiment corresponding to Figure 6 ensures transaction throughput and performance for each transaction pool shard through sharding and scalable deployment of the transaction pool. This solution uses the transaction sender account as the basis for determining the target transaction pool shard to which the transaction belongs. This enables the blockchain system to support ultra-large accounts and extremely high CTPS, achieving extremely high transaction processing performance. Furthermore, after determining the target transaction pool shard to which a transaction belongs, a verification process is performed on the transaction, and upon successful verification, the transaction is cached in the target transaction pool shard, effectively improving the security and performance of the entire blockchain system.

[0069] As described above, the solution provided by the embodiments of this specification can overcome the resource limitations of a single instance and single machine in the cache process. According to the sharding scheme of this solution, the transaction pool is sharded and scalable, fully utilizing the resources (CPU, memory, network, and I / O) of multiple machines. Under the same blockchain consensus network, it supports large-scale accounts and extremely high transaction CTPS. Under the same network, the performance bottlenecks of cross-group and cross-chain are naturally overcome.

[0070] Figure 8 is a schematic diagram of the structure of a blockchain node in an embodiment of this specification. The blockchain node includes n transaction pool shards for caching transactions. The blockchain node can execute the methods shown in Figures 5 and 6 and includes: a receiving unit 801 configured to receive a first transaction, the first transaction including a first sender account; a determining unit 802 configured to determine, based on the first sender account, a target transaction pool shard among the n transaction pool shards to which the first transaction belongs; and a storage unit 803 configured to cache the first transaction in the target transaction pool shard.

[0071] The embodiments of this specification also provide a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the methods shown in FIG. 5 and FIG. 6 .

[0072] An embodiment of this specification further provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method shown in Figures 5 and 6 is implemented.

[0073] The embodiments of this specification also provide a computer program product, wherein when the computer program product is executed in a computer, the computer is caused to execute the methods shown in FIG. 5 and FIG. 6 .

[0074] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0075] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0076] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0077] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0078] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0079] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0080] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0081] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0082] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0083] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0084] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0085] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0086] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0087] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0088] The foregoing description is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. Those skilled in the art will appreciate that various modifications and variations of one or more embodiments of this specification are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification are intended to be included within the scope of the claims.

Claims

1. A transaction caching method, executed by a blockchain node, wherein the blockchain node includes n transaction pool shards, the method comprising: receiving a first transaction, wherein the first transaction includes a first sender account; Based on the first sender account, determine a target transaction pool shard to which the first transaction belongs among the n transaction pool shards; The first transaction is cached in the target transaction pool shard.

2. The method according to claim 1, wherein: The determining, based on the first sender account, a target transaction pool shard to which the first transaction belongs among the n transaction pool shards includes: Performing hash calculation on the first sender account to obtain a first hash value; Based on the first hash value, determine the target transaction pool shard to which the first transaction belongs among the n transaction pool shards.

3. The method according to claim 1, further comprising: performing a verification process on the first transaction; The caching the first transaction to the target transaction pool shard includes: In response to successful verification of the first transaction, the first transaction is cached in the target transaction pool shard.

4. The method according to claim 3, wherein: The verification process includes a sub-process sequence, and the sub-process sequence is formed by arranging multiple sub-processes in order of execution cost from low to high; The performing of a verification process on the first transaction includes: The sub-processes in the sub-process sequence are sequentially executed for the first transaction in a direction from the head to the tail of the sub-process sequence.

5. The method according to claim 4, wherein: The sub-process sequence includes a first sub-process for transaction flow control checking, and the first sub-process includes: In response to the first transaction being received from a user device, determining whether the number of transactions cached in the target transaction pool shard reaches a capacity threshold corresponding to the target transaction pool shard; If the determination result is yes, it is determined that the first transaction has failed the check; If the determination result is no, it is determined that the first transaction passes the check.

6. The method according to claim 4, wherein: The sub-process sequence includes a second sub-process for transaction legitimacy checking, and the second sub-process includes: Determining whether the structure of the first transaction is a structure supported by the blockchain node; If the determination result is yes, then it is determined that the first transaction passes the inspection; If the determination result is negative, it is determined that the first transaction has failed the check.

7. The method according to claim 3 or 4, wherein: The blockchain node further includes n first cache shards, the n transaction pool shards correspond to different first cache shards, and the first cache shard is used to cache transaction information of a second transaction sent by a sender of a transaction in the corresponding transaction pool shard and successfully verified; The verification process includes a third sub-process for transaction replay checking, and the third sub-process includes: Determining whether the first transaction is a replay transaction based on the transaction information cached by the first cache shard corresponding to the target transaction pool shard; If the determination result is yes, it is determined that the first transaction has failed the check; If the determination result is no, it is determined that the first transaction passes the check.

8. The method according to claim 7, further comprising: In response to successful verification of the first transaction, the transaction information of the first transaction is written into a first cache shard corresponding to the target transaction pool shard.

9. The method according to claim 7, wherein: The transaction information of the second transaction includes any one of the following: a second hash value of the second transaction, multiple pieces of information in the second transaction, and the multiple pieces of information at least include a second sender account and a nonce value.

10. The method according to claim 3 or 4, wherein: The blockchain node also includes n second cache shards, the n transaction pool shards correspond to different second cache shards, and the second cache shard is used to cache the account status of the sender of the transaction in the corresponding transaction pool shard.

11. The method according to claim 10, wherein: The first transaction includes a signature based on a private key of a sender of the first transaction; the verification process includes a fourth sub-process for transaction integrity check, and the fourth sub-process includes: Reading a public key associated with the first sender account from a second cache shard corresponding to the target transaction pool shard; Verifying the signature based on the read public key; If the signature passes the verification, it is determined that the first transaction passes the inspection; If the signature fails to be verified, it is determined that the first transaction fails the check.

12. The method according to claim 10, wherein: The first transaction includes the total amount of resources corresponding to the first transaction; the verification process includes a fifth sub-process for checking the account balance, and the fifth sub-process includes: Reading an account balance associated with the first sender account from a second cache shard corresponding to the target transaction pool shard; Determine whether the total amount of resources is greater than the read account balance; If the determination result is yes, it is determined that the first transaction has failed the check; If the determination result is no, it is determined that the first transaction passes the check.

13. The method according to claim 12, wherein: Before determining whether the total amount of resources is greater than the read account balance, the method further includes: If the account balance is not read from the second cache shard corresponding to the target transaction pool shard, the account balance is read from the state database.

14. The method according to claim 13, wherein: In the case where the account balance is read from a state database, the method further comprises: In response to successful verification of the first transaction, the account balance is updated based on the first transaction, and the updated account balance is associated with the first sender account and written into a second cache shard corresponding to the target transaction pool shard.

15. The method according to claim 1, wherein: At least some of the n transaction pool shards are deployed on different devices.

16. A blockchain node, the blockchain node comprising n transaction pool shards for caching transactions, the blockchain node comprising: A receiving unit, configured to receive a first transaction, wherein the first transaction includes a first sender account; A determination unit is configured to determine, based on the first sender account, a target transaction pool shard to which the first transaction belongs among the n transaction pool shards; A storage unit is configured to cache the first transaction to the target transaction pool shard.

17. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 15.

18. A computing device, comprising a memory and a processor, wherein the memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 15 is implemented.

Images