Transaction identification method and device, electronic equipment and storage medium

Abstract

The invention discloses a transaction identifier generation method and device, electronic equipment and a storage medium, and is applied to a block chain network, the block chain network comprises a plurality of nodes used for storing a target block chain, and the method comprises the following steps: in response to a transaction identifier generation request of a client for the target block chain, determining a current proposal node in the plurality of nodes; through the current proposal node, performing time synchronization processing on the local timestamp based on the timestamp of the latest block in the target block chain to obtain a synchronization timestamp, and performing transaction identifier generation processing based on the synchronization timestamp and the corresponding self-increasing sequence to obtain a transaction identifier generation result; and returning the transaction identifier generation result to the client, so that the client initiates a transaction request corresponding to the target block chain to the block chain network based on the transaction identifier generation result. According to the invention, decentralization of transaction identifier generation is realized, a single-point fault is avoided, and transparency and security of the whole block chain network are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a transaction identification generation method, device, electronic device and storage medium. Background Art

[0002] Every transaction in a blockchain network requires a corresponding transaction identifier, which uniquely identifies a transaction within the blockchain network and ensures its uniqueness. One related method for generating data identifiers uses a centralized timestamp generation service within a single application. This service uses a centralized server to generate a timestamp-based, self-incrementing identifier. However, this centralized timestamp generation service becomes a single point of failure and lacks the transparency and security of decentralization. Therefore, this method is not suitable for decentralized blockchain networks and cannot effectively ensure the uniqueness and orderliness of transactions within the network. Summary of the Invention

[0003] In order to solve the problems of the prior art, the embodiments of the present application provide a transaction identification generation method, device, electronic device and storage medium. The technical solution is as follows:

[0004] In one aspect, a transaction identifier generation method is provided, which is applied to a blockchain network, wherein the blockchain network includes multiple nodes for storing a target blockchain, the method comprising:

[0005] In response to a request from a client to generate a transaction identifier for the target blockchain, determining a current proposing node among the multiple nodes;

[0006] Performing time synchronization processing on the local timestamp of the current proposal node based on the timestamp of the latest block in the target blockchain, through the current proposal node, to obtain a synchronized timestamp; performing transaction identifier generation processing based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp, to obtain a transaction identifier generation result corresponding to the transaction identifier generation request;

[0007] The transaction identifier generation result is returned to the client, and the transaction identifier generation result is used by the client to initiate a transaction request corresponding to the target blockchain to the blockchain network.

[0008] In another aspect, a transaction identifier generation device is provided, configured in a blockchain network, the blockchain network including a plurality of nodes for storing a target blockchain, the device comprising:

[0009] an identifier generation request response module, configured to determine a current proposal node among the multiple nodes in response to a transaction identifier generation request from a client for the target blockchain;

[0010] A transaction identifier generation module is configured to synchronize the local timestamp of the current proposal node with the timestamp of the latest block in the target blockchain to obtain a synchronized timestamp; perform transaction identifier generation based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp to obtain a transaction identifier generation result corresponding to the transaction identifier generation request;

[0011] The identifier generation result returning module is used to return the transaction identifier generation result to the client, and the transaction identifier generation result is used by the client to initiate a transaction request corresponding to the target blockchain to the blockchain network.

[0012] In some exemplary embodiments, the transaction identifier generation module includes:

[0013] A blockchain time extraction module, configured to extract a timestamp from the latest block of the target blockchain to obtain a blockchain timestamp;

[0014] A timestamp comparison module, configured to compare the local timestamp of the current proposal node with the blockchain timestamp to obtain a time comparison result;

[0015] The first time synchronization module is used to obtain time information from a preset time source when the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is earlier than the time corresponding to the blockchain timestamp, and use the obtained time information as the synchronization timestamp.

[0016] In some exemplary embodiments, when the first time synchronization module obtains time information from a preset time source, it is specifically used to: when the preset time source is the target blockchain, obtain the blockchain timestamp as the time information; when the preset time source is an external time source, send a network time acquisition request to an external trusted time server, receive the network timestamp returned by the trusted time server in response to the network time acquisition request, and use the network timestamp as the time information.

[0017] In some exemplary embodiments, the transaction identifier generation module further includes:

[0018] The second time synchronization module is used to use the local timestamp as the synchronization timestamp when the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is not earlier than the time corresponding to the blockchain timestamp.

[0019] In some exemplary embodiments, the apparatus further comprises:

[0020] a transaction request response module, configured to generate transaction record data corresponding to a transaction request sent by the client based on the transaction identifier generation result, and store the transaction record data in a pending transaction pool; the transaction record data including the transaction identifier in the transaction identifier generation result;

[0021] a current block generation module, configured to select a first proposal node from the multiple nodes as the current proposal node, and generate a current block based on the transaction record data in the pending transaction pool through the current proposal node; the timestamp of the current block is obtained by adding a preset time increment to the timestamp in the transaction identifier of the target transaction record data, where the target transaction record data is the transaction record data corresponding to the transaction identifier with the largest timestamp in the pending transaction pool;

[0022] The block storage module is used to initiate a consensus process for the current block in the blockchain network through the current proposal node, and if the consensus is passed, store the current block as the latest block on the target blockchain.

[0023] In some exemplary embodiments, the transaction identifier generation request includes a pre-fetched quantity parameter, where the pre-fetched quantity parameter indicates a preset quantity for generating transaction identifiers; and the transaction identifier generation module includes:

[0024] An auto-increment code generating module, configured to generate the preset number of auto-increment codes based on the pre-fetch quantity parameter and the auto-increment sequence corresponding to the synchronization timestamp;

[0025] A timestamp code fusion module, configured to fuse the synchronization timestamp with the preset number of self-increment codes according to a preset format to obtain the preset number of transaction identifiers;

[0026] a transaction identifier packaging module, configured to package the preset number of transaction identifiers in a list format to obtain a transaction identifier generation result corresponding to the transaction identifier generation request;

[0027] The transaction identifier generation result is stored in a local cache by the client, and a transaction request corresponding to the target blockchain is initiated to the blockchain network based on the target transaction identifier extracted from the local cache; the target transaction identifier is any one of the preset number of transaction identifiers.

[0028] In some exemplary embodiments, the transaction request response module includes:

[0029] a transaction request acquisition module, configured to acquire a transaction request sent by the client based on the target transaction identifier; wherein, after extracting the target transaction identifier from the local cache, the client deletes the target transaction identifier from the local cache;

