Transaction caching and ordering method, apparatus, electronic device, and storage medium

Abstract

The application provides a transaction caching and sequencing method, device, electronic equipment and storage medium, relates to the technical field of blockchains, and the method comprises the following steps: in response to a transaction event initiated by a user, performing transaction verification in a Byzantine sequencing transaction pool and adding the transaction to a verified to-be-sequenced transaction set; determining a transaction global trusted timestamp based on preset timestamps corresponding to transaction events corresponding to a preset number of nodes in the to-be-sequenced transaction set; sequencing the transaction events in the to-be-sequenced transaction set based on the transaction global trusted timestamp to obtain a trusted chain table, so that a consensus protocol obtains transactions in sequence based on the trusted chain table and performs consensus processing. The application alleviates the technical problem of the "hegemony" of the order of the main node at the consensus level in the existing blockchain, avoids the review attack on the transaction, and improves the stability and security of the transaction.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method, apparatus, electronic device and storage medium for transaction caching and sorting. Background Technology

[0002] In current blockchain platforms, the order of transactions within a block is determined by the node itself when the transaction nodes produce a block. Because the blockchain system is decentralized, this ordering of transactions within the transaction pool is vulnerable to censorship attacks. From the node perspective, to maximize their own interests, nodes typically package transactions according to gas fee order. Therefore, each node has the right to determine the transaction order, making it susceptible to censorship attacks. From the user perspective, setting high gas fees to prevent specific transactions from being submitted also creates a censorship attack opportunity. Summary of the Invention

[0003] The purpose of this application is to provide a method, apparatus, electronic device, and storage medium for transaction caching and sorting, so as to alleviate the technical problem of the "hegemony" of the master node over the order at the consensus level in the blockchain in the prior art.

[0004] In a first aspect, the present invention provides a method for transaction caching and sorting, the method being applied to a blockchain node; the method includes: In response to user-initiated transaction events, the transaction is verified in the Byzantine sorted transaction pool and added to the verified set of transactions to be sorted. Based on the preset timestamps corresponding to the transaction events of a preset number of nodes in the unsorted transaction set, a globally reliable timestamp for the transaction is determined; The transaction events in the unsorted transaction set are sorted based on the globally trusted timestamp of the transaction to obtain a trusted linked list, so that the consensus protocol can obtain transactions in order based on the trusted linked list and perform consensus processing; wherein, the trusted linked list caches transaction information including the trusted timestamp.

[0005] Secondly, the present invention provides a transaction caching and sorting apparatus, the apparatus being applied to a blockchain node; the apparatus includes: The caching and verification module is used to respond to user-initiated transaction events, verify transactions in the Byzantine sorted transaction pool, and add them to the verified unsorted transaction set. The trusted timestamp determination module is used to determine the global trusted timestamp of a transaction based on the preset timestamps corresponding to the transaction events of a preset number of nodes in the unsorted transaction set. The sorting module is used to sort the transaction events in the unsorted transaction set based on the global trusted timestamp of the transaction to obtain a trusted linked list, so that the consensus protocol can obtain transactions in order based on the trusted linked list and perform consensus processing; wherein, the trusted linked list caches transaction information including the trusted timestamp.

[0006] Thirdly, the present invention provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the transaction caching and sorting method described in any of the foregoing embodiments.

[0007] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the transaction caching and sorting method described in any of the foregoing embodiments.

[0008] The method, apparatus, electronic device, and storage medium for transaction caching and sorting provided in this application modify the transaction caching and sorting method. After a user initiates a transaction event, if the transaction event is verified to be legitimate, it is added to a set of transactions to be sorted. A globally trusted timestamp for the transaction is determined based on a preset number of timestamps corresponding to a threshold number of transactions in the set of transactions to be sorted. A trusted linked list is then generated sequentially based on this globally trusted timestamp. Since the order of the transaction events in the trusted linked list is determined by a preset number of nodes in the blockchain system, even if malicious nodes exist in the blockchain system, the number of nodes corresponding to the globally trusted timestamps is greater than the number of malicious nodes, thus not affecting the overall transaction sorting of the system. This avoids censorship attacks on transactions and improves transaction stability and security. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0010] Figure 1 A flowchart illustrating a transaction caching and sorting method provided in this application embodiment; Figure 2 A schematic diagram illustrating a specific transaction caching and sorting method provided in an embodiment of this application; Figure 3This is a schematic diagram of a preset-order process provided in an embodiment of this application; Figure 4 A structural diagram of a transaction caching and sorting apparatus provided in an embodiment of this application; Figure 5 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0012] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0013] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0014] First, let me introduce the terms used in this application: (1) Blockchain: A distributed ledger technology based on the principle of distributed fault tolerance, which stores log data (i.e. block data) through a chain structure, uses a consensus algorithm to determine the finally committed block data, and these block data are finally modified by smart contracts composed of automated scripts. It is a new distributed infrastructure and computing paradigm.

