CN112232822B

CN112232822B - Transaction processing method, node, device and storage medium of block chain network

Info

Publication number: CN112232822B
Application number: CN202011423043.2A
Authority: CN
Inventors: 李欣
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-12-08
Filing date: 2020-12-08
Publication date: 2022-02-08
Anticipated expiration: 2040-12-08
Also published as: CN112232822A

Abstract

The application provides a transaction processing method, a device, equipment and a computer readable storage medium of a block chain network, relating to the technical field of block chains, wherein the method comprises the following steps: receiving a transaction sent by a client through an organization node in a block chain network; if the transaction is successfully verified, sending the transaction to an endorsement node; receiving a transaction result sent by the endorsement node, and detecting the transaction result according to an endorsement strategy corresponding to the transaction; and under the condition that the transaction result meets the endorsement policy corresponding to the transaction, sending a chain-loading request to a sequencing node so that the sequencing node completes the chain loading of the transaction. By the aid of the transaction processing method of the blockchain network, further light weight of the client can be achieved, and maintenance difficulty and maintenance cost of the blockchain network are reduced.

Description

Transaction processing method, node, device and storage medium of block chain network

Technical Field

The present application relates to the field of blockchain network technologies, and in particular, to a transaction processing method, a node, a device, and a computer-readable storage medium for a blockchain network.

Background

The block chain is an encrypted and chained transaction storage structure formed by blocks, and the generation and the linkage of the blocks are realized based on a consensus algorithm among nodes. And the nodes of the block chain network sequence the transactions according to the time stamps of the transactions, so as to generate new blocks and realize the continuous growth of the block chain.

In the solution provided by the related art, the client must maintain network interworking with all endorsement nodes participating in endorsement to complete the acquisition of the transaction result. Therefore, the blockchain network in the related art has a complex network topology, and the maintenance difficulty and the maintenance cost are relatively high.

Disclosure of Invention

Embodiments of the present application provide a transaction processing method, an apparatus, a device, and a computer-readable storage medium for a blockchain network, which can implement further lightweight of a client, and reduce maintenance difficulty and maintenance cost of the blockchain network.

The technical scheme of the embodiment of the application is realized as follows: receiving a transaction sent by a client through an organization node in a block chain network; under the condition that the transaction verification is successful, the transaction is sent to the endorsement node; receiving a transaction result sent by the endorsement node, and detecting the transaction result according to an endorsement strategy corresponding to the transaction; and under the condition that the transaction result meets the endorsement policy corresponding to the transaction, sending an uplink request to the sequencing node so that the sequencing node finishes the uplink transaction.

In some embodiments of the present application, the method further comprises: under the condition that the transaction result does not meet the endorsement strategy corresponding to the transaction, generating a rollback sub-transaction corresponding to the sub-transaction; processing returns to the rolling transaction.

In some embodiments of the present application, the method further comprises: generating an execution result event according to the detection result; and sending the execution result event to the client.

In some embodiments of the present application, the method further comprises: under the condition that the transaction verification is successful, sending an acceptance event to the client; an acceptance event is used to characterize that the transaction has been successfully verified by the blockchain network and awaits processing.

In some embodiments of the present application, said sending executable transactions to the endorsement node via an executable transaction queue comprises: acquiring the historical distribution condition of at least one optional endorsement node in the endorsement node set; determining an endorsement node in the at least one selectable endorsement node according to the historical allocation condition of the at least one selectable endorsement node; the executable transaction is sent to the endorsement node.

In some embodiments of the present application, the determining an endorsement node among the at least one optional endorsement node according to the historical allocation of the at least one optional endorsement node comprises: determining the distribution sequence, the historical endorsement node of the last distributed transaction and the distribution condition of the historical endorsement node according to the historical distribution condition; and determining the endorsement node in at least one selectable endorsement node according to the preset rotation frequency, the distribution sequence and the distribution condition of the historical endorsement nodes.

An embodiment of the present application provides a node of a blockchain network, including:

the first receiving module is used for receiving the transaction sent by the client through an organization node in the block chain network;

the first sending module is used for sending the transaction to the endorsement node under the condition that the transaction is successfully verified;

the second receiving module is used for receiving the transaction result sent by the endorsement node and detecting the transaction result according to an endorsement strategy corresponding to the transaction;

and the second sending module is used for sending an uplink request to the sequencing node under the condition that the transaction result meets the endorsement policy corresponding to the transaction so as to enable the sequencing node to complete the uplink transaction.

An embodiment of the present application provides a transaction processing device for a blockchain network, including:

a memory for storing executable instructions;

and the processor is used for realizing the transaction processing method of the blockchain network provided by the embodiment of the application when the executable instructions stored in the memory are executed.

The embodiment of the present application provides a computer-readable storage medium, which stores executable instructions for causing a processor to implement the transaction processing method of the blockchain network provided in the embodiment of the present application when the processor executes the executable instructions.

The embodiment of the application has the following beneficial effects:

according to the embodiment of the application, the organization node in the block chain network receives the transaction sent by the client, and the consensus control step of the client in the transaction process in the related technology is transferred to the organization node of the organization where the client is located. Therefore, the client can be further lightened, namely the client does not need to know an endorsement strategy and the structure of a block chain network, so that the problem of knowledge diffusion does not exist; the client is only communicated with the organization nodes in the organization, network links are simplified, maintenance difficulty and maintenance cost of the block chain network are reduced, and safety of the block chain network is easily guaranteed.

Drawings

Fig. 1A is an alternative structural diagram of an application system of a blockchain network according to an embodiment of the present invention;

fig. 1B is a schematic diagram of an application architecture of a blockchain network according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of a node of a blockchain network according to an embodiment of the present disclosure;

fig. 3 is an alternative flow chart of a transaction processing method of a blockchain network according to an embodiment of the present disclosure;

fig. 4 is an alternative flow chart of a transaction processing method of a blockchain network according to an embodiment of the present disclosure;

fig. 5 is an alternative flow chart of a transaction processing method of a blockchain network according to an embodiment of the present disclosure;

fig. 6 is an alternative flow chart of a transaction processing method of a blockchain network according to an embodiment of the present disclosure;

fig. 7 is an alternative flowchart of a transaction processing method of a blockchain network according to an embodiment of the present disclosure;

fig. 8 is an alternative flowchart of a transaction processing method of a blockchain network according to an embodiment of the present disclosure;

FIG. 9 is a schematic diagram of an alternative network structure of a federated link network provided by an embodiment of the present application;

fig. 10 is an alternative flowchart of a transaction processing method of a blockchain network according to an embodiment of the present disclosure.

Detailed Description

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the attached drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

In the following description, the terms "first \ second \ third" are used merely for distinguishing similar objects and do not represent specific ordering for the objects, and it is understood that "first \ second \ third" may be interchanged with specific order or sequence where permitted so that the embodiments of the present application described in the present embodiment can be implemented in an order other than that shown or described in the present embodiment.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.

(1) A transaction Proposal (promusal) is a request for executing a smart contract invocation (hereinafter simply referred to as executing a transaction) included in a transaction, including an identification of a channel that receives the transaction, an identification of a smart contract that needs to be invoked in the channel, and parameter information that needs to be passed to the invoked smart contract.

(2) A Transaction, also referred to as a Transaction request, is equivalent to the computer term Transaction (Transaction), which includes the operations that need to be committed to the blockchain network for execution, and the corresponding Transaction results. Rather than simply referring to transactions in the business context, embodiments of the present invention follow this convention in view of the convention colloquially employed in blockchain technology for the term "transaction".

For example, the transactions may include a Deploy (Deploy) transaction for deploying smart contracts into nodes of the blockchain network and ready to be invoked and a call (Invoke) transaction; the Invoke (Invoke) transaction is used to perform a query operation (i.e., a read operation) or an update operation (i.e., a write operation, including additions, deletions, and modifications) on the state database in the ledger.

(3) A Block chain (Blockchain) is a storage structure for encrypted, chained transactions formed from blocks (blocks). The header of each block can comprise the hash values of all transactions in the block and also comprises the hash values of all transactions in the previous block, so that the falsification and forgery prevention of the transactions in the block are realized on the basis of the hash values; newly generated transactions, after being filled into the tiles and passing through the consensus of nodes in the blockchain network, are appended to the end of the blockchain to form a chain growth.

(4) A Blockchain Network (Blockchain Network) incorporates new blocks into a set of nodes of a Blockchain in a consensus manner.

(5) Ledger (legger) is a general term for a block chain (also called Ledger data) and a state database synchronized with the block chain. Wherein, the blockchain records the transaction in the form of a file in a file system; the state database records the transactions in the blockchain in the form of different types of Key (Key) Value pairs for supporting fast query of the transactions in the blockchain.

(6) Intelligent Contracts (Smart Contracts), also known as chain codes (chaincodes) or application codes, carry business logic that performs transactions, deployed in nodes of a blockchain network, running in an isolated execution environment (e.g., container or virtual machine).

(7) Consensus (Consensus), a process in a blockchain network, is used to agree on a transaction in a block between the nodes involved, the agreed block to be appended to the end of the blockchain. Mechanisms to achieve consensus include Proof of workload (PoW, Proof of Work), Proof of rights and interests (PoS, Proof of stamp), Proof of equity authority (DPoS, relieved Proof of stamp), Proof of Elapsed Time (PoET, Proof of Elapsed Time), and the like.