[0030] The transaction record data generating module is configured to generate transaction record data corresponding to the transaction request based on the target transaction identifier.

[0031] In some exemplary embodiments, the apparatus further includes an identifier generation request acquisition module, configured to acquire the transaction identifier generation request sent by the client in a preset cache state;

[0032] The preset cache status indicates that the number of transaction identifiers remaining in the local cache is less than a preset number threshold;

[0033] In some exemplary embodiments, the apparatus further comprises:

[0034] Lock status acquisition module, used to obtain the lock status;

[0035] an identifier generation request response module, specifically configured to: when the lock state is the first lock state, execute the step of responding to the transaction identifier generation request of the client for the target blockchain and determining the current proposal node among the multiple nodes;

[0036] a lock state adjustment module, configured to adjust the lock state to the second lock state after the identifier generation request response module executes the step of determining the current proposal node among the multiple nodes in response to the client's transaction identifier generation request for the target blockchain; and to adjust the lock state to the first lock state after the transaction identifier generation module obtains a transaction identifier generation result corresponding to the transaction identifier generation request;

[0037] The first lock state indicates unlocked, and the second lock state indicates locked.

[0038] On the other hand, an electronic device is provided, including a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the transaction identifier generation method of any of the above aspects.

[0039] On the other hand, a computer-readable storage medium is provided, in which at least one instruction or at least one program is stored. The at least one instruction or the at least one program is loaded and executed by a processor to implement the transaction identifier generation method as described in any of the above aspects.

[0040] In another aspect, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform any of the above-described transaction identifier generation methods.

[0041] In the embodiment of the present application, the blockchain network determines the current proposal node among multiple nodes by responding to the client's transaction identifier generation request for the target blockchain, and then synchronizes the local timestamp of the current proposal node based on the timestamp of the latest block in the target blockchain to obtain a synchronized timestamp, and performs transaction identifier generation processing based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp to obtain a transaction identifier generation result corresponding to the above-mentioned transaction identifier generation request, and then returns the transaction identifier generation result to the client, so that the client can initiate a transaction request to the target blockchain to the blockchain network based on the transaction identifier generation result. In the above technical solution, since the current proposal node is selected by the blockchain network based on the consensus mechanism, obtaining the transaction identifier generation result through the current proposal node can disperse the responsibility for generating the transaction identifier, realize the decentralization of transaction identifier generation, avoid single point failure, and improve the transparency and security of the entire blockchain network. The time synchronization processing of the current proposal node effectively avoids transaction identifier conflicts caused by time inconsistency, so that the generated transaction identifier has global uniqueness and incrementality in the entire blockchain network, ensuring the uniqueness and order of transactions in the blockchain network, and reducing conflicts and sorting problems. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0043] Figure 1 This is a schematic diagram of a blockchain network provided by an embodiment of the present application;

[0044] Figure 2 This is a schematic diagram of a blockchain provided by an embodiment of the present application;

[0045] Figure 3 This is a flowchart of a transaction identifier generation method provided in an embodiment of the present application;

[0046] Figure 4This is a flowchart of another transaction identifier generation method provided in an embodiment of the present application;

[0047] Figure 5 This is a flowchart of another transaction identifier generation method provided in an embodiment of the present application;

[0048] Figure 6 This is a flowchart of another transaction identifier generation method provided in an embodiment of the present application;

[0049] Figure 7 This is an example of an architecture for implementing a transaction identifier generation method provided in an embodiment of the present application;

[0050] Figure 8 This is a structural block diagram of a transaction identifier generation device provided in an embodiment of the present application;

[0051] Figure 9 This is a hardware structure block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0053] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0054] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0055] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0056] The present application embodiments involve blockchain technology, a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (to prevent counterfeiting) and generate the next block. Blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0057] See also Figure 1 The blockchain network 100 shown may include multiple nodes 101, which may refer to individual clients within the blockchain network. Each node 101 may receive input information during normal operation and maintain shared data within the blockchain network based on the received input information. To ensure information interoperability within the blockchain network, information connections may exist between each node in the blockchain network, allowing nodes to transmit information through these connections. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network obtain the input information according to a consensus algorithm and store it as data in the shared data, ensuring that the data stored on all nodes in the data sharing system is consistent.

[0058] Each node in a blockchain network has a corresponding node identifier. Furthermore, each node in a blockchain network can store the node identifiers of other nodes in the blockchain network, allowing it to subsequently broadcast generated blocks to other nodes in the blockchain network based on the node identifiers of other nodes. A node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0059] Each node 101 in the blockchain network 100 stores an identical target blockchain, which can be used to store transaction data. The target blockchain consists of multiple blocks, see Figure 2 The target blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block uses the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0060] The multiple nodes 101 in the blockchain network 100 can be servers and / or terminal devices, wherein the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms; terminal devices can include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc.

[0061] Consensus mechanisms are fundamental to the proper functioning of blockchain systems. Consensus means reaching agreement. Each node in a blockchain network stores its own distributed ledger (i.e., the blockchain). The consensus process is the process of maintaining consistency across all nodes. All or some of the nodes in a blockchain network can participate in the consensus process, which is typically based on a consensus algorithm. Each participating node executes the consensus algorithm to execute the corresponding steps. Optional consensus algorithms include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Byzantine Fault Tolerance (BFT), and Practical Byzantine Fault Tolerance (PBFT).

[0062] Typically, a blockchain requires one or more consensus rounds to reach agreement on a specific block height among participating nodes. Block height represents the number of blocks connected to the blockchain and serves as a block identifier, indicating its position within the blockchain. A consensus round typically consists of three phases, sequentially executed: the proposal phase, the pre-voting phase, and the pre-commit phase. Multiple nodes participating in the same consensus round are referred to as consensus nodes, which can be classified into two types: proposal nodes and non-proposal nodes.

[0063] Among them, a proposal node refers to a node device elected by multiple node devices participating in the consensus, which can also be called a leader node or master node. The node device serving as a proposal node is responsible for packaging the verified transactions into a new block during the proposal phase of this round of consensus process, broadcasting the new block to other node devices participating in the consensus for consensus processing, and is also responsible for consensus processing of the new block. In the embodiment of the present application, the proposal node is also responsible for generating a global self-incrementing transaction identifier. Non-proposal nodes are used to perform consensus processing on the new blocks broadcast by the proposal node.