[0015] (2) Trading pool: A transaction buffering technology serves as a temporary storage location for transactions within a blockchain platform, enabling local ordering and verification of transactions.

[0016] In existing technologies, such as Ethereum's transaction pool, the transaction pool acts as a transaction buffer for blockchain nodes, performing tasks such as caching, verification, sharing, and sorting of transactions before packaging them into blocks. When a node receives a transaction signed by a user, it first verifies the user's signature within the transaction pool, then shares it with other nodes through the p2p network, and finally sorts the verified transactions locally using a strategy (such as gas fees). When a node needs to package transactions, it packages a certain number of sorted transactions from the transaction pool and completes subsequent consensus and execution processes. However, existing technologies have the following drawbacks: 1. Blockchain systems are decentralized, and transactions within the transaction pool are sorted, making them vulnerable to censorship attacks.

[0017] In current blockchain platforms, the order of transactions within a block is determined by the node itself when it produces a block. Although nodes generally package transactions according to gas fee order to maximize their own profits, from the node's perspective, this means each node has the right to determine the transaction order, allowing for censorship attacks at the node level. From the user's perspective, setting high gas fees can prevent specific transactions from being submitted, thus enabling censorship attacks such as forward-running.

[0018] 2. The blockchain consensus module is not efficient in reaching consensus on all block data.

[0019] Since blockchain is an implementation of a distributed system, its consistency relies on a consensus protocol. This protocol ensures the consistency of block submission order through mutual communication. However, the purpose of consensus is to reach an agreement on the order of block transactions, regardless of the transaction content. During consensus communication, transaction content consumes a significant amount of transmission bandwidth, which is not the purpose of consensus. Therefore, including transaction content in the consensus block will severely impact consensus performance.

[0020] Based on this, embodiments of this application provide a method, apparatus, electronic device, and storage medium for transaction caching and sorting, which can solve the transaction review problem. By executing a Byzantine ordering protocol within the transaction pool, the order is determined by honest nodes, thus avoiding each node individually deciding the transaction order.

[0021] This application provides a method for transaction caching and sorting. The method is applied to nodes in a blockchain. The blockchain contains multiple nodes, and the method used in this application is applicable to any node in the blockchain. That is, each node can execute the method provided in this application.

[0022] See Figure 1 As shown in the embodiments of this application, the transaction caching and sorting method mainly includes the following steps: Step S102: In response to the transaction event initiated by the user, verify the transaction in the Byzantine sorted transaction pool and add it to the verified unsorted transaction set.

[0023] In one implementation, the Byzantine ordering transaction pool includes an unverified transaction queue, a transaction verification module, a set of transactions to be ordered, a Byzantine ordering protocol, a trusted timestamp ordering module, and a trusted linked list. The unverified transaction queue is used to temporarily cache transaction events initiated by users; the transaction verification module performs verification work before transaction ordering, such as signature and nonce verification; the set of transactions to be ordered caches all currently unordered transactions, including those sent from other nodes.

[0024] Step S104: Determine the global trusted timestamp of a transaction based on the preset timestamps corresponding to the transaction events of a preset number of nodes in the transaction set to be sorted.

[0025] Since Byzantine nodes (i.e. malicious nodes) may exist in the blockchain system, in order to prevent malicious nodes from launching censorship attacks by affecting the transaction order, the above-mentioned global trusted timestamp of a transaction can be determined by communicating with other nodes through the Byzantine ordering protocol to obtain the threshold timestamps of other nodes, and then determining the global trusted timestamp of a transaction based on the preset timestamps corresponding to the transaction events of a preset number of nodes.