(8) Members (members), also called business entities, represent a specific entity identity (e.g., companies, enterprises, social groups, etc.), have their own root certificates in a blockchain network, and a node in a blockchain belongs to a Member, which may have multiple nodes in the same channel.

(9) Organization (Organization), a domain formed by a subset of some members (a subset of all members in an access blockchain network) for implementing a particular service (without all members participating).

(10) The system comprises a Channel (Channel), a private isolation environment provided for the nodes of members in an organization in a block chain network, intelligent contracts and accounts in the Channel are only visible for the nodes of the members joining the Channel, the same node can join a plurality of channels, and one account is maintained corresponding to each Channel.

(11) Federation chain: also called federation blockchain, is a form of blockchain networks; only for members of a specific group and limited third parties, a plurality of preselected nodes are internally designated as billers, and the generation of each block is jointly determined by all the preselected nodes.

(12) HyperLegger Fabric: a platform providing a distributed ledger solution; the system is supported by a modular framework and has excellent confidentiality, scalability, flexibility and expandability; may be used to deploy enterprise-level blockchains with a full review mechanism as well as an open source architecture.

(13) Endorsement (Endorsed): in a blockchain network, a node (endorsement node) which undertakes the endorsement task carries out transaction information verification on blockchain transactions, and declares the process and the mechanism of the transaction legality on the verified transactions.

(14) Endorsement node (Endorser): nodes that undertake an endorsement task in a blockchain network may be referred to as endorsement nodes. Wherein the endorsement node can prove its legitimacy by a valid signature of the expected information of the valid certificate.

(15) Endorsement policy (Endorsement policy): the conditions which must be satisfied for endorsement of the transaction, namely the conditions given in the endorsement policy must be satisfied to conclude successful endorsement.

For example, the endorsement policy may be set to: nodes A, B, C and F both need to endorse a transaction of type T; or, most nodes in the channel must endorse transactions of type U; or, at least 3 nodes in A, B, C, D, E, F, G must endorse transactions of type V.

(16) Sort node (Orderer): the received transactions (Tx) are sorted by FIFS (First In First served), but the order of the transactions within the block is not necessarily the same as the actual order, but is determined by the time of arrival at the sorting node. The sequenced transactions are packed into blocks according to a certain rule, and the sequencing node sends the blocks to other nodes (accounting nodes) or clients; and ensuring that the blocks distributed by all the sorting nodes are consistent.

An exemplary application of the blockchain network provided by the embodiment of the present invention is described below, referring to fig. 1A, fig. 1A is a schematic architecture diagram of an exemplary application system 100 of a blockchain network 200 provided by the embodiment of the present invention, which includes a blockchain network 200, a client 510/410, and a Certificate Authority (CA) 300.

The type of blockchain network 200 is flexible and may be, for example, any of a public chain, a private chain, or a federation chain. Taking a public link as an example, a client running in a terminal or a server of any service agent can access the block link network 200 without authorization to become a special node and become a client node; taking a federation chain as an example, after a service agent is authorized to become a member of the blockchain network 200, a corresponding client may access the blockchain network 200 to become a client node.

It is noted that there is no limit to the number of client nodes belonging to the same service entity, and one client 410 used by the service entity 400 is shown in fig. 1A and can access the blockchain network 200 to become a client node, and similarly, one client 510 used by the service entity 500 can access the blockchain network 200 to become a client node.

The operation of the client node on the blockchain network 200 mainly includes two types of ledger inquiry and ledger update. For ledger query, a client node initiates a transaction proposal to the blockchain network 200, the transaction proposal comprises intelligent contract call related to query operation, the nodes of the blockchain network 200 execute the intelligent contract call comprised in the transaction proposal to query the ledger, and the queried data is taken as a transaction result and carried in a proposal response to be returned to the client.

For updating the ledger, the client node initiates an intelligent contract call related to the update operation in the transaction proposal to the blockchain network 200, the node of the blockchain network 200 simulates and executes (i.e. the ledger cannot be changed) the intelligent contract call included in the transaction proposal to the ledger, the updated key value pair in the ledger is taken as a transaction result and is carried in the proposal response to be returned to the client, and the client further constructs the transaction proposal and the proposal response as a transaction and submits the transaction proposal and the proposal response to the blockchain network 200. In the present application, the transaction proposal sent by the client is simply referred to as transaction.

The client node is a special node different from the native node in the blockchain network 200, and the default can lack the accounting function of the native node in the blockchain network 200, so that the development difficulty of the client is reduced and the lightweight of the client is realized. The delivery of events is supported between the client and the blockchain network 200, for example, the client may monitor/subscribe to events related to intelligent contract invocation in the operation of the blockchain network 200, for example, events for generating new blocks, so as to trigger relevant business logic of itself or external systems when a specific event occurs in the blockchain network 200.

The certificate authority 300 outside the blockchain network 200 is configured to return a registration password for login in response to a registration request from a client 410/510 (hereinafter, simply referred to as a client) so as to obtain a digital certificate for announcing identity information of a member to which the client belongs. As an alternative to the Certificate Authority (CA) 300, a CA node may be provided in the blockchain network 200 to implement the above functions.

In some embodiments, the accounting nodes in the blockchain network 200 may be divided into different types according to the functions implemented by the accounting nodes outside the accounting functions, as an example of the division of the blockchain network 200 into different types shown in fig. 1A, see fig. 1B, where fig. 1B is a schematic diagram of the application architecture 100 of the blockchain network 200 provided by the embodiment of the present invention, except for the client nodes (client 410 and client 510), the nodes in the blockchain network 200 have functions of verifying transactions and accounting by default, and the nodes having functions of verifying transactions and accounting only are called accounting nodes (commit), and further include some special types of accounting nodes: an endorsement node (Endorser), a sort node (Orderer), and a master node (Leader Peer).

As an example of setting a channel in the blockchain network 200, the above-mentioned nodes in the blockchain network 200 may join channels of different organizations, such as organization 1 and organization 2 that develop different services, as shown in fig. 1B, a node belonging to a member of the organization 1/2 in the blockchain network 200 may correspondingly join a channel of the organization 1/2, and a node in each channel receives a transaction related to a service of the belonging organization and records the transaction into an account book, which is isolated for nodes outside the channel. The client 410 belongs to an organization 1, and can submit a transaction proposal to an organization node of the organization 1; client 510 belongs to organization 2 and may submit a proposal for a transaction to the organization node of awkward organization 2.

In some embodiments, a Software Development Kit (SDK) is built in the client to implement management and control on the blockchain network 200, so that native code of the client may only concern about implementing service-related logic, and omit internal operation details of the blockchain network 200, thereby reducing Development difficulty of the client.

By way of example, the SDK provides clients with a series of Application Programming Interfaces (APIs) that Interface with Remote Procedure Call (RPC) based connections between nodes of the blockchain network 200 for the clients to manage and use the functions of the blockchain network 200, including: identity management, ledger management, transaction management, smart contracts, transaction management, membership management, consensus services, smart contract services, security and cryptographic services, event handling, and the like, which will be described in detail below.

In some embodiments, from the perspective of the top level of interfacing clients with blockchain network 200, the functionality of blockchain network 200 includes the functionality of identity management, ledger management, transaction management, and smart contracts, described separately below.

(1) Identity management: after a user of a client registers and logs in an authentication center, the client acquires a digital certificate (ECert) of a member, all other operations need to be signed by a private key associated with the digital certificate, a message receiving party and the member hold the same root certificate from the authentication center, and the message receiving party firstly carries out signature and verification of the digital certificate and then carries out subsequent message processing. The node also uses a digital certificate issued by the certificate authority, for example, when a member of the access area block chain network starts a system of the subordinate node and manages the subordinate node, the identity management function authenticates and authorizes the identity information of the member.

(2) Account book management: the members authorized to access the blockchain network 200 may query the ledger by various means, including querying the block according to the block number, querying the block according to the block hash, querying the block according to the transaction number, querying the transaction according to the transaction number, and obtaining the queried blockchain according to the channel name.

(3) Transaction management: the account book can only be updated by submitting a transaction, the client submits a transaction proposal through a transaction management function of the block chain network 200, and submits the transaction to the sequencing node after acquiring the endorsement of the transaction, and then the sequencing node packages the transaction to generate a block.

(4) Intelligent contract: the method realizes a Programmable Ledger (Programmable Ledger), executes transaction through intelligent contract calling, and realizes intelligent contract business logic based on a block chain. Only the intelligent contract can update the ledger.

In some embodiments, from the perspective of the blockchain network 200 interfacing with the underlying layers, the functions of the blockchain network 200 include membership management, consensus services, chain code services, security and password services, and the like, which are described separately below. (1) Member management: the identity information of the member is authenticated by a Root of Trust Certificate (Root of Trust) system and Public Key Infrastructure (PKI) to verify the digital signature of the member. And combining an authentication center or a third-party authentication center in the blockchain network to provide the registration function of the member and manage the digital certificate of the member, such as addition and revocation of the certificate. Illustratively, digital certificates are classified into a registration certificate (ECert), a transaction certificate (TCert), and a TLS certificate (TLS Cert), which are used for user identity, transaction signature, and secure Transport Layer Protocol (TLS) transmission, respectively. (2) Consensus service: the consensus mechanism is completed by 3 phases: the client submits a proposal to the endorsement node to obtain the endorsement, submits the transaction to the sequencing node for sequencing to generate a block after obtaining the endorsement, and broadcasts the block to the accounting node to verify the local account book written into the accounting node after the transaction in the block. (3) Chain code service: the realization of the intelligent contract depends on a safe execution environment, and the safe execution process and the isolation of user data are ensured. Docker can be used to manage common chain code and provide a safe sandbox environment and a mirror file warehouse. (4) Security and cryptographic services: and the basic functions of key generation, Hash operation, signature verification, encryption, decryption and the like are realized.