[0064] Consensus processing consists of pre-voting and pre-committing. Pre-voting occurs during the pre-voting phase, while pre-committing occurs during the pre-committing phase. Pre-voting refers to the process of pre-voting on whether to agree to the new block to be agreed upon. If a pre-vote is approved, the block is confirmed to be added to the blockchain. Pre-committing refers to the process of pre-committing the new block to be agreed upon. If a pre-commit is approved, the block is confirmed to be added to the blockchain. During multiple rounds of consensus at the same block height, the nodes participating in the consensus process may change from round to round. This means that the nodes participating in each round may change, the proposing node may change, and the new block to be agreed upon may also change.

[0065] In the embodiment of this application, Figure 1 As shown in , the client 102 can send a transaction identifier generation request to the blockchain network 100 before initiating a transaction request corresponding to the target blockchain to the blockchain network 100, so that the blockchain network 100 generates a globally unique and incremental transaction identifier in response to the transaction identifier generation request, and returns the transaction identifier to the client 102 in the form of a transaction identifier generation result, so that the client 102 can extract the transaction identifier in the transaction identifier generation result, and initiate a transaction request corresponding to the target blockchain to the blockchain network 100 based on the transaction identifier. It can be understood that the transaction request carries the corresponding transaction identifier, so that the uniqueness and orderliness of transactions in the blockchain network can be ensured by using the transaction identifier.

[0066] The following combination Figure 3 The technical solutions of the embodiments of the present application are described in detail.

[0067] See also Figure 3 , which shows a flow chart of a transaction identification generation method provided by an embodiment of the present application, which can be applied to Figure 1 The blockchain network 100 shown. It should be noted that this specification provides method operation steps as described in the embodiments or flowcharts, but more or fewer operation steps may be included based on conventional or non-creative work. The order of steps listed in the embodiments is only one way of executing the steps among many steps, and does not represent the only execution order. When the actual system or product is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, in a parallel processor or multi-threaded processing environment). Specifically, Figure 3 As shown, the method may include:

[0068] S301, in response to a request from a client to generate a transaction identifier for a target blockchain, determining a current proposal node among a plurality of nodes.

[0069] Specifically, when a client needs to initiate a transaction request (also referred to as a transaction) for a target blockchain to a blockchain network, it may first send a transaction identifier generation request for the target blockchain to the blockchain network. This transaction identifier generation request is used to request the generation of a transaction identifier that uniquely identifies a transaction within the blockchain network. In a specific implementation, the transaction identifier generation request may include a blockchain identifier, such as a blockchain name. Upon receiving the transaction identifier generation request, the blockchain network can determine the target blockchain based on the blockchain name in the transaction identifier generation request.

[0070] Among them, the current proposal node can be the proposal node elected in the consensus process corresponding to the latest block in the target blockchain.

[0071] S303: Through the current proposal node, the local timestamp of the current proposal node is synchronized based on the timestamp of the latest block in the target blockchain to obtain a synchronized timestamp; transaction identifier generation is performed based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp to obtain a transaction identifier generation result corresponding to the transaction identifier generation request.

[0072] Specifically, the blockchain network can detect the sending event of the transaction identifier generation request through a detection node. When the detection node detects the sending event, it can execute the aforementioned step S301 to determine the current proposal node, and then send the corresponding transaction identifier generation request to the current proposal node. After receiving the transaction identifier generation request, the current proposal node can perform time synchronization processing and transaction identifier generation processing to obtain a corresponding transaction identifier generation result, which includes the generated transaction identifier. The synchronization timestamp obtained by the time synchronization processing is not less than the timestamp of the latest block in the target blockchain.

[0073] In a specific implementation, when the current proposal node generates a transaction identifier based on the synchronization timestamp and the auto-increment sequence corresponding to the synchronization timestamp, it can first determine the auto-increment code based on the auto-increment sequence corresponding to the synchronization timestamp, and then generate a transaction identifier in a preset format based on the synchronization timestamp and the auto-increment code. The preset format may include any one of a combination format, a splicing format, and a compressed coding format. Among them, the compressed coding format may use variable length coding to reduce the length of the final transaction identifier. In addition, the preset format may also retain certain extension bits or flag bits to facilitate future format changes or function expansions of the transaction identifier, thereby improving the flexibility of transaction identifier generation, and still having good adaptability even in the ever-changing blockchain network environment. The timestamp and auto-increment code in the above-mentioned generated transaction identifier are incremental while ensuring that the transaction identifier is globally unique.

[0074] It should be noted that each synchronization timestamp corresponds to an auto-increment sequence, which can start at 0. The auto-increment codes in multiple transaction identifiers containing the same synchronization timestamp all come from the auto-increment sequence associated with that synchronization timestamp. In practical applications, the auto-increment sequence can be implemented using an auto-increment digital counter, which starts at 0 and increments each time a transaction identifier is generated.

[0075] In some exemplary embodiments, Figure 4 As shown, when the current proposal node implements time synchronization processing on the local timestamp of the current proposal node based on the timestamp of the latest block in the target blockchain, it may include:

[0076] S401, extract the timestamp from the latest block of the target blockchain to obtain the blockchain timestamp.

[0077] Specifically, the current proposal node can find the latest block of the target blockchain, and then extract the timestamp from the block header of the latest block. The extracted timestamp is the blockchain timestamp, where the latest block refers to the block most recently stored on the target blockchain.

[0078] S403: Compare the local timestamp of the current proposal node with the blockchain timestamp to obtain a time comparison result.

[0079] Specifically, the current proposal node compares its current local timestamp with the above-mentioned blockchain timestamp to obtain a time comparison result. If the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is earlier than the time corresponding to the blockchain timestamp, the following step S405 can be executed; conversely, if the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is not earlier than the time corresponding to the blockchain timestamp, the following step S407 can be executed.

[0080] For example, if the current proposal node's local timestamp is 15:00 and the blockchain timestamp is 15:20, then the time corresponding to the current proposal node's local timestamp is earlier than the time corresponding to the blockchain timestamp. If the previous proposal node's local timestamp is 15:00 and the blockchain timestamp is 14:55, then the time corresponding to the current proposal node's local timestamp is not earlier than the time corresponding to the blockchain timestamp.

[0081] S405. When the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is earlier than the time corresponding to the blockchain timestamp, time information is obtained from a preset time source, and the obtained time information is used as the synchronization timestamp.

[0082] The preset time source is a preset source for obtaining a synchronization timestamp during the time synchronization process.

[0083] In some exemplary embodiments, in order to improve the flexibility of the transaction identifier generation process, continue to refer to Figure 4 , the above step S405 may include:

[0084] S4051. When the preset time source is the target blockchain, the blockchain timestamp is obtained as the time information, so that the synchronization timestamp is the blockchain timestamp obtained in the aforementioned step S401.

[0085] S4053, when the preset time source is an external time source, the current proposal node sends a network time acquisition request to an external trusted time server, receives the network timestamp returned by the trusted time server in response to the network time acquisition request, and uses the network timestamp as the time information, so that the synchronization timestamp is the network timestamp.

[0086] The trusted time server may be, for example, an NTP (Network Time Protocol) server, and reliable network time may be synchronized via the NTP server.

[0087] S407: When the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is not earlier than the time corresponding to the blockchain timestamp, use the local timestamp as the synchronization timestamp.

[0088] Continuing with the previous example, if the local timestamp of the current proposal node is 15:00 and the blockchain timestamp is 14:55, it means that the time corresponding to the local timestamp of the current proposal node is not earlier than the time corresponding to the blockchain timestamp. In this case, the local timestamp 15:00 can be used as the synchronization timestamp.

[0089] In the above implementation, the current proposal node compares the local timestamp with the blockchain timestamp and determines the synchronization timestamp used to generate the transaction identifier based on the comparison result, thereby improving the accuracy of the time information in the subsequently generated transaction identifier and effectively avoiding transaction identifier conflicts caused by time inconsistency.

[0090] S305: Return the transaction identifier generation result to the client.

[0091] The transaction identifier generation result is used by the client to initiate a transaction request corresponding to the target blockchain to the blockchain network.

[0092] Specifically, after obtaining the transaction identifier generation result, the current proposing node can return the transaction identifier generation result to the client corresponding to the transaction identifier generation request. The current proposing node can return the transaction identifier generation result to the client directly, or the current proposing node can first send the transaction identifier generation result to the detection node, which then returns the transaction identifier generation result to the client. The client can then extract the transaction identifier from the transaction identifier generation result and, based on the transaction identifier, initiate a transaction request / transaction on the corresponding target blockchain to the blockchain network. It is understood that the transaction request carries the transaction identifier.

[0093] In some exemplary embodiments, Figure 5 As shown, after step S305, the method may further include:

[0094] S501 , in response to a transaction request sent by the client based on the transaction identifier generation result, generating transaction record data corresponding to the transaction request, and storing the transaction record data in a pending transaction pool.

[0095] The transaction record data includes the transaction identifier in the transaction identifier generation result. The pending transaction pool is used to store pending transaction record data in the blockchain network.

[0096] Specifically, the client can extract the transaction identifier from the transaction identifier generation result returned by the blockchain network, generate a transaction request based on the transaction identifier, and send the transaction request to the blockchain network to request the blockchain network to perform the corresponding transaction processing and generate the corresponding transaction record data. The blockchain network generates the transaction record data based on the transaction identifier in the transaction request, thereby globally uniquely and sequentially identifying the transaction within the blockchain network.

[0097] S503: Select a first proposal node from multiple nodes in the blockchain network as the current proposal node, and generate a current block based on the transaction record data in the pending transaction pool through the current proposal node.

[0098] The timestamp of the current block is obtained by adding a preset time increment to the timestamp in the transaction identifier of the target transaction record data, and the target transaction record data is the transaction record data corresponding to the transaction identifier with the largest timestamp in the pending transaction pool.

[0099] In a specific implementation, when the conditions for generating a new block are met, the blockchain network will generate a new block based on a consensus mechanism. The conditions for generating a new block can be set based on actual needs. For example, it can be when the number of pending transaction records in the pending transaction pool reaches a preset number, or when the time interval since the last new block was generated reaches a preset duration. It is understandable that the first proposal node selected from multiple nodes in the blockchain network based on the consensus mechanism may be different from the proposal node selected when a new block was last generated. In other words, the first proposal node may be different from the current proposal node in step S301. If the first proposal node is used as the current proposal node in step S301, the node used to generate the transaction identifier can be different, thereby distributing the responsibility for generating the transaction identifier, preventing single points of failure, and improving the transparency and security of transaction identifier generation.

[0100] In an embodiment of the present application, in order to improve the orderliness of the times of each block on the target blockchain and further improve the efficiency of block search, when the current proposal node generates the current block, the timestamp in the block header of the current block is obtained by adding a preset time increment based on the timestamp in the transaction identifier of the target transaction record data, and the target transaction record data is the transaction record data corresponding to the transaction identifier with the largest timestamp in the pending transaction pool. The largest timestamp is the latest timestamp of the corresponding time, that is, the timestamp closest to the current time. The granularity of the preset time increment is consistent with the granularity of the timestamp. For example, if the granularity of the timestamp is at the millisecond level, the preset time increment is also at the millisecond level, such as 1 millisecond. In a specific implementation, the current proposal node can sort the transaction record data in the pending transaction pool in the order of the time corresponding to the timestamps from early to late based on the timestamps in the transaction identifiers corresponding to the transaction record data, and determine the transaction record data sorted last as the target transaction record data, and then obtain the timestamp from the transaction identifier corresponding to the target transaction record data, and add 1 millisecond to the obtained timestamp to use as the timestamp in the block header of the current block.

[0101] S505, initiating a consensus process for the current block in the blockchain network through the current proposal node, and when the consensus result indicates a pass, storing the current block as the latest block on the target blockchain.

[0102] Specifically, the current proposal node can broadcast the generated current block in the blockchain network, and then initiate a consensus process for the current block in the blockchain network. Multiple nodes in the blockchain network run the consensus algorithm to complete the consensus process and obtain a consensus result. If the consensus result is passed, the current block can be stored as the latest block on the target blockchain, thereby completing the addition of a new block.

[0103] In the above embodiment, when generating a new block, a preset time increment is added to the timestamp in the transaction identifier of the target transaction record data, and the target transaction record data is the transaction record data corresponding to the transaction identifier with the largest timestamp in the transaction pool to be processed, thereby ensuring the orderliness of the time of each block in the target blockchain, and the transaction identifier of the transaction record data in each block is obtained by the proposal node based on the synchronized time and the self-incrementing sequence, that is, ensuring the global uniqueness and incremental nature of the transaction identifier, and also ensuring decentralization and maintaining the security and reliability of the blockchain network.