[0026] Step S106: Sort the transaction events in the set of transactions to be sorted based on the global trusted timestamp of the transaction to obtain a trusted linked list, so that the consensus protocol can obtain transactions in order based on the trusted linked list and perform consensus processing.

[0027] In one implementation, a trusted timestamp ordering module in the Byzantine transaction pool can be used to sort transactions based on existing globally trusted timestamps. A trusted linked list is used to cache transactions with trusted timestamps.

[0028] The consensus protocol requires continuously retrieving transactions from the head of the trusted chain and packaging them sequentially. Before packaging, the transactions are cached and sorted within the Byzantine transaction pool. Sorting transactions using globally trusted timestamps avoids malicious sorting and censorship attacks by the master node; the transaction pool's caching function also alleviates the pressure of transaction sharing among nodes and the consensus layer.

[0029] The transaction caching and sorting method provided in this application, after a user initiates a transaction event, if the transaction event is verified to be legitimate, adds the transaction event to a set of transactions to be sorted. A globally trusted timestamp for each transaction is determined based on a preset number of timestamps corresponding to the threshold values ​​of the transactions in the set. A trusted linked list is then generated sequentially based on this globally trusted timestamp. Since the order of the transaction events in the trusted linked list is determined by a preset number of nodes in the blockchain system, even if malicious nodes exist in the blockchain system, the number of nodes corresponding to the globally trusted timestamps is greater than the number of malicious nodes. Therefore, the overall transaction sorting will not be affected, preventing censorship attacks and improving transaction stability and security.

[0030] In one implementation, before verifying transactions in the Byzantine-ordered transaction pool, the method further includes: signing the transaction event and sending a first preset timestamp to other nodes included in the blockchain.

[0031] For example, a blockchain includes nodes 1, 2, 3, ..., n. When node 1 in the blockchain receives a transaction event initiated by a user, it signs the transaction event and sends the first preset timestamp (i.e., the preset-order corresponding to node 1) to nodes 2, 3, ..., n in the blockchain.

[0032] In another implementation, node 1 in the above example may also receive a preset timestamp sent by any one of nodes 2, 3, ..., n. In this case, the above method further includes: If voting information sent by other nodes in the blockchain is obtained, the transaction event corresponding to the voting information is added to the unsorted transaction set; wherein, the voting information is generated by the node that sent the voting information based on the local timestamp corresponding to the moment of receiving the second preset timestamp after receiving the second preset timestamp sent by other nodes in the blockchain other than itself and verifying the legality of the second preset timestamp, and the voting information includes the local timestamp and signature information.

[0033] For ease of understanding, let's continue with Node 1 as an example. Upon receiving voting information from other nodes in the blockchain (let's say Node 2), Node 1 adds the corresponding transaction event to the unordered transaction set. For instance, if Node 2 receives a preset order from other nodes (Node 1, Node 3, ..., Node n), Node 2 records a local timestamp 't' and verifies the validity of the transactions within the received preset order. If the verification passes, Node 2 generates voting information containing its local timestamp and signature. Finally, Node 2 sends the vote to Node 1 and adds it to the unordered transaction set.

[0034] For ease of understanding, the two implementation methods described above can be illustrated in the same example, using the example of different nodes in the blockchain operating separately. In one implementation method, assuming the blockchain includes node 1 and node 2, after a user initiates a transaction event, the two implementation methods described above can be: Node 1 signs the transaction event and sends the first pre-set timestamp to the other nodes in the blockchain; Node 2 obtains the second preset timestamp sent by other nodes in the blockchain (such as Node 1) and records the local timestamp corresponding to the time of acquisition; verifies the validity of the second timestamp, and after the verification is successful, generates voting information, sends the voting information to Node 1, and adds it to the set of transactions to be sorted.

[0035] Furthermore, to ensure the reliability and security of transactions, after a user initiates a transaction event, the transaction event is temporarily cached in the Byzantine sorted transaction pool in response to the user's transaction event, resulting in an unverified transaction queue. The transaction events contained in the unverified transaction queue are verified before sorting, and then added to the verified unsorted transaction set. Transaction verification includes at least signature verification and encryption verification.