In some embodiments, the upper layers of the blockchain network 200 interface with clients, a standard RPC interface is provided in the client 410/510, and the SDK is packaged based on the API, so that developers can develop various service logics based on blockchains in the SDK; the client's event mechanism enables the client to receive various events of the blockchain network 200, such as when an event is received to create a new chunk, an event to execute an intelligent contract.

An exemplary structure of a node of the blockchain network implementing an embodiment of the present invention is described below, and it is understood that the hardware structure of any type of node in the blockchain network 200 may be implemented according to the hardware structure described below.

Referring to fig. 2, fig. 2 is a schematic diagram illustrating a structure of a node 210 in a blockchain network 200 according to an embodiment of the present invention, where the node 210 shown in fig. 2 includes: at least one processor 2110, memory 2140, and at least one network interface 2120. The various components in node 210 are coupled together by a bus system 2130. It is understood that the bus system 2130 is used to enable communications among these components. The bus system 2130 includes a power bus, a control bus, and a status signal bus, in addition to the data bus. But for the sake of clarity the various buses are labeled in figure 2 as bus system 2130.

The Processor 2110 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc., wherein the general purpose Processor may be a microprocessor or any conventional Processor, etc.

The memory 2140 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. The memory 2140 optionally includes one or more storage devices physically located remote from the processor 2110.

The memory 2140 includes volatile memory or nonvolatile memory, and may also include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read Only Memory (ROM), and the volatile Memory may be a Random Access Memory (RAM). The memory 2140 described with embodiments of the invention is intended to comprise any suitable type of memory.

In some embodiments, the memory 2140 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 2141, including system programs for handling various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and handling hardware-based tasks;

a network communication module 2142 for reaching other computing devices via one or more (wired or wireless) network interfaces 2120, exemplary network interfaces 2120 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

in some embodiments, the nodes of the blockchain network provided by the embodiments of the present invention may be implemented in software, and fig. 2 shows a software module 2143 stored in the memory 2140, which may be software in the form of programs and plug-ins, and includes at least one of the following sub-modules: a first receiving module 21431, a first sending module 21432, a second receiving module 21433, and a second sending module 21434. These modules are logical and thus may be combined or further split according to the functionality implemented.

The functions of the respective modules will be explained below.

In this embodiment of the present application, a transaction processing method of a blockchain network provided in this embodiment of the present application will be described with a node as an execution subject.

Referring to fig. 3, fig. 3 is an alternative flowchart of a transaction processing method of a blockchain network according to an embodiment of the present application, which will be described with reference to the steps shown in fig. 3.

In step 301, the organization node receives a transaction sent by a client.

In some embodiments of the present application, the present application utilizes an organization node where the client sits in the organization to control the consensus process in the transaction process, as opposed to the related art where the consensus process in the transaction process is controlled by the client. Wherein, the organization node is any peer node in the organization where the client is located.

Taking the schematic diagram of fig. 1B as an example, for the client 410, since the client 410 belongs to the organization 1, the transaction sent by the client 410 is received by the organization node in the organization 1; accordingly, for the client 510, since the client 510 belongs to the organization 2, the transaction sent by the client 510 is received by the organization node in the organization 2.

In some embodiments of the present application, the organization node may also simultaneously serve as other functional nodes in the blockchain network, including an endorsement node, an accounting node, and the like.

In step 302, the organization node sends the transaction to the endorsement node if the transaction is verified successfully.

In some embodiments of the present application, the organization node, upon receiving the transaction, verifies the transaction. Wherein the above-mentioned verification of the transaction may be achieved by: the organization node verifies the format of the transaction to obtain a first verification result; performing repeatability verification on the transaction in the block chain network to obtain a second verification result; verifying the digital signature of the client side included in the transaction to obtain a third verification result; acquiring authority information in the block chain network, and performing authority verification on the client according to the authority information to obtain a fourth verification result; and when the first verification result, the second verification result, the third verification result and the fourth verification result are all successful, determining that the transaction is successfully verified. Through the verification of the four aspects, the tightness of the transaction verification is improved.

In some embodiments of the present application, when the organization node successfully verifies the transaction, the transaction is sent to the endorsement node, so that the endorsement node simulates to execute the transaction and obtains a transaction result corresponding to the transaction. The organizational node may also send an acceptance event to the client, where the acceptance event is used to characterize that the transaction has been successfully verified by the blockchain network and awaits processing.

In some embodiments of the present application, in the event that the organizational node fails to verify the transaction, the organizational node returns a verification failure event to the client that carries a failure code (indicating the type of error that verified the transaction failed).

In some embodiments of the present application, after the endorsement node receives the transaction, the transaction also needs to be verified, and the specific verification method is the same as the verification method of the organization node for the transaction. It should be noted that after the organization node verifies the transaction, the endorsement node may not need to verify the transaction; or the organization node does not verify the transaction, and the endorsement node verifies the transaction; alternatively, after the transaction is validated by the organization node, the endorsement node may still need to validate the transaction again.

In some embodiments of the present application, after the endorsement node verifies the transaction, if the verification is successful, the endorsement node simulates to execute the transaction, and obtains a transaction result corresponding to the transaction. The endorsement node can call an intelligent contract corresponding to the transaction according to an endorsement strategy corresponding to the transaction, and the updated key value pair in the account book is used as a transaction result; under the condition of verification failure, the endorsement node returns a verification failure event carrying a failure code (indicating the error type of verification transaction failure) to the client; the endorsement node may also send the verification failure event to an organization node, and send the verification failure event to the client through the organization node.

In some embodiments of the application, the endorsement node may sign the obtained transaction result to obtain an endorsement node signature, and the endorsement node sends the transaction result and the endorsement node signature to the organization node.

In step 303, the organization node receives the transaction result sent by the endorsement node, and detects the transaction result according to the endorsement policy corresponding to the transaction.

In some embodiments of the present application, after receiving the transaction result sent by the endorsement node, the organization node may detect the transaction result according to an endorsement policy corresponding to the transaction. And under the condition that the endorsement node also sends the endorsement node signature, the organization node verifies the endorsement node signature, and under the condition that the verification is successful, the organization node further verifies whether the endorsement node signature is collected in a set number or not and whether the transaction results are consistent or not.

In step 304, the organization node sends a chain request to the sequencing node if the transaction result satisfies the endorsement policy corresponding to the transaction.

In some embodiments of the present application, when the transaction result satisfies the endorsement policy corresponding to the transaction, if a set number of endorsement node signatures have been collected and the transaction results are all consistent, the organization node constructs the transaction, the transaction result, and the endorsement node signatures as an uplink request and sends the constructed uplink request to the sorting node. In addition, the uplink request may further include other related information, such as a channel identifier and an identifier of an intelligent contract, which is not limited in the embodiment of the present invention.

As can be seen from the foregoing exemplary implementation of fig. 3 in the embodiment of the present application, the organization node in the blockchain network receives the transaction sent by the client, and transfers the consensus control step of the client in the transaction process to the organization node of the organization where the client is located in the related art. Therefore, the client can be further lightened, namely the client does not need to know an endorsement strategy and the structure of a block chain network, so that the problem of knowledge diffusion does not exist; the client is only communicated with the organization nodes in the organization, network links are simplified, maintenance difficulty and maintenance cost of the block chain network are reduced, and safety of the block chain network is easily guaranteed.

Referring to fig. 4, fig. 4 is an alternative flowchart of a transaction processing method of a blockchain network provided in the embodiment of the present application, based on fig. 3, step 302 in fig. 3 may be updated to step 401 to step 403, which will be described in conjunction with the steps shown in fig. 4.

In step 401, in case the transaction is verified successfully, the organization node determines the transaction as an executable transaction and buffers it in the executable transaction queue.

In some embodiments of the present application, the above step 401 may be implemented by: in step 4011, a transaction type of the transaction is obtained; determining an optional transaction queue corresponding to the transaction type as an executable transaction queue in at least one optional transaction queue; the transaction is determined to be an executable transaction and buffered to an executable transaction queue.

In order to implement execution separation of different business processes, a corresponding optional transaction queue is set for each existing transaction type, a corresponding endorsement node set is set for each optional transaction queue in advance, and the transaction is directly cached into an executable transaction queue corresponding to the transaction type according to the transaction type of the transaction under the condition that the transaction is verified successfully.

In step 402, an endorsement node set corresponding to an executable transaction queue is obtained; the set of endorsement nodes comprises endorsement nodes.

In some embodiments of the application, since the executable transaction queue is preset with the corresponding endorsement node set, the endorsement node can be directly obtained in the endorsement node set, and a step of determining the endorsement node by using an endorsement policy again is omitted. Wherein the set of endorsement nodes comprises at least one endorsement node.