[0104] In some exemplary embodiments, in order to improve the processing speed of the client, the client can be configured with a transaction identifier pre-fetching function. Through this transaction identifier pre-fetching function, the client can pre-request multiple transaction identifiers from the blockchain network and cache the multiple transaction identifiers returned by the blockchain network locally. When needed, they can be retrieved from the local cache. Based on this, when the client sends a transaction identifier generation request for the target blockchain to the blockchain network, it can carry a preset quantity parameter in the transaction identifier generation request. The preset quantity parameter indicates the preset quantity of transaction identifiers to be generated. Then, after the current proposal node of the blockchain network receives the transaction identifier generation request, if Figure 6 As shown, when the current proposal node performs transaction identifier generation processing based on the synchronization timestamp and the auto-increment sequence corresponding to the synchronization timestamp and obtains the transaction identifier generation result corresponding to the transaction identifier generation request, it may include:

[0105] S601 : Generate the preset number of self-increment codes based on the pre-fetch quantity parameter and the self-increment sequence corresponding to the synchronization timestamp.

[0106] Specifically, when a client enables the transaction identifier pre-fetching function, it can obtain a preset quantity parameter and then, based on the preset quantity parameter, send a transaction identifier generation request to the blockchain network for the target blockchain. The transaction identifier generation request is used to request the generation of a preset number of transaction identifiers. The preset quantity parameter can be a default value set by the client or a value pre-entered by the client user using the transaction identifier pre-fetching function interface.

[0107] After receiving the above-mentioned transaction identifier generation request, the blockchain network can send the transaction identifier generation request to the current proposal node, and then the current proposal node receives the transaction identifier generation request and obtains a preset quantity parameter from the transaction identifier generation request. After obtaining the preset quantity parameter, it generates a preset number of self-increment codes based on the pre-fetched quantity parameter and the self-increment sequence corresponding to the synchronization timestamp.

[0108] S603: Merge the synchronization timestamp with the preset number of self-increment codes according to a preset format to obtain the preset number of transaction identifiers.

[0109] The preset format may include any one of a combination format, a concatenation format, and a compression encoding format. The compression encoding format may use variable-length encoding to reduce the length of the final transaction identifier. In addition, the preset format may retain certain extension bits or flag bits to facilitate future format changes or functional expansions of the transaction identifier, thereby increasing the flexibility of transaction identifier generation and maintaining good adaptability even in the ever-changing blockchain network environment.

[0110] S605: Pack the preset number of transaction identifiers in a list format to obtain a transaction identifier generation result corresponding to the transaction identifier generation request.

[0111] It can be understood that the transaction identifier generation result includes the above-mentioned preset number of transaction identifiers, and the transaction identifier generation result can be used by the client to store in the local cache, and based on the target transaction identifier extracted from the local cache, initiate a transaction request corresponding to the target blockchain to the blockchain network, and the target transaction identifier is any transaction identifier among the preset number of transaction identifiers.

[0112] Specifically, after obtaining the transaction identifier generation result, the current proposal node can return the transaction identifier generation result to the client, so that the client can obtain a preset number of transaction identifiers and store the preset number of transaction identifiers in a list format in the local cache. The transaction identifier can then be extracted from the local cache to initiate a transaction request for the corresponding target blockchain to the blockchain network.

[0113] In the above implementation, the proposal node generates a preset number of transaction identifiers in batches, thereby reducing the pressure on the proposal node caused by high-concurrency transaction identifier generation requests, thereby achieving higher performance and scalability.

[0114] Based on this, see Figure 6 The aforementioned step S501, in response to the transaction request sent by the client based on the transaction identifier generation result, generating the transaction record data corresponding to the transaction request may include:

[0115] S607: Acquire a transaction request sent by the client based on the target transaction identifier.

[0116] After extracting the target transaction identifier from the local cache, the client deletes the target transaction identifier from the local cache.

[0117] S609: Generate transaction record data corresponding to the transaction request based on the target transaction identifier.

[0118] In some exemplary embodiments, see Figure 6 After step S607, the method may further include:

[0119] S611: Obtain the transaction identifier generation request sent by the client in a preset cache state.

[0120] The preset cache status indicates that the number of transaction identifiers remaining in the local cache is less than a preset number threshold.

[0121] Specifically, when the client turns on the transaction identifier pre-fetching function, the client stores a preset number of transaction identifiers obtained in the local cache. Each time, a transaction identifier can be extracted from the local cache to generate a corresponding transaction request and sent to the blockchain network. The client deletes the transaction identifier from the local cache after extracting a transaction identifier each time, and counts the number of transaction identifiers remaining in the local cache. When the number of remaining transaction identifiers is less than the preset number threshold, the client sends a transaction identifier generation request to the blockchain network again, and the transaction identifier generation request includes a pre-fetch quantity parameter, so that the preset number of transaction identifiers can be obtained from the blockchain network again, thereby improving the processing speed of the client while also improving the performance of the global self-incremented transaction identifier. This provides important basic support for large-scale blockchain network applications, and can also reduce the pressure on proposal nodes caused by high-concurrency transaction identifier generation requests.

[0122] In some exemplary embodiments, if an abnormal problem occurs when the blockchain network is processing a transaction identifier generation request, such as a failure of the current proposal node or a network error, the blockchain network can trigger an automatic retry or return an error message to the client, so that the client can handle the exception in a timely manner.

[0123] In some exemplary embodiments, to ensure that the proposing node does not generate duplicate or erroneous transaction identifiers due to concurrent requests, the blockchain network, in step S301, responds to the client's request to generate a transaction identifier for the target blockchain and, before determining the current proposing node among the multiple nodes, may further include:

[0124] Get the lock status;

[0125] When the lock state is the first lock state, performing the step of determining the current proposing node among the multiple nodes in response to the client's request to generate a transaction identifier for the target blockchain, and adjusting the lock state to a second lock state; the first lock state indicates unlocked, and the second lock state indicates locked;

[0126] Accordingly, after obtaining the transaction identifier generation result corresponding to the transaction identifier generation request in the aforementioned step S303, the method may further include:

[0127] The lock state is adjusted to the first lock state.

[0128] Specifically, after receiving a transaction identifier generation request from a client for the target blockchain, the blockchain network can obtain the lock state. Only when the current lock state is the first lock state indicating unlocked will the blockchain network trigger the execution of a response to the transaction identifier generation request and adjust the lock state to the second lock state indicating locked. Conversely, if the current lock state is the second lock state indicating locked, the blockchain network will not trigger the execution of a response to the transaction identifier generation request. In this case, the blockchain network can obtain the lock state at a preset time interval until the obtained lock state is the first lock state. The preset time interval can be set based on actual needs, for example, 1 second, 3 seconds, etc. When the blockchain network's proposal node obtains the transaction identifier generation result corresponding to the transaction identifier generation request, it can adjust the lock state to the first lock state indicating unlocked, and then continue to trigger the response process for the next transaction identifier generation request. This ensures that the proposal node does not generate duplicate or erroneous transaction identifiers due to concurrent requests, thereby improving the accuracy of transaction identifiers.