[0036] Furthermore, to address the issue of malicious nodes disrupting transaction ordering in blockchain systems, in an optional implementation, the aforementioned method of determining a globally trusted timestamp for a transaction based on the preset timestamps corresponding to the transaction events of a predetermined number of nodes in the transaction set to be ordered can, in specific implementation, include the following steps 1 and 2: Step 1: Verify the validity of the voting information corresponding to the transaction events in the transaction set to be sorted, and add the verified transaction events to the voting transaction set; Step 2: If the number of votes in the voting transaction set meets the preset quantity requirement, then determine the global trusted timestamp of the transaction based on the preset timestamps corresponding to the preset quantity of nodes in the voting transaction set; wherein, the preset quantity requirement is greater than the number of malicious nodes in the blockchain.

[0037] In a specific example, assuming the number of system nodes in the blockchain is 3f+1, where f is a Byzantine node (i.e., a malicious node), if the number of votes in the voting transaction set meets the preset requirement, then the globally trusted timestamp of the transaction is determined based on the preset number of timestamps corresponding to the preset number of nodes in the voting transaction set. A specific example can be found below: If the number of votes in the voting transaction set satisfies 2f+1, then the global trusted timestamp of the transaction is determined based on the preset timestamps corresponding to the 2f+1 nodes in the voting transaction set.

[0038] In one implementation, the above-mentioned determination of the global trusted timestamp of a transaction based on the preset timestamps corresponding to 2f+1 nodes in the voting transaction set can be achieved by calculating the median of the preset timestamps corresponding to 2f+1 nodes in the voting transaction set. The number 2f+1 ensures the upper and lower limits of the median.

[0039] Optionally, in practical applications, other numerical processing results (such as mean, variance, etc.) corresponding to the preset timestamps of the 2f+1 nodes in the voting transaction set can also be calculated to facilitate constraints.

[0040] Therefore, the system determines 2f+1 nodes with globally trusted timestamps for transactions, ensuring that f malicious nodes will not affect the overall system's sorting, guaranteeing the fairness of transactions, and avoiding scrutiny of transaction order.

[0041] Furthermore, based on the globally trusted timestamps of transactions, the transaction events in the set of transactions to be sorted are sorted to obtain a trusted linked list. In specific implementation, this may include the following steps A and B: Step A: If a globally trusted timestamp for a transaction is received, verify whether the transaction event corresponding to the voting transaction set is valid, and verify the correctness of the globally trusted timestamp for the transaction event. Step B: Sort the transaction events in the transaction set to be sorted according to the preset relationship of the received global trusted timestamps to obtain a trusted linked list; the preset relationship includes at least one of the following: the order of receipt time and the size of the timestamp values.

[0042] Regarding step A above, when the globally trusted timestamp of a transaction is determined by the median of the preset timestamps of a preset number of nodes that have won bets, the correctness of the globally trusted timestamp of the transaction corresponding to the transaction event is verified, that is, whether the median of the preset timestamps corresponding to the preset number of nodes is correct.

[0043] Regarding step B above, the transaction events in the transaction set to be sorted are sorted according to the preset relationship of the received global trusted timestamps. In one implementation, the transaction events can be added to the trusted linked list in ascending order of the received global trusted timestamps.

[0044] For ease of understanding, this application provides a specific implementation method, which mainly solves the problem of master nodes' "hegemony" over the order at the consensus level in the blockchain and alleviates the pressure on the consensus system through the Byzantine order transaction pool protocol.

[0045] The trading pool consists of the following parts: 1) The unverified transaction queue can use FIFO to temporarily cache transactions, mainly receiving transactions sent by users.

[0046] 2) The transaction verification module is mainly responsible for verifying transactions before they are sorted, including signature and nonce verification.

[0047] 3) The set to be sorted caches all currently unsorted transactions, including unsorted transactions sent from other nodes.

[0048] 4) The Byzantine Fault Tolerance (BFT) protocol is responsible for communicating with other nodes to determine the globally trusted timestamps of transactions. The system has 3f+1 nodes. Each node records the timestamps of the transactions it receives and sends them back to the sorting node. The trusted timestamp of each transaction is determined by the median of the 2f+1 timestamps; the number 2f+1 guarantees both the upper and lower bounds of the median.

[0049] 5) Trusted timestamp sequencing module, which is mainly responsible for sorting transactions based on existing trusted timestamps.

[0050] 6) The trusted linked list caches transactions with trusted timestamps.