In step 403, the executable transaction is sent to the endorsement node via the executable transaction queue.

In some embodiments of the present application, after determining the endorsement node corresponding to the transaction, the transaction is sent to the endorsement node, and the next executable transaction is processed according to the enqueue time of each executable transaction in the executable transaction queue. For the next executable transaction, the endorsement node corresponding to the next executable transaction is directly determined in the endorsement node set corresponding to the executable transaction queue according to the method.

In some embodiments of the present application, the transaction processing method of the blockchain network provided in the present application may implement a service logic defined by the transaction before and after the step of selecting the endorsement node and before and after the step of sending the executable transaction to the endorsement node by calling a Filter (Filter) corresponding to the executable transaction, thereby controlling a consensus process in the transaction process.

As can be seen from the above exemplary implementation of fig. 4 in the embodiment of the present application, different executable transaction queues are set for each transaction type, and a corresponding endorsement node set is set for each executable transaction queue, so that in the process of allocating an endorsement node for a transaction, a step of determining an endorsement node by using an endorsement policy in the related art is omitted, and the efficiency of selecting the endorsement node is improved. In addition, different executable transaction queues are set for transactions of different transaction types, so that execution separation of corresponding transactions of different services is realized, an endorsement node set can be customized for the transaction of each transaction type, and the overall transaction processing efficiency is improved.

Referring to fig. 5, fig. 5 is an alternative flowchart of a transaction processing method of a blockchain network according to an embodiment of the present application, based on fig. 4, step 401 in fig. 4 may be updated to step 501 to step 503, which will be described with reference to the steps shown in fig. 5.

In step 501, if the transaction is verified successfully, a sub-transaction corresponding to the transaction is generated.

In some embodiments of the present application, for some complex transactions, for example, transactions that need to generate a sub-transaction, the present application generates a sub-transaction corresponding to the transaction according to a filter (filter) corresponding to the transaction when the transaction is successfully verified.

Taking the scenario of charging a commission as an example, assume that the transaction sent by the client is a transfer F0 from user a to user B. For this transaction, the organizational node would generate a sub-transaction Tx0, which sub-transaction Tx0 indicates that the facilitator user C charges user A for F1, i.e., that user A actually billed for F0+ F1.

In step 502, the sub-transaction is processed and the ul result for the sub-transaction is obtained.

In some embodiments of the present application, the organization node needs to process the sub-transaction corresponding to the transaction before processing the transaction, and the processing method of the sub-transaction may be the same as the processing method of the transaction according to the embodiment provided in fig. 3, and receive the uplink transaction result corresponding to the sub-transaction.

In step 503, if the uplink result indicates that the sub-transaction is successful, the transaction is determined to be an executable transaction and buffered in the executable transaction queue.

In some embodiments of the present application, after receiving the eu result corresponding to the sub-transaction, if the eu result indicates that the sub-transaction is successfully processed, the transaction is continuously executed, that is, the transaction is determined to be an executable transaction and buffered in an executable transaction queue.

As can be seen from the foregoing exemplary implementation of fig. 5, in the embodiment of the present application, by generating a sub-transaction corresponding to a transaction, after the sub-transaction is processed, the transaction is buffered in an executable transaction queue. Therefore, the transaction processing process under the complex scene can be realized, and the application range of the application is widened.

Referring to fig. 6, fig. 6 is an alternative flowchart of a transaction processing method of a blockchain network provided in an embodiment of the present application, based on fig. 5, step 502 in fig. 5 may be implemented by steps 601 to 602, which will be described in conjunction with the steps shown in fig. 6.

In step 601, the sub-transaction is buffered to a sub-transaction buffer queue.

In some embodiments of the present application, to enable ordered processing of sub-transactions, a sub-transaction cache queue is provided. And after the organization node generates the sub-transaction corresponding to the transaction, orderly storing the sub-transaction into the sub-transaction cache queue.

In some embodiments of the present application, for transactions of different transaction types, a different sub-transaction cache queue is set for each transaction type. After generating the corresponding sub-transaction according to the transaction, the sub-transaction may be cached in a sub-transaction cache queue corresponding to the transaction type according to the transaction type of the transaction.

In step 602, the sub-transaction is processed through the sub-transaction buffer queue to obtain the ul transaction result of the sub-transaction.

In some embodiments of the present application, the above step 602 may be implemented by:

in step 6021, at least one sub-transaction in the sub-transaction buffer queue is divided into transaction groups according to a preset grouping rule.

In some embodiments, the dividing at least one sub-transaction in the sub-transaction buffer queue into transaction groups according to a preset grouping rule may include: detecting the number of sub-transactions in the sub-transaction cache queue; and under the condition that the number of the sub-transactions reaches the preset number threshold, dividing the sub-transactions with the preset number threshold in the sub-transaction cache queue into the transaction group.

In the process that the organization node receives the transaction sent by the client, the organization node will continuously cache the sub-transactions corresponding to the transaction in the sub-transaction cache queue, that is, the number of the sub-transactions in the sub-transaction cache queue is continuously increased, and when the number of the sub-transactions reaches the preset number threshold, all the sub-transactions (or the sub-transactions with the preset number threshold) in the sub-transaction cache queue at this time are taken as a transaction group.

In some embodiments, the dividing at least one sub-transaction in the sub-transaction buffer queue into transaction groups according to a preset grouping rule may further include: acquiring the transaction time consumption of the sub-transaction cache queue; the transaction consumed time is the waiting time from the earliest caching to the sub-transaction in the sub-transaction cache queue; and under the condition that the transaction consumed time reaches the preset time threshold, dividing all the sub-transactions in the sub-transaction cache queue into the transaction group.

In the process that the organization node receives the transaction sent by the client, the organization node continuously caches the sub-transactions corresponding to the transaction in the sub-transaction cache queue, each sub-transaction in the sub-transaction cache queue corresponds to a waiting time, and the waiting time is a time interval from the time when the sub-transaction is cached in the sub-transaction queue to the current system time. Generally, the waiting time of the sub-transaction which is cached first in the sub-transaction cache queue is the longest, and the longest waiting time is determined as the transaction elapsed time. And under the condition that the transaction consumed time reaches the preset time threshold, dividing all the sub-transactions in the sub-transaction cache queue into the transaction group.

It should be noted that the transaction group may also be determined according to the preset number threshold and the preset time threshold. And if any condition is met, all the sub-transactions in the sub-transaction cache queue at the moment are divided into the transaction groups.

In step 6022, at least one sub-transaction in the transaction group is executed according to the intelligent contract corresponding to the transaction group, and a transaction group execution result of the transaction group is obtained.

In some embodiments, the executing at least one sub-transaction in the transaction group according to the intelligent contract corresponding to the transaction group to obtain the execution result of the transaction group may include: acquiring a first intelligent contract corresponding to the transaction group; executing each sub-transaction according to the first intelligent contract and obtaining an execution result of each sub-transaction; and generating the transaction group processing result according to the execution result of each sub-transaction.

And the first intelligent contract is not configured with a corresponding endorsement policy, so that the execution result of each sub-transaction is directly determined as the transaction group processing result.

In some embodiments, the executing at least one sub-transaction in the transaction group according to the intelligent contract corresponding to the transaction group to obtain the execution result of the transaction group in the transaction group may further include: acquiring a second intelligent contract corresponding to the transaction group; the second intelligent contract configures an endorsement policy; sending each sub-transaction to at least one endorsement node corresponding to the transaction group according to the second intelligent contract; receiving a simulation execution result of each sub-transaction sent by at least one endorsement node corresponding to the transaction group; and verifying the simulation execution result of each sub-transaction according to the endorsement policy of the second intelligent contract and generating a transaction group processing result.

In step 6023, the uplink request of the transaction group corresponding to the transaction group is generated according to the execution result of the transaction group.

In some embodiments of the present application, the transaction processing method of the blockchain network provided in the present application may implement the service logic defined by the transaction after the step of receiving the execution result/transaction result of the transaction group and before the uplink request is sent by calling a Filter (Filter) corresponding to the executable transaction, so as to control the consensus process in the transaction process.

In step 6024, the transaction set uplink request is sent to the sequencing node.

In step 6025, the eu result of the sub-transaction is determined according to the eu result of the transaction group sent by the sequencing node.

In some embodiments of the present application, the blockchain network comprises at least one of said organization nodes; each organization node corresponds to one sub-hotspot account, and each sub-transaction in the transaction group is used for trading with the hotspot account; the hotspot account comprises at least one of the child hotspot accounts.

For one intermediary user C, the intermediary user C may provide different types of services at the same time, that is, the transactions of different types of transactions may be represented as the transactions between any one user and the intermediary user C. In order to improve the concurrency processing efficiency, the account of the facilitator user C may be determined as a hotspot account, the hotspot account may be divided into at least one sub hotspot account, and for any organization node in the blockchain network, a corresponding sub hotspot account may be allocated to the organization node. The organization node realizes the transaction with the hotspot account by executing the transaction with the sub hotspot account, so that the processing efficiency under the concurrent transaction scene is improved.

Referring to fig. 7, fig. 7 is an alternative flowchart of a transaction processing method of a blockchain network according to an embodiment of the present application, based on fig. 5, step 303 in fig. 5 may be updated to step 701 to step 703, which will be described with reference to the steps shown in fig. 7.