[0129] In some exemplary embodiments, in order to improve the response speed of the blockchain network, such as Figure 7 As shown, each node (node ​​1, node 2, node 3...) of the blockchain network can be configured with a message forwarding module, an ID generation module and a storage module, wherein the storage module is used to store the target blockchain.

[0130] The message forwarding module can be used to detect the transaction identifier generation request sent by the client, and confirm the current proposal node when the transaction identifier generation request is detected, and then forward the transaction identifier generation request to the current proposal node (such as Figure 7 Node 1 shown in ). The ID generation module is used to generate the current proposal node (such as Figure 7In the case of node 1) shown in , the local timestamp of the current proposal node is synchronized based on the timestamp of the latest block in the target blockchain to obtain a synchronized timestamp; transaction identifier generation is performed based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp to obtain a transaction identifier generation result corresponding to the transaction identifier generation request. The transaction identifier generation result can also be sent to the message forwarding module, which can then return the transaction identifier generation result to the client. The message forwarding module effectively processes and forwards the client's transaction identifier generation request and transaction identifier generation result, realizing asynchronous request and response, and improving the overall response speed of the blockchain network.

[0131] In a specific implementation, the transaction ID generation request may be sent to the message forwarding module in the form of a message, which is hereinafter referred to as a transaction ID generation request message (ID Generation Request), and its message structure may be exemplified as follows:

[0132] {

[0133] "type":"ID_GENERATION_REQUEST",

[0134] "client_id":"<client ID>",

[0135] "request_id":"<request ID>",

[0136] "timestamp":"<request timestamp>"

[0137] }

[0138] As described above, the transaction identifier generation request message may include the client ID, the request ID, and the timestamp of the request. Of course, other field information may also be included according to actual needs.

[0139] When forwarding the transaction ID generation request to the current proposal node, the message forwarding module can also forward it in the form of a message. This message is hereinafter referred to as the transaction ID generation request forwarding message (ID Generation RequestForward). Its message structure can be exemplified as follows:

[0140] {

[0141] "type":"ID_GENERATION_REQUEST_FORWARD",

[0142] "client_id":"<client ID>",

[0143] "request_id":"<request ID>",

[0144] "timestamp":"<request timestamp>",

[0145] "forwarded_by":"<forwarding node ID>"

[0146] }

[0147] As described above, compared with the transaction identifier generation request message, the transaction identifier generation request forwarding message adds a forwarding node ID field to record the requested forwarding node.

[0148] After the current proposal node obtains the transaction ID generation result based on the transaction ID generation request, it can forward the result to the forwarding node through the message forwarding module in the form of a message. This message is hereinafter referred to as the transaction ID generation response message (ID Generation Response). The message structure can be exemplified as follows:

[0149] {

[0150] "type":"ID_GENERATION_RESPONSE",

[0151] "client_id":"<client ID>",

[0152] "request_id":"<request ID>",

[0153] "generated_id":"<generated transaction ID>",

[0154] "status":"<response status>",

[0155] "timestamp":"<response timestamp>"

[0156] }

[0157] As described above, the transaction identifier generation response message may include the client ID, the request ID, the generated transaction identifier, the response status, and the response timestamp.

[0158] When the forwarding node returns the transaction ID generation result to the client, it can forward it in the form of a message. This message is hereinafter referred to as the transaction ID generation response forward message (ID Generation Response Forward). The message structure can be exemplified as follows:

[0159] {

[0160] "type":"ID_GENERATION_RESPONSE_FORWARD",

[0161] "client_id":"<client ID>",

[0162] "request_id":"<request ID>",

[0163] "generated_id":"<generated global auto-increment ID>",

[0164] "status":"<response status>",

[0165] "timestamp":"<response timestamp>",

[0166] "forwarded_by":"<forwarding node ID>"

[0167] }

[0168] As described above, compared with the transaction identifier generation response message, the transaction identifier generation response forwarding message adds a forwarding node ID field to record the forwarding node of the response.

[0169] It can be seen from the above technical solutions of the embodiment of the present application that, in the embodiment of the present application, since the current proposal node is selected by the blockchain network based on the consensus mechanism, obtaining the transaction identifier generation result through the current proposal node can disperse the responsibility for generating the transaction identifier, achieve decentralization, avoid single point failure, and improve the transparency and security of the entire blockchain network. The time synchronization processing of the current proposal node effectively avoids transaction identifier conflicts caused by time inconsistency, so that the generated transaction identifier has global uniqueness and incrementality in the entire blockchain network, ensuring the uniqueness and sequentiality of transactions in the blockchain network, and reducing conflicts and sorting problems. In addition, the client is used to pre-fetch and locally cache multiple transaction identifiers, which improves the performance of the global self-increment ID. This provides important basic support for large-scale blockchain network applications and reduces the request pressure of the proposal node to generate IDs, so as to achieve higher performance and scalability.

[0170] Corresponding to the transaction identifier generation methods provided in the aforementioned embodiments, embodiments of the present application also provide a transaction identifier generation device, which is configured in a blockchain network comprising multiple nodes for storing a target blockchain. Since the transaction identifier generation device provided in embodiments of the present application corresponds to the transaction identifier generation methods provided in the aforementioned embodiments, the implementation methods of the aforementioned transaction identifier generation methods also apply to the transaction identifier generation device provided in this embodiment and will not be described in detail in this embodiment.

[0171] See also Figure 8 , which shows a schematic diagram of the structure of a transaction identification generation device provided by an embodiment of the present application, which has the function of implementing the transaction identification generation method in the above method embodiment, and the function can be implemented by hardware or by hardware executing corresponding software. Figure 8 As shown, the transaction identifier generating device 800 may include:

[0172] an identifier generation request response module 810 for determining a current proposing node among the multiple nodes in response to a transaction identifier generation request from a client for the target blockchain;

[0173] The transaction identifier generation module 820 is configured to synchronize the local timestamp of the current proposal node with the timestamp of the latest block in the target blockchain via the current proposal node to obtain a synchronized timestamp; perform transaction identifier generation based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp to obtain a transaction identifier generation result corresponding to the transaction identifier generation request;