[0051] For the transaction pool operation mechanism, please refer to Figure 2 As shown, the sorting and caching functions are completed within the transaction pool. Therefore, the consensus protocol only needs to continuously retrieve and package transactions from the head of the trusted chain in sequence; before packaging, the caching and sorting of transactions have already been completed within the transaction pool. The sorted transactions prevent malicious sorting and censorship attacks by the master node; the caching function of the transaction pool also alleviates the pressure of transaction sharing among nodes and the consensus layer.

[0052] The sorting process for the aforementioned transaction pool mainly includes the following steps:

[0053] The above process describes the core workflow for sorting transactions within the transaction pool. Specifically, during the sorting process, each node retrieves a transaction from the FIFO queue F (assuming node 1), signs it, and sends the preset-order to all other nodes; at this time, queues F and O are updated. If node 2 receives a preset-order from another node, it records a local timestamp t. Simultaneously, it verifies the validity of the transactions within the received preset-order. If the verification passes, node 2 generates a vote containing its own timestamp and signature information, and finally sends the vote to node 1 and adds it to set O; otherwise, it does not vote. Node 1 verifies the validity of the signature of the received vote. If valid, it adds it to set V, corresponding to the preset-order's vote set. When |V(preset-order)| = 2f + 1, it generates a trusted timestamp trust-order for the preset-order and adds it to linked list M, simultaneously sending it to all other nodes and updating set O; invalid votes are discarded. When node 2 receives a trust-order from node 1, it verifies the existence and validity of the transaction corresponding to the trust-order using set V; then it calculates the correctness of the trusted timestamp tm and the validity of V (preset-order); if both are valid, it adds the trust-order to M and updates set O. See [link to relevant documentation]. Figure 3 As shown.

[0054] For ease of understanding, Figure 3 The image only shows node 1 sending its own preset-order. In practical applications, each node can send its own preset-order and then calculate a trusted timestamp trust-order. Since the trust-order is uniquely calculated based on the median of the timestamps of 2f+1 people, the total order of the trust-order is guaranteed.

[0055] For the consensus process, transaction summaries can be obtained from the transaction pool linked list M, added to the block, and consensus can begin. Consensus can use any masternode-driven consensus protocol. Transaction verification during the consensus process can be performed through linked list M. Once consensus is complete, sets M and V are updated.

[0056] This application embodiment uses a Byzantine transaction pool for sorting, ensuring that the order of transactions is determined by at least 2f+1 nodes in the system, thus preventing f malicious nodes from affecting the overall system's sorting. This guarantees transaction fairness and avoids scrutiny of transaction order. Furthermore, during the transaction sorting process within the pool, the sorting node caches the transactions while sending them to other nodes. If sorting is successful, it proves that the node received the transactions to be sorted and sent its timestamp. Therefore, it ensures that transactions are cached, eliminating the need to send completed transaction content during the consensus process and alleviating pressure at the consensus layer.

[0057] Based on the above method embodiments, this application also provides a transaction caching and sorting apparatus, which is applied to a blockchain node. See [link to relevant documentation]. Figure 4 As shown, the device mainly includes the following parts: The caching and verification module 42 is used to respond to user-initiated transaction events, verify transactions in the Byzantine sorted transaction pool, and add them to the verified unsorted transaction set. The trusted timestamp determination module 44 is used to determine the global trusted timestamp of a transaction based on the preset timestamps corresponding to the transaction events of a preset number of nodes in the transaction set to be sorted. The sorting module 46 is used to sort the transaction events in the set of transactions to be sorted based on the global trusted timestamp of the transaction, so as to obtain a trusted linked list, so that the consensus protocol can obtain transactions in order based on the trusted linked list and perform consensus processing.

[0058] The transaction caching and sorting apparatus provided in this application, after a user initiates a transaction event, if the transaction event is verified to be legitimate, adds the transaction event to a set of transactions to be sorted. It then determines a globally trusted timestamp for each transaction based on a preset number of timestamps corresponding to a threshold number of transactions in the set, and generates a trusted linked list of transactions in sequence based on this globally trusted timestamp. Since the order of the transaction events in the trusted linked list is determined by a preset number of nodes in the blockchain system, even if malicious nodes exist in the blockchain system, the number of nodes corresponding to the globally trusted timestamps is greater than the number of malicious nodes, thus not affecting the overall transaction sorting of the system. This avoids censorship attacks on transactions and improves transaction stability and security.