In step 701, the organization node determines whether there is a transaction result that has not been returned according to the endorsement policy corresponding to the transaction.

In step 702, where there is a transaction result that has not been returned, the wait continues.

In step 703, in the case that there is no unreturned transaction result, it is determined whether the transaction result satisfies the endorsement policy corresponding to the transaction, and a detection result is generated.

In some embodiments of the present application, it is determined whether an endorsement policy corresponding to the transaction is satisfied according to the returned transaction result to generate the detection result. The detection result comprises that the transaction result meets the endorsement policy corresponding to the transaction, and the transaction result does not meet the endorsement policy corresponding to the transaction.

In some embodiments of the present application, the organization node may further generate an execution result event according to the detection result; and sending the execution result event to the client.

In some embodiments of the present application, step 704 may also be included: in step 704, generating a rollback sub-transaction corresponding to the sub-transaction if the transaction result does not satisfy the endorsement policy corresponding to the transaction; processing returns to the rolling transaction.

After generating the rollback sub-transaction of the sub-transaction, the rollback sub-transaction may be cached in the sub-transaction cache queue for implementing the rollback operation, and the sub-transaction may be executed through the sub-transaction cache queue for implementing the rollback operation.

As can be seen from the above exemplary implementation of fig. 7, in the embodiment of the present application, in the case that the transaction result corresponding to the transaction does not satisfy the endorsement policy, the rollback sub-transaction corresponding to the sub-transaction of the transaction is generated, so that the rollback processing on the sub-transaction of the chain is realized, and the flexibility of the system is improved.

Referring to fig. 8, fig. 8 is an alternative flowchart of a transaction processing method of a blockchain network provided in an embodiment of the present application, based on fig. 4, step 403 in fig. 4 may be implemented by steps 801 to 803, which will be described in conjunction with the steps shown in fig. 8.

In step 801, historical allocation of at least one optional endorsement node in the set of endorsement nodes is obtained.

In step 802, an endorsement node is determined among the at least one selectable endorsement nodes based on the historical allocation of the at least one selectable endorsement node.

In some embodiments of the present application, step 802 described above may be implemented by: in step 8021, the distribution order, the history endorsement node of the last distributed transaction, and the distribution of the history endorsement node are determined according to the history distribution. In step 8022, determining the endorsement node in the at least one selectable endorsement node according to the preset rotation frequency, the distribution sequence and the distribution condition of the historical endorsement nodes.

Wherein the allocation order is a selection order of at least one selectable endorsement node; the rotation frequency is the transaction quantity of the transactions which can be continuously distributed by one optional endorsement; the historical endorsement node is an optional endorsement node corresponding to the previous transaction; the distribution condition of the history endorsement node is the distributed transaction quantity of the history endorsement node which is continuously distributed with transactions. Determining the historical endorsement node as the endorsement node corresponding to the transaction under the condition that the distributed transaction quantity does not reach the rotation frequency; and under the condition that the number of the distributed transactions reaches the rotation frequency, selecting the next selectable endorsement node of the history endorsement nodes as the endorsement node corresponding to the transactions according to the distribution sequence.

In some embodiments of the present application, the rotation frequency may be adaptively configured according to the computing power of the endorsement node.

In step 803, the executable transaction is sent to the endorsement node.

As can be seen from the foregoing exemplary implementation of fig. 8, in the embodiment of the present application, by determining the rotation frequency of the endorsement node set, in the process of determining the endorsement node for the transaction, the selection efficiency and the selection rationality of the endorsement node are ensured. The load of each endorsement node can be balanced, and the overall endorsement efficiency in the transaction process is further improved.

Next, an exemplary application of the embodiment of the present application in a practical application scenario will be described.

Referring to fig. 9 in the related art, fig. 9 is a schematic diagram of an alternative network structure of a federation chain network according to an embodiment of the present application.

Different organizations of the alliance chain in the graph can be regarded as different organizations, each organization can be provided with a plurality of Peer nodes, the Peer nodes can be divided into a main node, an endorsement node and an accounting node according to roles, and one physical Peer node can simultaneously play the three roles. Compared with other alliance chain schemes, the Fabric blockchain network designs an order node, sequences and blocks the transactions meeting the endorsement strategy, generates a blockchain blockdata structure and broadcasts the blockchain blockdata structure to alliances.

In the related art, the consensus process for the transaction includes:

1. a Client (Client) initiates a transaction, firstly, transaction information (deal Message) is sent to a plurality of defined Endorsement nodes (Endorsers), and the Endorsement node is determined by an intelligent contract (Chaincode) of the transaction and an Endorsement Policy (Endorsement Policy) in the intelligent contract; and after the endorsement node receives the transaction information, executing the transaction to obtain an output result.

2. The client collects the information returned by each endorsement node, and enters a sorting (Ordering) stage when the endorsement strategy is met, otherwise, the transaction fails.

3. The client broadcasts the transactions passing the endorsement policy to all sequencing nodes (Orderers), and the sequencing nodes sequence all the transactions passing the endorsement policy through a consensus mechanism, so that the data of all the nodes meet the time sequence consistency.

4. The sequencing node broadcasts the sequenced transaction Block (Block) to other Peers (including endorsement nodes and non-endorsement nodes).

5. After all Peers verify the transaction block, the self-account book is updated, and the uplink is completed.

According to the consensus process in the embodiment of fig. 9, it can be seen that the consensus process of the alliance-link network is more flexible and has higher flexibility than the consensus process of the conventional block-link network, and in addition, because the client controls the consensus process: the client broadcasts the 'transaction' to the endorsement node, collects the results, checks the endorsement policy, and broadcasts the endorsement result to the ordering (order) node. The following technical effects can be achieved:

1. the client can automatically decide to send the transaction to a specific node (Peer) of a specific organization according to the transaction type or a specific rule;

2. the client can obtain more information and control right in the consensus process, and can better control the transaction property of the transaction; this makes it easier for the federation chain to integrate with the business system.

Due to the technical effects, a business system on a alliance chain platform can support various application scenarios, but the applicant finds, through research, that the following defects are caused as a client participates in too many consensus processes:

1. there is a diffusion of knowledge. The Client needs to understand the business and the endorsement strategy corresponding to the business, and also needs to be capable of reasonably selecting Peer nodes participating in endorsement; the Client needs to control the consensus process and realizes process control through codes;

2. with a more complex network topology. The Client must keep network intercommunication with all Peer nodes which can participate in endorsement; the Client must be able to maintain network interworking with all Orderer nodes; even if a reverse proxy component is introduced, the Client needs to know the domain name, the port and the like of the node network protocol;

3. cleavage of consensus process. The Client controls two important steps of endorsement result checking and transaction chaining in the process, and although the control is decoupled, additional cost is introduced, such as: A. the possibility of wasted effort: even if the endorsement strategy is met, the Client does not submit the transaction to the uplink, so that the transaction is idle, and more convenient possibility is provided for DDOS attack; B. possibility of malicious data counterfeiting: if the endorsement policy is not designed reasonably, and can be utilized by a malicious Client, false or wrong transaction data is directly submitted to an Orderer node uplink.

It can be seen that, as the client participates in excessive consensus process, the complexity of the system is increased, which not only affects the design, optimization and safety of the system architecture, but also affects the operation and maintenance of the system; in addition, the splitting of the consensus process also affects the system performance, not only the TPS (Transaction per Second) index of the system, but also especially the concurrency capability of the system; that is, the commonly-described "hot" data problem, i.e., concurrent transactions involve modifying the same "user" or "account" data. The consensus design described above does not have concurrency at the block level, i.e., multiple transactions in the same block cannot modify the same "user" or "account" data; this concurrency capability is sometimes necessary for federation chain applications. For example, several business scenarios require concurrency capabilities: the intermediate mechanism charges the procedure time of transferring accounts among the user accounts one by one, and the account for entering the procedure time needs to support certain concurrence; in batch transactions, accounting is related to the user accounts transferred in or out of a plurality of batches in a single batch.

Through research, the applicant simplifies the capability of the Client and improves the concurrent processing capability of the hot data on the basis of keeping the application flexibility according to the scene characteristics of the alliance chain.

In some embodiments of the present application, a transaction processing method for a blockchain network is provided, and referring to fig. 10, the steps shown in fig. 10 will be described.

S1001, the client sends a transaction proposal to the organization node.

In some embodiments of the present application, the client no longer controls the consensus process, but rather is a more lightweight client, sending only the transaction proposal to the organization node of the organization in which the client is located. The transaction proposal is the transaction in the above embodiment.

S1002, the organization node checks the transaction request and selects an endorsement node.

In some embodiments of the present application, the organization node takes over control of the consensus process by the client in the related art, and selects the endorsement node according to the endorsement policy corresponding to the transaction proposal. The organization node can also be used as an endorsement node, and the execution logic of each selected endorsement node is consistent.

In some embodiments of the present application, the selection of the endorsement node may be implemented by: selecting an endorsement node according to the system configuration; and automatically selecting according to an endorsement policy.

And S1003, the organization node sends an acceptance event to the client.

In some embodiments of the present application, after receiving an acceptance event sent by the organization node, the client registers an event snoop with the organization node by default.

And S1004, the organization node broadcasts the transaction proposal to the endorsement node.