[0174] The identifier generation result returning module 830 is used to return the transaction identifier generation result to the client, and the transaction identifier generation result is used by the client to initiate a transaction request corresponding to the target blockchain to the blockchain network.

[0175] In some exemplary embodiments, the transaction identifier generation module 820 includes:

[0176] The blockchain time extraction module is used to extract the timestamp from the latest block of the target blockchain to obtain the blockchain timestamp;

[0177] The timestamp comparison module is used to compare the local timestamp of the current proposal node with the blockchain timestamp to obtain the time comparison result;

[0178] The first time synchronization module is used to obtain time information from a preset time source when the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is earlier than the time corresponding to the blockchain timestamp, and use the obtained time information as the synchronization timestamp.

[0179] In some exemplary embodiments, when the first time synchronization module obtains time information from a preset time source, it is specifically used to: when the preset time source is the target blockchain, obtain the blockchain timestamp as the time information; when the preset time source is an external time source, send a network time acquisition request to an external trusted time server, receive the network timestamp returned by the trusted time server in response to the network time acquisition request, and use the network timestamp as the time information.

[0180] In some exemplary embodiments, the transaction identifier generation module 820 further includes:

[0181] The second time synchronization module is configured to use the local timestamp as the synchronization timestamp if the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is not earlier than the time corresponding to the blockchain timestamp.

[0182] In some exemplary embodiments, the apparatus 800 may further include:

[0183] a transaction request response module, configured to generate transaction record data corresponding to the transaction request in response to the transaction request sent by the client based on the transaction identifier generation result, and store the transaction record data in a pending transaction pool; the transaction record data includes the transaction identifier in the transaction identifier generation result;

[0184] a current block generation module, configured to select a first proposal node from the multiple nodes as the current proposal node, and generate a current block based on the transaction record data in the pending transaction pool using the current proposal node; the timestamp of the current block is obtained by adding a preset time increment to the timestamp in the transaction identifier of the target transaction record data, where the target transaction record data is the transaction record data corresponding to the transaction identifier with the largest timestamp in the pending transaction pool;

[0185] The block storage module is used to initiate a consensus process for the current block in the blockchain network through the current proposal node, and if the consensus is passed, the current block is stored as the latest block on the target blockchain.

[0186] In some exemplary embodiments, the transaction identifier generation request includes a pre-fetched quantity parameter, where the pre-fetched quantity parameter indicates a preset quantity for generating transaction identifiers; the transaction identifier generation module 820 may include:

[0187] An auto-increment code generating module, configured to generate the preset number of auto-increment codes based on the pre-fetch quantity parameter and the auto-increment sequence corresponding to the synchronization timestamp;

[0188] A timestamp code fusion module is used to fuse the synchronization timestamp with the preset number of self-increment codes according to a preset format to obtain the preset number of transaction identifiers;

[0189] a transaction identifier packaging module, configured to package the preset number of transaction identifiers in a list format to obtain a transaction identifier generation result corresponding to the transaction identifier generation request;

[0190] The transaction identifier generation result is used by the client to store in a local cache, and based on the target transaction identifier extracted from the local cache, a transaction request corresponding to the target blockchain is initiated to the blockchain network; the target transaction identifier is any transaction identifier among the preset number of transaction identifiers.

[0191] In some exemplary embodiments, the transaction request response module may include:

[0192] a transaction request acquisition module, configured to acquire a transaction request sent by the client based on the target transaction identifier; wherein, after extracting the target transaction identifier from the local cache, the client deletes the target transaction identifier from the local cache;

[0193] The transaction record data generating module is used to generate transaction record data corresponding to the transaction request based on the target transaction identifier.

[0194] In some exemplary embodiments, the apparatus 800 may further include an identifier generation request acquisition module, configured to acquire the transaction identifier generation request sent by the client in a preset cache state;

[0195] The preset cache status indicates that the number of transaction identifiers remaining in the local cache is less than a preset number threshold;

[0196] In some exemplary embodiments, the apparatus 800 may further include:

[0197] Lock status acquisition module, used to obtain the lock status;

[0198] an identifier generation request response module, specifically configured to: when the lock state is the first lock state, execute the step of responding to the client's request for generating a transaction identifier for the target blockchain and determining a current proposing node among the multiple nodes;

[0199] A lock state adjustment module is configured to adjust the lock state to the second lock state after the identifier generation request response module executes the step of determining the current proposal node among the multiple nodes in response to the client's transaction identifier generation request for the target blockchain; and adjust the lock state to the first lock state after the transaction identifier generation module obtains a transaction identifier generation result corresponding to the transaction identifier generation request; wherein the first lock state indicates unlocked and the second lock state indicates locked.

[0200] It should be noted that the apparatus provided in the above embodiments, when implementing its functions, is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0201] An embodiment of the present application provides an electronic device, which includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement any one of the transaction identifier generation methods provided in the above method embodiments.

[0202] The memory can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, application programs required for the functions, etc.; the data storage area can store data created based on the use of the device, etc. In addition, the memory can include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory can also include a memory controller to provide the processor with access to the memory.

[0203] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal, a server or a similar computing device, that is, the above-mentioned electronic device can include a computer terminal, a server or a similar computing device. Figure 9 This is a hardware structure diagram of an electronic device that runs a transaction identifier generation method provided in an embodiment of the present application, such as Figure 9 As shown, the internal structure of the electronic device may include but is not limited to: a processor, a network interface and a memory. The processor, network interface and memory in the electronic device may be connected via a bus or other means. Figure 9 The bus connection is taken as an example.

[0204] Among them, the processor (or CPU (Central Processing Unit)) is the computing core and control core of the computer device. The network interface may optionally include a standard wired interface, a wireless interface (such as WI-FI, mobile communication interface, etc.). Memory is a memory device in the computer device, used to store programs and data. It is understandable that the memory here can be a high-speed RAM storage device or a non-volatile memory device (non-volatile memory), such as at least one disk storage device; optionally, it can also be at least one storage device located away from the aforementioned processor. The memory provides storage space, which stores the operating system of the electronic device, which may include but is not limited to: Windows system (an operating system), Linux (an operating system), Android (Android, a mobile operating system) system, IOS (a mobile operating system) system, etc., and the present invention is not limited to this; and, the storage space also stores one or more instructions suitable for being loaded and executed by the processor. These instructions can be one or more computer programs (including program code). In the embodiment of this specification, the processor loads and executes one or more instructions stored in the memory to implement the transaction identifier generation method provided by the above method embodiment.