[0059] In one feasible implementation, prior to transaction verification in the Byzantine-ordered transaction pool, the apparatus further includes a signature and preset timestamp sending module, used for: The transaction event is signed, and the first pre-set timestamp is sent to other nodes in the blockchain.

[0060] In one feasible implementation, the above-mentioned apparatus further includes a transaction event adding module, used to add the transaction event corresponding to the voting information to the unsorted transaction set if voting information sent by other nodes included in the blockchain is obtained; wherein, the voting information is generated by the node that sent the voting information based on the local timestamp corresponding to the time of receiving the second preset timestamp after receiving the second preset timestamp sent by other nodes in the blockchain other than itself and verifying the legality of the second preset timestamp, and the voting information includes the local timestamp and signature information.

[0061] In one feasible implementation, the aforementioned trusted timestamp determination module 44 is further configured to: The validity of the voting information corresponding to the transaction events in the transaction set to be sorted is verified, and the verified transaction events are added to the voting transaction set. If the number of votes in the voting transaction set meets the preset requirement, then the global trusted timestamp of the transaction is determined based on the preset timestamps corresponding to the preset number of nodes in the voting transaction set; wherein, the preset requirement is greater than the number of malicious nodes in the blockchain.

[0062] In one feasible implementation, the aforementioned trusted timestamp determination module 44 is further configured to: If the number of votes in the voting transaction set satisfies 2f+1, then the global trusted timestamp of the transaction is determined based on the preset timestamps corresponding to the 2f+1 nodes in the voting transaction set; where f is the number of Byzantine nodes and the number of nodes contained in the blockchain system is 3f+1.

[0063] In one feasible implementation, the sorting module 46 is further configured to: If a globally trusted timestamp of a transaction is received, verify whether the transaction event corresponding to the voting transaction set is valid, and verify the correctness of the globally trusted timestamp of the transaction corresponding to the transaction event; The transaction events in the transaction set to be sorted are sorted according to the preset relationship of the received global trusted timestamps to obtain a trusted linked list; the preset relationship includes at least one of the following: the order of receipt time and the size of the timestamp values.

[0064] In one feasible implementation, the above-mentioned caching and verification module 42 is further configured to: In response to user-initiated transaction events, the transaction events are temporarily cached in the Byzantine Ordered Transaction Pool, resulting in an unverified transaction queue. The transaction verification process is performed on the transaction events contained in the unverified transaction queue before sorting, and then added to the verified unsorted transaction set. Transaction verification includes at least signature verification and encryption verification.

[0065] The transaction caching and sorting apparatus provided in this application embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts of the transaction caching and sorting apparatus embodiment not mentioned in the previous embodiment can be referred to the corresponding content in the aforementioned transaction caching and sorting method embodiment.

[0066] This application also provides an electronic device, such as... Figure 5 The diagram shows the structure of the electronic device 100, which includes a processor 51 and a memory 50. The memory 50 stores computer-executable instructions that can be executed by the processor 51. The processor 51 executes the computer-executable instructions to implement any of the above-mentioned transaction caching and sorting methods.

[0067] exist Figure 5 In the illustrated embodiment, the electronic device further includes a bus 52 and a communication interface 53, wherein the processor 51, the communication interface 53, and the memory 50 are connected via the bus 52.

[0068] The memory 50 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 53 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 52 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 52 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0069] The processor 51 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 51 or by instructions in software form. The processor 51 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory. The processor 51 reads the information in the memory and, in conjunction with its hardware, completes the steps of the transaction caching and sorting method of the aforementioned embodiment.