In some embodiments of the present application, the organization node sends the acceptance event and the broadcast transaction to the endorsement node to the client, with the two steps separated.

And S1005, after the endorsement node verifies the transaction proposal, executing the intelligent contract corresponding to the transaction proposal, signing the generated execution result, and sending the execution result and the signature to the organization node.

And S1006, the organization node receives the execution result and checks whether the endorsement policy is met.

In some embodiments of the present application, if the endorsement policy is not satisfied and there are execution results not returned, then wait is continued.

In some embodiments of the present application, if the execution results are collected but the endorsement policy is not satisfied, an event that the endorsement policy is not satisfied is sent to the client.

S1007, the organization node broadcasts an uplink request to the sorting node.

In some embodiments of the present application, the uplink request includes an execution result generated by the endorsement node.

S1008, the organization node sends an execution result event to the client;

in some embodiments of the present application, after broadcasting, an event containing the result of the execution of the transaction is sent to the client;

s1009, the sequencing node sequences and blocks the received uplink request, generates a block record of the block chain, and broadcasts the block data to the accounting node after reaching the consensus;

and S1010, checking the block data by the accounting node, recording the block data in the account book, and simultaneously, orderly modifying the data state of the local account book one by one.

In some embodiments of the present application, if the accounting node is the node where the ue registers for event listening, the ue is sent the block uplink event.

Through the method provided by the embodiment of the application, the client does not participate in the consensus process any more, so that the defects in the related technology can be overcome, and the following advantages exist: the client does not need to know the endorsement strategy and the composition of the block chain network, so that the problem of knowledge diffusion does not exist; the client is only communicated with the Peer node appointed by the organization, so that the network link is simplified, and the implementation, operation and maintenance of the physical network are simplified. The organization node is adopted to control the control process, and an event monitoring mechanism of the client is reserved, so that the client can also obtain the execution condition of the transaction proposal. The function of the organization node is strengthened, the technical effect of the external encapsulation consensus process of the block chain network can be realized, and the technical basis of the design of service distribution, data fragmentation and the like is provided for the organization.

Compared with the consensus process in the related art, the method provided by the embodiment of the application has the advantages that the organization node completely follows the setting of the endorsement policy, and all transactions meeting the endorsement policy are linked. Compared with the scheme that the client judges whether the transaction is uplink or not by self in the related technology, the method avoids the influence of some non-blockchain system factors on the uplink of transaction data, and further can relieve the influence of an illegal client on the attack of a blockchain network. The safety of the block chain network can be ensured only by enhancing the safety construction of the nodes, the maintenance difficulty and the maintenance cost of the block chain network are reduced, and the safety of the block chain network is ensured more easily.

In some embodiments, in addition to the endorsement policy affecting the consensus process, the scheme also designs a Filter (Filter) in the whole process, wherein the Filter is used for realizing a self-defined service logic by calling the configured Filter before selecting the endorsement node, after selecting the endorsement node, before broadcasting the transaction to the endorsement node, after receiving the endorsement result and before initiating a cochain request, so as to control whether the consensus process is continued; wherein, the filters of the whole consensus process are configured according to the sequence.

In some embodiments, the method provided by the present application may support sub-transactions of transactions, for example, in a business scenario of charging a commission fee one by one, assuming that a transaction proposal sent by the client is that user a transfers F0 to user B, and the intermediary user C charges F1 for user a, that is, the actual billed amount of user a is F0+ F1. The processing procedure of the transaction proposal comprises the following steps:

a client initiates a transaction proposal T carrying request parameters to an organization node, wherein the request parameters are used for representing that a user A transfers F0 to a user B;

the organization node derives a sub-transaction Tx0 of the transaction proposal T through a Filter (Filter); this sub-transaction Tx0 is used to characterize the facilitator user C to charge F1 for A; wherein a sub-transaction is a complete transaction to be passed through consensus; but the endorsement policy of sub-transaction Tx0 need not be consistent with transaction T;

after the Tx0 agrees, the organization node initiates the agreement of the transaction proposal T; if the endorsement policy of the transaction proposal T fails, the organizational node performs a "rollback" of the sub-transaction Tx0 through Filter, i.e., performs sub-transaction Tx1, which sub-transaction Tx1 is used to characterize the return of the facilitator user C to user A F1. Wherein the endorsement policy of sub-transaction Tx1 is identical to the endorsement policy of sub-transaction Tx 0.

In some embodiments, the present application further provides an executable transaction queue of fractional transaction types; transactions of different transaction types are cached in different queues, and the transactions in the queues are read in order by the queue listener and then broadcast to the endorsement node. The transaction proposals belonging to the same executable transaction queue have the same transaction types, so that each queue can preset a corresponding endorsement node set instead of selecting one transaction by one according to endorsement configuration or endorsement strategy.

In some embodiments, if transaction proposals of the same transaction type are configured with different endorsement policies, different sub-buffer queues may be set according to the different endorsement policies.

In some embodiments, in an endorsement node set corresponding to the executable transaction queue, at least one endorsement node in the endorsement node set can be used in turn according to a preset use frequency; the frequency of use may be configured according to the computing power of the endorsement node.

For example, if the usage frequency is set to 5, it means that after 5 transactions are sent to the endorsement node, another transaction needs to be changed; assuming that there are 3 nodes available for endorsement by an organization, with numbers P0, P1, and P2, the round-robin process can be described as: the number of the broadcasting programs is 5 in the P0, 5 in the P1, 5 in the P2 and 5 in the P0, and the rotation is performed.

In some embodiments, for the executable transaction queue, it is necessary to monitor a change condition of an endorsement node state and connectivity of at least one endorsement node corresponding to the executable transaction queue, and update an endorsement node set of the executable transaction queue according to the change condition.

In some embodiments, for a transaction proposal that requires the derivation of a sub-transaction, the transaction proposal is buffered to a pending transaction queue if the transaction proposal derives a sub-transaction and the sub-transaction has not yet completed. After the sub-transaction completes the uplink, the transaction is moved from the pending transaction queue to the executable transaction queue.

In some embodiments of the present application, the organization node sends the acceptance event and the broadcast transaction to the endorsement node to the client, where the two steps are separated, that is, the organization node sends the acceptance event to the client after placing the transaction proposal in the cache queue.

In some embodiments of the present application, a batch processing method of sub-transactions is also provided. The method comprises the steps that a sub-transaction cache queue is provided, and sub-transactions derived by an organization node through a Filter do not call an intelligent contract immediately, but are cached to the sub-transaction cache queue.

Considering that sub-transactions more relate to 'hot spots' of concurrent transactions and the performance of uplink is poor one by one, batch processing of the sub-transactions is introduced, namely, a plurality of ordered sub-transactions in a queue are packaged into a 'group' to be used as one transaction, and a corresponding intelligent contract is called; executing the sub-transactions in the group sequentially one by one inside the contract; if the contract has no endorsement policy, the group is used as a trade uplink after the execution is successful.

Wherein the contract supporting the sub-transaction group configures an endorsement policy; the whole consensus process is not different from the consensus process described in the above embodiments; after the endorsement policy is satisfied, the group is used as a trade uplink. In the above description of the sub-transactions in the embodiment, a "rollback" scenario is involved, and the newly generated sub-transactions in the scenario are also buffered in the queue.

By combining the design points, various organizations can design different Peer systems according to business scenes. The following is a brief description of the design of the Peer system, taking the scenario of commission charge as an example.

Assume that a concurrent transaction scenario is that multiple transactions of the same transaction type are sent to a specific Peer node at the same time, as follows:

[ A0, A1, …, An, B0, B1, …, Bn ] are users/accounts that are different from one another;

transaction T0: a0 transfers to B0, the amount is F0;

transaction T1: a1 transfers to B1, the amount is F1;

…

and (3) transaction Tn: an transfers money to Bn, the amount is Fn;

after the Peer node receives any transaction request, the request validity is checked, and an intelligent contract (corresponding to the transaction type) and an endorsement strategy corresponding to the transaction type are checked; after that, the Peer node derives a sub-transaction from each transaction, taking T0 as an example, the business meaning corresponding to the sub-transaction Tx0 is: c charges T0 for a commission Fx0, C is the user account for which the commission is charged; the commission fees for the concurrent transactions in the above example are all charged to account number C; fx0 is the commission for transaction T0.

At this time, the following data have been buffered in the three queues provided in the embodiment of the present application:

the sub-transaction queue: [ Tx0, Tx1, … Txn ], sequence is only schematic, keeping the natural order of joining the queue;

a queue to be executed: [ T0, T1, … Tn ], sequence is only schematic, keeping the natural order of the join queue;

the executable queue is empty.

The Peer preferentially groups the elements of the sub-transaction queue according to a (configurable) number threshold; for example, if the number threshold is set to 100, the Peer groups the first 100 elements of the sub-transaction queue sequence, and executes the transaction of the group by using the intelligent contract configured by the system; namely, one intelligent contract is executed to complete one grouped transaction; if the contract does not have endorsement policy, (and substantially does not need endorsement policy), the Peer will make the group as a transacted uplink; after the uplink is finished, the transaction Tn corresponding to the grouped sub-transaction can be moved from the queue to be executed to the executable queue; at this time, 100 transactions in the executable queue are not concurrent 'hot spot' accounts, so that the transactions in the queue can be quickly broadcasted (from a preset endorsement node set according to rules) to the selected endorsement node for execution;