[0205] An embodiment of the present application also provides a computer-readable storage medium, which can be set in an electronic device to store at least one instruction or at least one program related to implementing a transaction identifier generation method. The at least one instruction or the at least one program is loaded and executed by the processor to implement any one of the transaction identifier generation methods provided in the above method embodiments.

[0206] Embodiments of the present application further provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform any of the transaction identifier generation methods provided in the above method embodiments.

[0207] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0208] It should be noted that the order of the embodiments of the present application described above is for descriptive purposes only and does not represent the superiority or inferiority of the embodiments. The above description is of specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0209] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0210] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0211] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A transaction identifier generation method, characterized in that: Applied to a blockchain network, the blockchain network including a plurality of nodes for storing a target blockchain, the method comprising: In response to a request from a client to generate a transaction identifier for the target blockchain, determining a current proposing node among the multiple nodes; Performing time synchronization processing on the local timestamp of the current proposal node based on the timestamp of the latest block in the target blockchain, through the current proposal node, to obtain a synchronized timestamp; performing transaction identifier generation processing based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp, to obtain a transaction identifier generation result corresponding to the transaction identifier generation request; The transaction identifier generation result is returned to the client, and the transaction identifier generation result is used by the client to initiate a transaction request corresponding to the target blockchain to the blockchain network.

2. The method according to claim 1, characterized in that The performing time synchronization processing on the local timestamp of the current proposal node based on the timestamp of the latest block in the target blockchain to obtain a synchronized timestamp includes: Extracting a timestamp from the latest block of the target blockchain to obtain a blockchain timestamp; Compare the local timestamp of the current proposal node with the blockchain timestamp to obtain a time comparison result; When the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is earlier than the time corresponding to the blockchain timestamp, time information is obtained from a preset time source, and the obtained time information is used as the synchronization timestamp.

3. The method according to claim 2, characterized in that Acquiring time information from a preset time source includes: When the preset time source is the target blockchain, obtaining the blockchain timestamp as the time information; In the case that the preset time source is an external time source, a network time acquisition request is sent to an external trusted time server, a network timestamp returned by the trusted time server in response to the network time acquisition request is received, and the network timestamp is used as the time information.

4. The method according to claim 2, characterized in that The method further comprises: If the time comparison result indicates that the time corresponding to the local timestamp of the current proposal node is not earlier than the time corresponding to the blockchain timestamp, the local timestamp is used as the synchronization timestamp.

5. The method according to claim 1, wherein After returning the transaction identifier generation result to the client, the method further includes: In response to a transaction request sent by the client based on the transaction identifier generation result, generating transaction record data corresponding to the transaction request, and storing the transaction record data in a pending transaction pool; the transaction record data includes the transaction identifier in the transaction identifier generation result; A first proposal node is selected from the multiple nodes as the current proposal node, and a current block is generated by the current proposal node based on the transaction record data in the pending transaction pool; the timestamp of the current block is obtained by adding a preset time increment to the timestamp in the transaction identifier of the target transaction record data, where the target transaction record data is the transaction record data corresponding to the transaction identifier with the largest timestamp in the pending transaction pool; The current proposal node initiates a consensus process for the current block in the blockchain network. If the consensus is passed, the current block is stored as the latest block on the target blockchain.

6. The method according to claim 5, characterized in that The transaction identifier generation request includes a pre-fetched quantity parameter, where the pre-fetched quantity parameter indicates a preset quantity for generating transaction identifiers; and the transaction identifier generation processing based on the synchronization timestamp and the auto-increment sequence corresponding to the synchronization timestamp to obtain a transaction identifier generation result corresponding to the transaction identifier generation request includes: Generate the preset number of self-increment codes based on the pre-fetch quantity parameter and the self-increment sequence corresponding to the synchronization timestamp; Merging the synchronization timestamp with the preset number of self-increment codes according to a preset format to obtain the preset number of transaction identifiers; Packaging the preset number of transaction identifiers in a list format to obtain a transaction identifier generation result corresponding to the transaction identifier generation request; The transaction identifier generation result is stored in a local cache by the client, and a transaction request corresponding to the target blockchain is initiated to the blockchain network based on the target transaction identifier extracted from the local cache; the target transaction identifier is any one of the preset number of transaction identifiers.

7. The method according to claim 6, characterized in that The generating, in response to the transaction request sent by the client based on the transaction identifier generation result, transaction record data corresponding to the transaction request includes: Obtaining a transaction request sent by the client based on the target transaction identifier; wherein, after extracting the target transaction identifier from the local cache, the client deletes the target transaction identifier from the local cache; Transaction record data corresponding to the transaction request is generated based on the target transaction identifier.

8. The method according to claim 7, characterized in that After obtaining the transaction request sent by the client based on the target transaction identifier, the method includes: Obtaining the transaction identifier generation request sent by the client in a preset cache state; The preset cache status indicates that the number of transaction identifiers remaining in the local cache is less than a preset number threshold.

9. The method according to claim 1, characterized in that Before determining the current proposing node among the multiple nodes in response to the client's request for generating a transaction identifier for the target blockchain, the method includes: Get the lock status; When the lock state is the first lock state, performing the step of determining the current proposing node among the multiple nodes in response to the client's request to generate a transaction identifier for the target blockchain, and adjusting the lock state to a second lock state; the first lock state indicates unlocked, and the second lock state indicates locked; Accordingly, after obtaining the transaction identifier generation result corresponding to the transaction identifier generation request, the method further includes: The lock state is adjusted to the first lock state.

10. A transaction identification generating device, characterized in that: Configured in a blockchain network, the blockchain network includes a plurality of nodes for storing a target blockchain, the apparatus comprising: an identifier generation request response module, configured to determine a current proposal node among the multiple nodes in response to a transaction identifier generation request from a client for the target blockchain; A transaction identifier generation module is configured to synchronize the local timestamp of the current proposal node with the timestamp of the latest block in the target blockchain to obtain a synchronized timestamp; perform transaction identifier generation based on the synchronized timestamp and the auto-increment sequence corresponding to the synchronized timestamp to obtain a transaction identifier generation result corresponding to the transaction identifier generation request; The identifier generation result returning module is used to return the transaction identifier generation result to the client, and the transaction identifier generation result is used by the client to initiate a transaction request corresponding to the target blockchain to the blockchain network.

11. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by the processor to implement the transaction identifier generation method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the transaction identifier generation method according to any one of claims 1 to 9.

13. A computer program, characterized in that When the computer program is executed by a processor, the transaction identifier generation method according to any one of claims 1 to 9 is implemented.

Images