[0070] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the above-described transaction caching and sorting method. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0071] The computer program products of the transaction caching and sorting method, apparatus, electronic device and storage medium provided in the embodiments of this application include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0072] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0073] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0074] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "set up," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0075] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for transaction caching and sorting, characterized in that, The method is applied to nodes in a blockchain; the method includes: In response to user-initiated transaction events, the transaction is verified in the Byzantine sorted transaction pool and added to the verified set of transactions to be sorted. Based on the preset timestamps corresponding to the transaction events of a preset number of nodes in the unsorted transaction set, a globally reliable timestamp for the transaction is determined; The transaction events in the unsorted transaction set are sorted based on the global trusted timestamp of the transaction to obtain a trusted linked list, so that the consensus protocol can obtain transactions in order based on the trusted linked list and perform consensus processing. Determining a globally trusted timestamp for a transaction based on the preset timestamps corresponding to transaction events of a preset number of nodes in the unsorted transaction set includes: verifying the legitimacy of voting information corresponding to transaction events in the unsorted transaction set, and adding verified transaction events to a voting transaction set; if the number of votes in the voting transaction set meets a preset requirement, then determining a globally trusted timestamp for a transaction based on the preset timestamps corresponding to the preset number of nodes in the voting transaction set; wherein the preset requirement is greater than the number of malicious nodes in the blockchain.

2. The transaction caching and sorting method according to claim 1, characterized in that, The method further includes the following steps prior to transaction verification in the Byzantine-ordered transaction pool: The transaction event is signed, and a first preset timestamp is sent to other nodes in the blockchain.

3. The transaction caching and sorting method according to claim 2, characterized in that, The method further includes: If voting information is obtained from other nodes in the blockchain, the transaction event corresponding to the voting information is added to the set of transactions to be sorted. The voting information is generated by the node that sent the voting information after receiving a second preset timestamp from other nodes in the blockchain (excluding itself) and verifying the legality of the second preset timestamp. The voting information includes the local timestamp and signature information.

4. The transaction caching and sorting method according to claim 1, characterized in that, If the number of votes in the voting transaction set meets the preset requirement, then a globally trusted timestamp for the transaction is determined based on the preset timestamps corresponding to the preset number of nodes in the voting transaction set, including: If the number of votes in the voting transaction set satisfies 2f+1, then the global trusted timestamp of the transaction is determined based on the preset timestamps corresponding to the 2f+1 nodes in the voting transaction set; where f is the number of Byzantine nodes and the number of nodes contained in the blockchain system is 3f+1.

5. The transaction caching and sorting method according to claim 1, characterized in that, Based on the globally trusted timestamps of the transactions, the transaction events in the unsorted transaction set are sorted to obtain a trusted linked list, including: If a globally trusted timestamp for a transaction is received, verify whether the transaction event corresponding to the voting transaction set is legitimate, and verify the correctness of the globally trusted timestamp for the transaction event. The transaction events in the unsorted transaction set are sorted according to a preset relationship of the received global trusted timestamps to obtain a trusted linked list; the preset relationship includes at least one of the following: the order of receipt time and the size of the timestamp values.

6. The transaction caching and sorting method according to claim 1, characterized in that, In response to user-initiated transaction events, the transaction is verified in the Byzantine-ordered transaction pool and added to the verified set of transactions to be ordered, including: In response to a user-initiated transaction event, the transaction event is temporarily cached in the Byzantine Ordered Transaction Pool to obtain an unverified transaction queue; The transaction events contained in the unverified transaction queue are verified before being sorted, and then added to the set of verified transactions to be sorted; the transaction verification includes at least signature verification and encryption verification.

7. A device for transaction caching and sorting, characterized in that, The device is used in a blockchain node; the device includes: The caching and verification module is used to respond to user-initiated transaction events, verify transactions in the Byzantine sorted transaction pool, and add them to the verified unsorted transaction set. The trusted timestamp determination module is used to determine the global trusted timestamp of a transaction based on the preset timestamps corresponding to the transaction events of a preset number of nodes in the unsorted transaction set. The sorting module is used to sort the transaction events in the set of transactions to be sorted based on the global trusted timestamp of the transaction, so as to obtain a trusted linked list, so that the consensus protocol can obtain transactions in order based on the trusted linked list and perform consensus processing; wherein, the trusted linked list caches transaction information including the trusted timestamp; The trusted timestamp determination module is further configured to: verify the legitimacy of the voting information corresponding to the transaction events in the transaction set to be sorted, and add the verified transaction events to the voting transaction set; if the number of votes in the voting transaction set meets the preset quantity requirement, determine the global trusted timestamp of the transaction based on the preset timestamps corresponding to the preset quantity of nodes in the voting transaction set; wherein, the preset quantity requirement is greater than the number of malicious nodes in the blockchain.

8. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the transaction caching and sorting method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the transaction caching and sorting method according to any one of claims 1 to 6.

Images