if the system requires more concurrency capability, besides adjusting the number threshold, each Peer can be configured with different C accounts, that is, the C accounts can be regarded as being split into [ C0, C1, … Cn ], and then each Peer node of the organization uses one of the C accounts.

When the number threshold is configured to be larger, although a larger concurrency amount can be supported, when the concurrency amount is smaller, the transaction processing time consumption is obviously increased, so a Timer (Timer) function can also be added, and a time threshold can be configured, for example, 1s indicates that when the transaction time consumption in the sub-transaction queue reaches 1s, that is, (the current time-request time) is not less than 1s, the sub-transactions are taken as a group, and the subsequent flow is executed.

As can be seen from the above exemplary implementation of the present application, the present application migrates control of the consensus process from the client to the Peer design, naturally solves the problems of knowledge diffusion and complex network topology caused by the Fabric client design, and also brings some additional effects: with the client not participating in consensus any more, the organization can design the authentication mode and management between the client and the block chain system; that is, the CA that no longer relies on the Fabric system issues certificates for use by clients; certain convenience is provided for the integration of a block chain system and a business system; the realization of the client is simplified, and the client is simpler to realize and is more beneficial to system integration and maintenance because the client does not participate in consensus and only interacts with the remaining clients and the Peer.

Continuing with the exemplary structure of the software module 2143 provided by embodiments of the present invention, in some embodiments, as shown in FIG. 2, the software module 2143 stored in the memory 2140 may include at least one of the following sub-modules: a first sending module 21431, a first receiving module 21432, a second sending module, a second receiving module 21434.

A first receiving module 21431, configured to receive, through an organization node in the blockchain network, a transaction sent by a client;

a first sending module 21432, configured to send the transaction to the endorsement node if the transaction is successfully checked;

the second receiving module 21433 is configured to receive the transaction result sent by the endorsement node, and detect the transaction result according to an endorsement policy corresponding to the transaction;

the second sending module 21434 is configured to send an uplink request to the sorting node when the transaction result satisfies an endorsement policy corresponding to the transaction, so that the sorting node completes uplink transaction.

In some embodiments of the present application, the first sending module 21432 is further configured to: determining the transaction as an executable transaction and caching the executable transaction into an executable transaction queue; acquiring an endorsement node set corresponding to an executable transaction queue; the endorsement node set comprises endorsement nodes; and sending the executable transaction to the endorsement node through the executable transaction queue.

In some embodiments of the present application, the first sending module 21432 is further configured to: acquiring a transaction type of a transaction; determining an optional transaction queue corresponding to the transaction type as an executable transaction queue in at least one optional transaction queue; the transaction is determined to be an executable transaction and buffered to an executable transaction queue.

In some embodiments of the present application, the first sending module 21432 is further configured to: generating a sub-transaction corresponding to the transaction; processing the sub-transaction and obtaining a business uplink result of the sub-transaction; if the uplink result indicates that the sub-transaction is successful, the transaction is determined to be an executable transaction and buffered in an executable transaction queue.

In some embodiments of the present application, the first sending module 21432 is further configured to: caching the sub-transaction to a sub-transaction cache queue; and processing the sub-transaction through the sub-transaction buffer queue to obtain a business uplink result of the sub-transaction.

In some embodiments of the present application, the first sending module 21432 is further configured to: dividing at least one sub-transaction in the sub-transaction cache queue into transaction groups according to a preset grouping rule; executing at least one sub-transaction in the transaction group according to the intelligent contract corresponding to the transaction group to obtain a transaction group execution result of the transaction group; generating a business group uplink request corresponding to the business group according to the business group execution result; sending a transaction set uplink request to a sequencing node; and receiving the business group uplink result sent by the sequencing node, and determining the business uplink result of the sub-business according to the business group uplink result.

In some embodiments of the present application, the first sending module 21432 is further configured to: acquiring a first intelligent contract corresponding to the transaction group; executing each sub-transaction according to the first intelligent contract and obtaining the execution result of each sub-transaction; and generating a transaction group processing result according to the execution result of each sub-transaction.

In some embodiments of the present application, the first sending module 21432 is further configured to: acquiring a second intelligent contract corresponding to the transaction group; the second intelligent contract configures an endorsement policy; sending each sub-transaction to at least one endorsement node corresponding to the transaction group according to a second intelligent contract; receiving a simulation execution result of each sub-transaction sent by at least one endorsement node corresponding to the transaction group; and verifying the simulation execution result of each sub-transaction according to the endorsement policy of the second intelligent contract and generating a transaction group processing result.

In some embodiments of the present application, the blockchain network comprises at least one organizational node; each organization node corresponds to one sub-hotspot account, and each sub-transaction in the transaction group is used for carrying out transaction with the hotspot account; the hotspot account includes at least one sub-hotspot account.

In some embodiments of the present application, the first sending module 21432 is further configured to: detecting the number of sub-transactions in a sub-transaction cache queue; and under the condition that the number of the sub-transactions reaches a preset number threshold, dividing the sub-transactions with the preset number threshold in the sub-transaction cache queue into transaction groups.

In some embodiments of the present application, the first sending module 21432 is further configured to: acquiring transaction time consumption of a sub-transaction cache queue; the transaction time consumption is the waiting time of the sub-transaction from the earliest cache to the sub-transaction cache queue; and under the condition that the transaction consumed time reaches a preset time threshold, dividing all the sub-transactions in the sub-transaction cache queue into transaction groups.

In some embodiments of the present application, the second receiving module 21433 is further configured to: judging whether unreturned transaction results exist or not according to the endorsement strategy corresponding to the transaction; continuing to wait in the presence of unreturned transaction results; under the condition that no unreturned transaction result exists, judging whether the transaction result meets an endorsement strategy corresponding to the transaction or not, and generating a detection result; the detection result comprises that the transaction result meets the endorsement strategy corresponding to the transaction and the transaction result does not meet the endorsement strategy corresponding to the transaction.

In some embodiments of the present application, the second receiving module 21433 is further configured to: under the condition that the transaction result does not meet the endorsement strategy corresponding to the transaction, generating a rollback sub-transaction corresponding to the sub-transaction; processing returns to the rolling transaction.

In some embodiments of the present application, the second sending module 21434 is further configured to: generating an execution result event according to the detection result; and sending the execution result event to the client.

In some embodiments of the present application, the first sending module 21432 is further configured to: under the condition that the transaction verification is successful, sending an acceptance event to the client; an acceptance event is used to characterize that the transaction has been successfully verified by the blockchain network and awaits processing.

In some embodiments of the present application, the first sending module 21432 is further configured to: acquiring the historical distribution condition of at least one optional endorsement node in the endorsement node set; determining an endorsement node in the at least one selectable endorsement node according to the historical allocation condition of the at least one selectable endorsement node; the executable transaction is sent to the endorsement node.

In some embodiments of the present application, the first sending module 21432 is further configured to: determining the distribution sequence, the historical endorsement node of the last distributed transaction and the distribution condition of the historical endorsement node according to the historical distribution condition; and determining the endorsement node in at least one selectable endorsement node according to the preset rotation frequency, the distribution sequence and the distribution condition of the historical endorsement nodes.

Embodiments of the present disclosure provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the transaction processing method of the blockchain network according to the embodiment of the present application.

Embodiments of the present disclosure provide a computer-readable storage medium storing executable instructions, which when executed by a processor, will cause the processor to execute a transaction processing method of a blockchain network provided by embodiments of the present disclosure, for example, the method shown in fig. 3 to 8.

In some possible implementations, the computer-readable storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some possible implementations, the executable instructions may be in the form of a program, software module, script, or code written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and they may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

In summary, the following technical effects can be achieved through the embodiments of the present application:

(1) according to the embodiment of the application, the organization node in the block chain network receives the transaction sent by the client, and the consensus control step of the client in the transaction process in the related technology is transferred to the organization node of the organization where the client is located. Therefore, the client can be further lightened, namely the client does not need to know an endorsement strategy and the structure of a block chain network, so that the problem of knowledge diffusion does not exist; the client is only communicated with the organization nodes in the organization, network links are simplified, maintenance difficulty and maintenance cost of the block chain network are reduced, and safety of the block chain network is easily guaranteed.

(2) According to the method and the device, different executable transaction queues are set for each transaction type, and the corresponding endorsement node sets are set for each executable transaction queue, so that the step of determining the endorsement nodes by using an endorsement strategy in the related technology can be omitted in the process of distributing the endorsement nodes for transactions, and the selection efficiency of the endorsement nodes is improved. In addition, different executable transaction queues are set for transactions of different transaction types, so that execution separation of corresponding transactions of different services is realized, an endorsement node set can be customized for the transaction of each transaction type, and the overall transaction processing efficiency is improved.

(3) According to the embodiment of the application, the sub-transaction corresponding to the transaction is generated, and after the sub-transaction is processed, the transaction is cached in the executable transaction queue. Therefore, the transaction processing process under the complex scene can be realized, and the application range of the application is widened.

(4) According to the method and the device, under the condition that the transaction result corresponding to the transaction does not meet the endorsement policy, the rollback sub-transaction corresponding to the sub-transaction of the transaction is generated, rollback processing of the sub-transaction of the chain is achieved, and flexibility of the system is improved.

(5) By determining the rotation frequency of the endorsement node set, the selection efficiency and the selection rationality of the endorsement nodes are ensured in the process of determining the endorsement nodes for the transaction. The load of each endorsement node can be balanced, and the overall endorsement efficiency in the transaction process is further improved.

The above description is only an example of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A transaction processing method for a blockchain network, applied to an organization node in a alliance-chain network, the method comprising:

receiving a transaction sent by a client, wherein the client and the organization node belong to the same organization in the alliance-link network;

under the condition that the transaction verification is failed, returning a verification failure event carrying a failure code to the client;

under the condition that the transaction is successfully verified, the transaction is sent to an endorsement node, so that the endorsement node simulates and executes the transaction to obtain a transaction result corresponding to the transaction;

receiving the transaction result sent by the endorsement node, and detecting the transaction result according to an endorsement strategy corresponding to the transaction;

under the condition that the transaction result does not meet the endorsement strategy corresponding to the transaction, generating a rollback sub-transaction corresponding to the sub-transaction of the transaction, and processing the rollback sub-transaction;

under the condition that the transaction result meets an endorsement policy corresponding to the transaction, sending a chain-loading request to a sequencing node so that the sequencing node completes the chain loading of the transaction;

wherein the sending the transaction to an endorsement node comprises:

under the condition that the uplink of the sub-transaction corresponding to the transaction is successful, determining the transaction as an executable transaction and caching the executable transaction into an executable transaction queue, wherein the executable transaction queue is used for sending each executable transaction to the endorsement node according to the enqueue time of each executable transaction in the executable transaction queue; obtaining historical distribution conditions of at least one optional endorsement node in an endorsement node set corresponding to the executable transaction queue, wherein the historical distribution conditions comprise distribution sequences, historical endorsement nodes of transactions distributed last time and distribution conditions of the historical endorsement nodes; determining the endorsement node in the at least one selectable endorsement node according to a preset rotation frequency and the historical allocation condition;

the method further comprises the following steps:

configuring a filter of the whole process so as to realize the business logic of the transaction customization by calling the filter and further control the consensus process in the transaction process, wherein the whole process comprises the following steps: before the endorsement node is determined, after the endorsement node is determined, before the transaction is broadcast to the endorsement node, after the transaction result is received, and before the uplink request is sent.

2. The method of claim 1, wherein sending the transaction to an endorsement node further comprises:

acquiring an endorsement node set corresponding to the executable transaction queue, wherein the endorsement node set comprises the endorsement nodes;

and sending the executable transaction to the endorsement node through the executable transaction queue.

3. The method of claim 1, wherein determining the transaction as an executable transaction and buffering the transaction into an executable transaction queue comprises:

obtaining a transaction type of the transaction;

determining an optional transaction queue corresponding to the transaction type as the executable transaction queue in at least one optional transaction queue;

determining the transaction as the executable transaction and caching the executable transaction queue.

4. The method of claim 2 or 3, wherein prior to determining the transaction as an executable transaction and buffering in an executable transaction queue, the method further comprises:

generating a sub-transaction corresponding to the transaction;

processing the sub-transaction and obtaining an uplink transaction result of the sub-transaction;

determining the transaction as an executable transaction and caching the transaction in an executable transaction queue under the condition that the uplink of the sub-transaction corresponding to the transaction is successful, wherein the method comprises the following steps:

and under the condition that the business uplink result represents that the sub business uplink is successful, determining the transaction as an executable transaction and caching the executable transaction into an executable transaction queue.

5. The method of claim 4, wherein the processing the sub-transaction and obtaining the ul result for the sub-transaction comprises:

caching the sub-transaction to a sub-transaction cache queue;

and processing the sub-transaction through the sub-transaction buffer queue to obtain an uplink transaction result of the sub-transaction.

6. The method of claim 5, wherein said processing said sub-transactions through said sub-transaction buffer queue to obtain a ul result for said sub-transactions comprises:

dividing at least one sub-transaction in the sub-transaction cache queue into transaction groups according to a preset grouping rule;

executing at least one sub-transaction in the transaction group according to an intelligent contract corresponding to the transaction group to obtain a transaction group execution result of the transaction group;

generating a business group uplink request corresponding to the business group according to the business group execution result;

sending the CRUK request to the sequencing node;

and receiving an affair group uplink result sent by the sequencing node, and determining the affair uplink result of the sub-affair according to the affair group uplink result.

7. The method of claim 6, wherein the executing at least one of the sub-transactions in the transaction group according to the intelligent contract corresponding to the transaction group to obtain the transaction group execution result of the transaction group comprises:

acquiring a first intelligent contract corresponding to the transaction group;

executing each sub-transaction according to the first intelligent contract and obtaining an execution result of each sub-transaction;

and generating the transaction group processing result according to the execution result of each sub-transaction.

8. The method of claim 6, wherein the executing at least one of the sub-transactions in the transaction group according to the intelligent contract corresponding to the transaction group to obtain the transaction group execution result of the transaction group comprises:

acquiring a second intelligent contract corresponding to the transaction group, wherein the second intelligent contract is configured with an endorsement policy;

sending each sub-transaction to at least one endorsement node corresponding to the transaction group according to the second intelligent contract;

receiving a simulation execution result of each sub-transaction sent by at least one endorsement node corresponding to the transaction group;

and verifying the simulation execution result of each sub-transaction according to the endorsement policy of the second intelligent contract and generating a transaction group processing result.

9. The method of claim 6, wherein the blockchain network comprises at least one of the organization nodes, wherein each of the organization nodes corresponds to a sub-hotspot account, and wherein each of the sub-transactions in the transaction group is configured to transact with a hotspot account, and wherein the hotspot account comprises at least one of the sub-hotspot accounts.

10. The method according to claim 6, wherein the dividing at least one of the sub-transactions in the sub-transaction buffer queue into transaction groups according to a preset grouping rule comprises:

detecting the number of sub-transactions in the sub-transaction cache queue;

and under the condition that the number of the sub-transactions reaches the preset number threshold, dividing the sub-transactions with the preset number threshold in the sub-transaction cache queue into the transaction group.

11. The method according to claim 6, wherein the dividing at least one of the sub-transactions in the sub-transaction buffer queue into transaction groups according to a preset grouping rule comprises:

acquiring transaction consumed time of the sub-transaction cache queue, wherein the transaction consumed time is the waiting time from the earliest cache to the sub-transaction in the sub-transaction cache queue;

and under the condition that the transaction consumed time reaches the preset time threshold, dividing all the sub-transactions in the sub-transaction cache queue into the transaction group.

12. The method according to claim 4, wherein the receiving the transaction result sent by the endorsement node and detecting the transaction result according to the endorsement policy corresponding to the transaction comprises:

judging whether unreturned transaction results exist according to the endorsement strategy corresponding to the transaction;

continuing to wait in the presence of unreturned transaction results;

and under the condition that an unreturned transaction result does not exist, judging whether the transaction result meets an endorsement policy corresponding to the transaction, and generating a detection result, wherein the detection result comprises that the transaction result meets the endorsement policy corresponding to the transaction and the transaction result does not meet the endorsement policy corresponding to the transaction.

13. A node of a blockchain network, the node being an organizing node in a federation chain network, the organizing node comprising:

the first receiving module is used for receiving the transaction sent by a client, wherein the client and the organization node belong to the same organization in the alliance chain network;

the first sending module is used for returning a verification failure event carrying a failure code to the client under the condition that the transaction verification fails; under the condition that the transaction is successfully verified, the transaction is sent to an endorsement node, so that the endorsement node simulates and executes the transaction to obtain a transaction result corresponding to the transaction;

the second sending module is used for generating a rollback sub-transaction corresponding to the sub-transaction of the transaction and processing the rollback sub-transaction under the condition that the transaction result does not meet the endorsement policy corresponding to the transaction; under the condition that the transaction result meets an endorsement policy corresponding to the transaction, sending a chain-loading request to a sequencing node so that the sequencing node completes the chain loading of the transaction;

the first sending module is further configured to determine, when the uplink of the sub-transaction corresponding to the transaction is successful, that the transaction is an executable transaction and buffer the executable transaction into an executable transaction queue, where the executable transaction queue is configured to send each executable transaction to the endorsement node according to an enqueue time of each executable transaction in the executable transaction queue; obtaining historical distribution conditions of at least one optional endorsement node in an endorsement node set corresponding to the executable transaction queue, wherein the historical distribution conditions comprise distribution sequences, historical endorsement nodes of transactions distributed last time and distribution conditions of the historical endorsement nodes; determining the endorsement node in the at least one selectable endorsement node according to a preset rotation frequency and the historical allocation condition;

the organization node is further configured to configure a filter of an overall process, so as to implement the business logic defined by the transaction by calling the filter, and further control a consensus process in the transaction process, where the overall process includes: before the endorsement node is determined, after the endorsement node is determined, before the transaction is broadcast to the endorsement node, after the transaction result is received, and before the uplink request is sent.

14. A transaction processing device for a blockchain network, comprising:

a memory for storing executable instructions;

a processor for implementing the method of any one of claims 1 to 12 when executing executable instructions stored in the memory.

15. A computer-readable storage medium having stored thereon executable instructions for, when executed by a processor, implementing the method of any one of claims 1 to 12.