Transaction execution method and device, computer readable medium and electronic equipment

Abstract

The embodiment of the invention provides a transaction execution method and device in a block chain network, a computer readable medium and electronic equipment, and the method comprises the steps: adding a to-be-executed transaction to a block chain node and a target contract task queue corresponding to a target smart contract, the block chain node comprises contract task queues corresponding to the smart contracts; for each smart contract, determining the number of lightweight virtual machines started for the smart contract according to the number of transactions to be executed contained in the corresponding contract task queue; and for each smart contract, starting the lightweight virtual machines containing the smart contract on the block chain node according to the number of the lightweight virtual machines, and pulling and executing the to-be-executed transaction from the contract task queue corresponding to the smart contract through the lightweight virtual machines. Operating system components used by the lightweight virtual machine are an independent operating system kernel and a root file system. According to the embodiment of the invention, the resource isolation during execution of different transactions can be enhanced, and the starting time is shortened.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and more specifically, to a method, device, computer-readable medium, and electronic device for executing transactions in a blockchain network. Background Art

[0002] The core of blockchain is smart contract technology. Alliance chains including Changan Chain and Hyperledger Fabric all use smart contract technology.

[0003] However, existing smart contracts have problems such as long container startup time and poor resource isolation between different smart contracts when in use, and cannot meet the high concurrency requirements of blockchain transactions. Summary of the invention

[0004] The embodiments of the present application provide a method, device, computer-readable medium, and electronic device for executing transactions in a blockchain network, which can enhance resource isolation when executing different transactions and reduce startup time, at least to a certain extent.

[0005] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0006] According to one aspect of an embodiment of the present application, a method for executing transactions in a blockchain network is provided, the method comprising: according to a target smart contract identifier contained in the transaction to be executed, adding the transaction to be executed to a target contract task queue corresponding to the target smart contract on a blockchain node, the smart contract identifier of the target smart contract being the target smart contract identifier, and the blockchain node comprising contract task queues corresponding to each smart contract in at least one smart contract; for each smart contract in the at least one smart contract, determining the number of lightweight virtual machines that need to be started for the smart contract according to the number of transactions to be executed contained in the contract task queue corresponding to the smart contract; for each smart contract in the at least one smart contract, starting a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines that need to be started for the smart contract, and pulling and executing the transaction to be executed from the contract task queue corresponding to the smart contract through the lightweight virtual machine, wherein the operating system components used by the lightweight virtual machine are an independent operating system kernel and a root file system.

[0007] According to one aspect of an embodiment of the present application, a device for executing transactions in a blockchain network is provided, the device comprising: an adding unit, for adding the to-be-executed transaction to a target contract task queue corresponding to the target smart contract on the blockchain node according to the target smart contract identifier contained in the to-be-executed transaction, the smart contract identifier of the target smart contract being the target smart contract identifier, and the blockchain node comprising contract task queues corresponding to each smart contract in at least one smart contract; a quantity determining unit, for determining, for each smart contract in the at least one smart contract, the number of to-be-executed transactions contained in the contract task queue corresponding to the smart contract, the number of lightweight virtual machines that need to be started for the smart contract; a starting and executing unit, for each smart contract in the at least one smart contract, starting a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines that need to be started for the smart contract, and pulling and executing the to-be-executed transaction from the contract task queue corresponding to the smart contract through the lightweight virtual machine, wherein the operating system components used by the lightweight virtual machine are an independent operating system kernel and a root file system.

[0008] In some embodiments of the present application, based on the aforementioned scheme, the sum of the number of lightweight virtual machines started for each smart contract on the blockchain node is a fixed value.

[0009] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a dynamic adjustment unit; after starting a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines started for the smart contract as needed for each smart contract in the at least one smart contract, the dynamic adjustment unit is used to: perform a lightweight virtual machine dynamic adjustment step for each smart contract respectively, and the lightweight virtual machine dynamic adjustment step includes: obtaining the length of the contract task queue corresponding to the current smart contract; and adjusting the number of lightweight virtual machines corresponding to the current smart contract according to the length of the contract task queue.

[0010] In some embodiments of the present application, based on the aforementioned scheme, the dynamic adjustment unit is configured as follows: if the contract task queue is determined to be a long queue based on the comparison result of the length of the contract task queue and the long queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is increased; if the contract task queue is determined to be a short queue based on the comparison result of the length of the contract task queue and the short queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is reduced, wherein the long queue length threshold is greater than the short queue length threshold.

[0011] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a contract task queue creation unit; before adding the transaction to be executed to the target contract task queue corresponding to the target smart contract on the blockchain node according to the target smart contract identifier contained in the transaction to be executed, the contract task queue creation unit is used to: if the transaction to be executed is a transaction for creating a smart contract, obtain the smart contract in binary file form from the transaction to be executed; and create a contract task queue corresponding to the smart contract in binary file form on the blockchain node.

[0012] In some embodiments of the present application, based on the aforementioned scheme, the startup and execution unit is configured to: obtain a pre-prepared kernel image and root file system image; copy the smart contract in binary file form to the root file system image to obtain a new root file system image; and start a lightweight virtual machine containing the smart contract based on the new root file system image and the kernel image.

[0013] In some embodiments of the present application, based on the aforementioned scheme, the device further includes an acquisition unit and a block generation unit; before adding the transaction to be executed to the target contract task queue corresponding to the target smart contract on the blockchain node, the acquisition unit is used to: add the received transaction to the transaction pool; obtain multiple transactions for generating a new block from the transaction pool; select one transaction from the multiple transactions each time as the transaction to be executed, wherein the number of lightweight virtual machines that need to be started for the smart contract is determined when all transactions for generating the new block are added to the corresponding contract task queue; after pulling and executing the transaction to be executed from the contract task queue corresponding to the smart contract through the lightweight virtual machine, the block generation unit is used to: when all the transactions to be executed for generating the new block are executed, generate a new block according to all the transactions to be executed for generating the new block.

[0014] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a verification unit; before adding the received transaction to the transaction pool, the verification unit is used to: when the blockchain node receives a transaction request carrying a transaction from a client, perform signature verification and authority verification on the transaction request, wherein the received transaction is added to the transaction pool when the transaction request passes the signature verification and the authority verification.

[0015] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a consensus unit; after generating a new block according to all pending transactions for generating the new block, the consensus unit is used to: send the new block to other blockchain nodes in the blockchain network to reach a consensus in the blockchain network; if the consensus on the new block is passed, the new block is stored in the blockchain node.

[0016] According to one aspect of an embodiment of the present application, a computer-readable medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method for executing transactions in a blockchain network as described in the above embodiments is implemented.

[0017] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method for executing transactions in a blockchain network as described in the above embodiments.

[0018] According to one aspect of an embodiment of the present application, a computer program product is provided, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method for executing transactions in a blockchain network as described in the above embodiments.

[0019] In the technical solutions provided in some embodiments of the present application, by setting contract task queues corresponding to each smart contract on the blockchain node, and adding the to-be-executed transaction to the corresponding target contract task queue according to the target smart contract identifier contained in the to-be-executed transaction; then, by creating a lightweight virtual machine containing the smart contract for each smart contract, the transaction is pulled and executed from the contract task queue corresponding to the corresponding smart contract by the lightweight virtual machine corresponding to each smart contract, and the number of lightweight virtual machines that need to be started for each smart contract is determined according to the number of to-be-executed transactions contained in the contract task queue corresponding to each smart contract, thereby effectively improving the concurrency performance, and can smoothly achieve high concurrency when the number of transactions is large; at the same time, since a lightweight virtual machine is used to pull and execute transactions, and the lightweight virtual machine uses an independent operating system kernel and root file system, the resource isolation and security of different transactions are effectively enhanced; in addition, compared with the startup time of an ordinary container, the lightweight virtual machine does not need to start components such as a time-consuming security management component, so the startup time of the lightweight virtual machine is shorter, and the startup and running speed is faster, thereby improving the startup efficiency, and the fast switching of lightweight virtual machines can be achieved.

[0020] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0022] Figure 1 A schematic diagram showing an exemplary system architecture to which the technical solution of the embodiments of the present application can be applied;

[0023] Figure 2 A flowchart of a method for executing a transaction in a blockchain network according to an embodiment of the present application is shown;

[0024] Figure 3 An embodiment according to the present application is shown. Figure 2 Flowchart of the steps before step 260, details of step 270, and steps after step 280 in the embodiment;

[0025] Figure 4 A schematic diagram of the architecture of a blockchain node according to an embodiment of the present application is shown;

[0026] Figure 5 An embodiment according to the present application is shown. Figure 2 Flowchart of steps before step 260 in the embodiment;

[0027] Figure 6 A flowchart of starting a lightweight virtual machine containing a smart contract on a blockchain node according to an embodiment of the present application is shown;

[0028] Figure 7 An embodiment according to the present application is shown. Figure 2 A flowchart of the steps after step 280 in the embodiment;

[0029] Figures 8A-8C A schematic diagram of the process of installing and running a smart contract on a blockchain node according to an embodiment of the present application is shown;

[0030] Figures 9A-9C A schematic diagram of the process of initiating and executing a common transaction according to an embodiment of the present application is shown;

[0031] Figures 10A-10B A schematic diagram of a process of dynamic container scheduling based on Firecracker according to an embodiment of the present application is shown;

[0032] Fig.11 A block diagram of a device for executing transactions in a blockchain network according to an embodiment of the present application is shown;

[0033] Fig.12 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0034] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more comprehensive and complete and fully convey the concept of the example embodiments to those skilled in the art.

[0035] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0036] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0037] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0038] In related technologies, public chains and consortium chains are two common types of blockchains. Public chains including Ethereum and consortium chains including Changan Chain and Hyperledger Fabric all use smart contract technology. However, the smart contracts they provide have the following disadvantages when used:

[0039] Ethereum's solidity contract charges for each operation. Overly complex code logic and calculation processes will consume a lot of fees, and the contract language is not rich enough and has certain limitations.

[0040] In alliance chains such as Changan Chain and Hyperledger Fabric, smart contract execution does not actually consume fees, so native languages ​​(such as Golang and Java) can be used, but these languages ​​usually occupy a process, can directly operate memory, occupy the network, consume CPU, etc., and can access the other party's file system or network. A contract in Changan Chain starts a process. If the transaction logic of a contract is too complex, it can occupy most of the resources, resulting in slow execution of other contract transactions. Hyperledger Fabric uses the Docker container method, but the storage and resource usage of Docker containers are very large and heavy, and the startup time is slow.

[0041] To this end, the present application first provides a method for executing transactions in a blockchain network. The method for executing transactions in a blockchain network provided by the embodiments of the present application can overcome the above-mentioned defects, not only can solve the resource isolation problem of different contract transactions, but also can solve the problem of slow startup time of Docker containers, making concurrency more friendly; in addition, it can also improve the ease of use of executing transactions based on smart contracts.

[0042] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solution of the embodiment of the present application can be applied is shown. Figure 1As shown, the system architecture 100 may include a user terminal 110 and a blockchain network 130. The blockchain network 130 includes multiple blockchain nodes, which may specifically include a first blockchain node 131, a second blockchain node 132, a third blockchain node 133, a fourth blockchain node 134, and a fifth blockchain node 135. The user terminal 110 and the blockchain network 130 are connected via a communication link 120, and a communication connection is established between any two blockchain nodes, so that the user terminal 110 can communicate with any blockchain node in the blockchain network 130, and any two blockchain nodes in the blockchain network 130 can also communicate with each other. A contract task queue corresponding to a smart contract and a group of lightweight virtual machines are deployed on each blockchain node. Each blockchain node stores a blockchain, and a client that can be used to access the blockchain located on the blockchain node in the blockchain network 130 is deployed on the user terminal 110. When a method for executing transactions in a blockchain network provided in the present application is applied to Figure 1 In the system architecture shown, a process may be as follows: first, a user sends a transaction request containing a transaction to a first blockchain node 131 in a blockchain network 130 through a client on a user terminal 110; then, the first blockchain node 131 determines a contract task queue corresponding to the smart contract identifier according to the received smart contract identifier in the transaction, and adds the transaction to the contract task queue; then, the transaction is pulled from the contract task queue and executed through a lightweight virtual machine in a group of lightweight virtual machines corresponding to the smart contract identifier.

[0043] In some embodiments of the present application, when the first blockchain node 131 receives a transaction for creating a smart contract, the first blockchain node 131 creates a new contract task queue based on the smart contract included in the transaction and adds the transaction to the new contract task queue.

[0044] In some embodiments of the present application, a transaction pool is deployed on each blockchain node. After receiving a transaction, each blockchain node adds it to the transaction pool. Each blockchain node takes out the transaction that needs to be added to the contract task queue from the transaction pool.

[0045] In some embodiments of the present application, each blockchain node adds the transaction in the transaction request to the transaction pool after completing the legitimacy verification of the received transaction request.

[0046] It should be understood that Figure 1The number of user terminals and blockchain nodes in the blockchain network is only illustrative. According to the implementation requirements, there can be any number of user terminals, and the number of blockchain nodes in the blockchain network can also be any number, that is, there can be multiple user terminals, and the number of blockchain nodes in the blockchain network can be more than 5 or less than 5.

[0047] It should be noted that Figure 1 The embodiment shown is only one embodiment of the present application. Figure 1 In the embodiment, the blockchain node in the blockchain network is a server, and the user terminal is a desktop computer. However, in other embodiments of the present application, the blockchain node and the user terminal may also be various types of terminal devices such as laptop computers, desktop computers, tablet computers, vehicle-mounted terminals, portable wearable devices, workstations, etc.; although in Figure 1 In the scheme of the embodiment, the device type of each blockchain node in the blockchain network is the same, but in other embodiments of the present application, each blockchain node in the blockchain network can use different types of devices; the transaction executed on a blockchain node is directly obtained by the blockchain node from the user terminal, but in other embodiments of the present application, the transaction executed on a blockchain node can also be obtained by the blockchain node from other blockchain nodes. For example, when the resources of a blockchain node are insufficient, the received transaction can be forwarded to other blockchain nodes for execution. The embodiment of the present application does not make any limitation on this, and the protection scope of the present application should not be limited in any way.

[0048] It is easy to understand that the execution method of transactions in the blockchain network provided in the embodiment of the present application is generally executed by the server, and accordingly, the execution device of transactions in the blockchain network is generally set in the server. However, in other embodiments of the present application, the terminal device may also have similar functions as the server, so as to execute the execution scheme of transactions in the blockchain network provided in the embodiment of the present application.

[0049] Therefore, the embodiments of the present application can be applied to a terminal or a server. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited to this. The terminal and the server can be directly or indirectly connected via wired or wireless communication, and this application is not limited here.

[0050] The solution of the embodiment of the present application can be applied to the field of blockchain. Blockchain is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods, each of which contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product service layer, and the application service layer.

[0051] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation monitoring. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first adapts the interface for parsing and authentication (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation monitoring module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarm, network status monitoring, node equipment health status monitoring, etc.

[0052] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0053] The implementation details of the technical solution of the embodiment of the present application are described in detail below:

[0054] Figure 2The flowchart of the method for executing transactions in a blockchain network according to an embodiment of the present application is shown. The method for executing transactions in the blockchain network can be executed by any blockchain node in the blockchain network. The blockchain node can be a variety of devices capable of computing and processing, such as user terminals or cloud servers. User terminals include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, smart watches, etc. Please refer to Figure 2 As shown, the method for executing transactions in the blockchain network includes at least the following steps:

[0055] Step 260, according to the target smart contract identifier contained in the transaction to be executed, the transaction to be executed is added to the target contract task queue corresponding to the target smart contract on the blockchain node, the smart contract identifier of the target smart contract is the target smart contract identifier, and the blockchain node contains contract task queues corresponding to each smart contract in at least one smart contract.

[0056] Step 270, for each smart contract in at least one smart contract, determine the number of lightweight virtual machines that need to be started for the smart contract based on the number of transactions to be executed contained in the contract task queue corresponding to the smart contract.

[0057] Step 280, for each smart contract in at least one smart contract, start a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines that need to be started for the smart contract, and pull and execute pending transactions from the contract task queue corresponding to the smart contract through the lightweight virtual machine, wherein the operating system components used by the lightweight virtual machine are an independent operating system kernel and root file system.

[0058] Before introducing the above steps in detail, the steps that need to be performed before step 260 are first introduced.

[0059] Figure 3 An embodiment according to the present application is shown. Figure 2 Flowchart of steps before step 260, details of step 270, and steps after step 280 in the embodiment. Figure 3 As shown, before adding the transaction to be executed to the target contract task queue corresponding to the target smart contract on the blockchain node, the transaction execution method in the blockchain network may include the following steps:

[0060] In step 210, the received transaction is added to the transaction pool.

[0061] It is easy to understand that the transactions received by the blockchain nodes exist in the form of transaction information.

[0062] The transaction pool (also called Mempool) of a blockchain refers to a collection of transactions that have not been packaged into a block and are waiting to be written into a block. In a blockchain network, each node maintains a transaction pool to store new transactions generated by users. When a user initiates a transaction, the transaction will be broadcast to the entire network. If the transaction complies with the transaction rules and verification rules of the blockchain network, it will be added to the node's transaction pool. Transactions in the transaction pool need to wait for verification and confirmation before waiting to be packaged into a block. By using transaction pool technology, the efficiency and performance of the blockchain can be improved while ensuring that transactions are processed smoothly.

[0063] Figure 4 A schematic diagram of the architecture of a blockchain node according to an embodiment of the present application is shown. Figure 4 Introduce the solution of the embodiment of this application. Figure 4 As shown, the architecture first includes a network module. The network module is a module for the blockchain node to interact with the outside world through the network, which includes a transaction chain submodule and a data query submodule; the transaction chain submodule is used to receive transactions sent by users to the blockchain node through the client; the data query submodule receives query statements sent by users, and the query statements are used to directly query data in the blockchain.

[0064] In one embodiment of the present application, before adding the received transaction to the transaction pool, the transaction execution method in the blockchain network may further include the following steps: when the blockchain node receives a transaction request carrying a transaction from a client, the transaction request is subjected to signature verification and authority verification, wherein the received transaction is added to the transaction pool when the transaction request passes the signature verification and authority verification.

[0065] The blockchain network includes multiple blockchain nodes. The blockchain node that receives the transaction request can be any blockchain node in the blockchain network, for example, it can be the blockchain node closest to the requester, or it can be a blockchain node randomly determined from the blockchain network.

[0066] By performing signature verification and permission verification on transaction requests, the legitimacy of transaction requests can be verified, avoiding the mistaken addition of illegal transactions to the transaction pool, and further avoiding the mistaken addition of illegal transactions to the chain.

[0067] In one embodiment of the present application, a signature verification is performed on a transaction request in the following manner: a transaction request and a digital signature carrying a transaction are received from a client, where the digital signature is obtained by encrypting a summary of the transaction request by the requester of the transaction request using its private key; the digital signature is decrypted using the public key of the requester of the transaction request to obtain a first summary; a hash operation is performed on the transaction request using a hash function to obtain a second summary; if the first summary is consistent with the second summary, it is determined that the signature verification has been passed; otherwise, it is determined that the signature verification has not been passed.

[0068] The transaction request may include the identity of the requester, and the transaction request may be verified by determining whether the transaction request matches the authority corresponding to the identity. The identity of the requester may be the public key of the requester, or any other ID that can uniquely identify a requester.

[0069] Specifically, whether the permission verification is passed can be determined by determining whether the requester of the transaction request is on the blacklist, whether it has the authority to send the transaction, whether it has the authority to call the method to create the contract, etc.

[0070] Please continue to see Figure 4 As shown, the architecture also includes an authentication module and a transaction pool module. The authentication module includes a signature verification submodule and a permission verification submodule. Signature verification is performed through the signature verification submodule, and permission verification is performed through the permission verification submodule. The transaction pool module is used to cache received transactions into the transaction pool.

[0071] In step 220, multiple transactions for generating a new block are obtained from the transaction pool.

[0072] When a new block is about to be generated, a batch of transactions used to generate the new block is obtained from the transaction pool so that a new block can be generated based on this batch of transactions.

[0073] Please continue to see Figure 4 As shown, the architecture also includes a block scheduling module, which is used to schedule transactions in the transaction pool and generate new blocks. The block scheduling module is responsible for obtaining multiple transactions from the transaction pool for generating new blocks.

[0074] In step 230, one transaction is selected from the multiple transactions each time as a transaction to be executed.

[0075] Treat each transaction as a pending transaction, and perform subsequent operations on each pending transaction in sequence until all transactions used to generate a new block are added to the corresponding contract task queue.

[0076] Figure 4 The block scheduling module in is used to traverse each transaction in multiple transactions in sequence.

[0077] Figure 5 An embodiment according to the present application is shown. Figure 2 Flowchart of steps before step 260 in the embodiment. Figure 5 As shown, before adding the transaction to be executed to the target contract task queue corresponding to the target smart contract on the blockchain node according to the target smart contract identifier contained in the transaction to be executed, the transaction execution method in the blockchain network may further include the following steps:

[0078] In step 240, if the transaction to be executed is a transaction for creating a smart contract, the smart contract in binary file form is obtained from the transaction to be executed.

[0079] A pending transaction can be a transaction used to create a smart contract, or it can be a normal transaction, that is, a transaction that does not require the creation of a smart contract. These normal transactions usually require the execution of transactions through the created smart contract.

[0080] Smart contract is a computer protocol designed to transmit, verify or execute contracts in an information-based manner. Smart contracts allow trusted transactions without a third party, and these transactions are irreversible.

[0081] If a pending transaction contains a smart contract in binary form, it is a transaction used to create a smart contract.

[0082] When a user needs to create a smart contract in a blockchain network, he first compiles the local smart contract (such as the code file of the smart contract) into a binary file to obtain the smart contract in binary file form, and then submits the transaction containing the smart contract in binary file form to the blockchain node.

[0083] In step 250, a contract task queue corresponding to the smart contract in binary file form is created on the blockchain node.

[0084] Figure 4 The block scheduling module shown will create a new contract task queue corresponding to the smart contract when the transaction to be executed is a transaction for creating a smart contract.

[0085] Below, we will introduce the details Figure 2 Steps shown.

[0086] In step 260, according to the target smart contract identifier contained in the transaction to be executed, the transaction to be executed is added to the target contract task queue corresponding to the target smart contract on the blockchain node, the smart contract identifier of the target smart contract is the target smart contract identifier, and the blockchain node contains contract task queues corresponding to each smart contract in at least one smart contract.

[0087] Please continue to see Figure 4 As shown in the figure, the block scheduling module specifically includes a transaction distribution scheduling submodule, which includes a contract task queue corresponding to each smart contract, and the contract task queue stores all tasks corresponding to the corresponding smart contract. The block scheduling module is responsible for placing the pending transactions into the transaction distribution scheduling submodule, which schedules and distributes the pending transactions to the corresponding contract task queue for execution.

[0088] The smart contract identifier included in the pending transaction is used to uniquely identify a smart contract. The pending transaction may be an ordinary transaction, in which case the smart contract identifier included in the pending transaction is used to identify the smart contract used to execute the pending transaction; the pending transaction may also be a transaction used to create a smart contract.

[0089] In this step, the pending transaction is added to the corresponding contract task queue according to the smart contract required to execute the pending transaction. The transaction added to the contract task queue can also be called a task.

[0090] Before obtaining the transaction to be executed, there may be a contract task queue corresponding to one or more smart contracts on the blockchain node. Each smart contract corresponds to a contract task queue.

[0091] In step 270, for each smart contract in at least one smart contract, the number of lightweight virtual machines that need to be started for the smart contract is determined based on the number of transactions to be executed contained in the contract task queue corresponding to the smart contract.

[0092] Before executing step 270, the method may further include the following steps: determining whether all transactions used to generate a new block have been added to the corresponding contract task queue.

[0093] Please continue to see Figure 3 As shown, for each smart contract in at least one smart contract, according to the number of transactions to be executed contained in the contract task queue corresponding to the smart contract, determining the number of lightweight virtual machines that need to be started for the smart contract can specifically include the following steps:

[0094] In step 270', when all transactions for generating a new block are added to the corresponding contract task queue, for each smart contract in at least one smart contract, the number of lightweight virtual machines that need to be started for the smart contract is determined based on the number of transactions to be executed contained in the contract task queue corresponding to the smart contract.

[0095] That is, determining the number of lightweight virtual machines that need to be started for the smart contract is done by adding all transactions for generating new blocks to the corresponding contract task queue.

[0096] In one embodiment of the present application, the sum of the number of lightweight virtual machines started for each smart contract on the blockchain node is a fixed value.

[0097] The number of lightweight virtual machines started on a blockchain node can always be controlled to a fixed value to ensure that the total resources used by the blockchain node remain unchanged, thereby effectively realizing resource management.

[0098] In one embodiment of the present application, the number of lightweight virtual machines that need to be started for the smart contract is determined based on the number of pending transactions contained in the contract task queue corresponding to the smart contract, including: determining the sum of the numbers of pending transactions contained in each contract task queue; determining the proportion of the number of pending transactions contained in each contract task queue based on the sum of the numbers; and taking the product of the proportion of the number corresponding to the current smart contract and a fixed value as the number of lightweight virtual machines that need to be started for the current smart contract.

[0099] Since the product of the quantity ratio and the fixed value may be a decimal, in actual calculation, rounding operation can be performed. It is only necessary to make the sum of the number of lightweight virtual machines started for each smart contract on the blockchain node a fixed value.

[0100] In one embodiment of the present application, the number of lightweight virtual machines that need to be started for the smart contract is determined based on the number of pending transactions contained in the contract task queue corresponding to the smart contract, including: determining the logical complexity of each smart contract; for each smart contract, determining the product of the logical complexity of the smart contract and the number of pending transactions contained in the contract task queue of the smart contract; determining the sum of the products of the quantities corresponding to each smart contract; determining the proportion of the product of the quantities corresponding to the current smart contract based on the sum of the products of the quantities corresponding to each smart contract and the product of the quantity corresponding to the current smart contract; and taking the product of the proportion of the product of the quantities corresponding to the current smart contract and a fixed value as the number of lightweight virtual machines that need to be started for the current smart contract.

[0101] Logical complexity can be calculated in various ways, for example, based on the length of the smart contract code or the time complexity of the smart contract code.

[0102] In an embodiment of the present application, since the logical complexity of the smart contract is further taken into consideration when determining the number of lightweight virtual machines that need to be started for the smart contract, the number of lightweight virtual machines that need to be started for the smart contract can be determined more accurately, so that the pending transactions contained in each contract task queue can be executed efficiently and synchronously.

[0103] In step 280, for each smart contract in at least one smart contract, a lightweight virtual machine containing the smart contract is started on the blockchain node according to the number of lightweight virtual machines needed to be started for the smart contract, and the lightweight virtual machine is used to pull and execute pending transactions from the contract task queue corresponding to the smart contract, wherein the operating system components used by the lightweight virtual machine are an independent operating system kernel and root file system.

[0104] Lightweight virtual machines (microVMs) are created based on Firecracker, and may also be referred to as contract Firecracker containers in the embodiments of this application. Firecracker is a lightweight virtualization technology based on KVM (Kernel-based Virtual Machine), designed to provide secure isolation for serverless and container workloads. Firecracker can start new microVMs in hundreds of microseconds, making it ideal for running tasks in large-scale parallelism. Firecracker's resource usage and startup time are lower than traditional virtual machines and container technologies.

[0105] Firecracker has the following advantages:

[0106] 1. Isolation performance: Firecracker provides stronger isolation performance because it uses lightweight virtual machines (microVMs) to run workloads. This means that each task runs in its own virtual machine, completely isolated from other tasks and the host system.

[0107] 2. Startup time: Firecracker has a very short startup time and can start new micro virtual machines in hundreds of microseconds. This makes Firecracker very suitable for scenarios that require fast startup and stop of tasks, such as serverless computing.

[0108] 3. Security: Firecracker is designed with security in mind, using a variety of techniques to limit virtual machines’ access to host system resources. This makes Firecracker more resilient than container technology when facing security threats.

[0109] A container is an independent runtime environment in which you can run applications. A container is created based on an image, contains everything in the image, and can run applications in it. Containers are lightweight, can be started and stopped quickly, and can run in different environments, such as development, testing, and production environments. Container technology can help developers build, test, and deploy applications more quickly.

[0110] The inventor of this application found that compared with traditional Docker containers, Firecracker has obvious advantages in isolation performance, startup time, security and ease of use. Therefore, Firecracker is more suitable for scenarios that require strong isolation performance and fast startup time, and therefore, it is more suitable for blockchain contract process execution.

[0111] All lightweight virtual machines started on a blockchain node constitute a contract container pool. The contract container pool is a smart contract execution environment based on blockchain technology. It can automatically manage and schedule multiple smart contract containers to achieve efficient smart contract execution. The contract container pool usually consists of multiple smart contract containers, each of which can execute smart contracts independently. When a new smart contract needs to be executed, the contract container pool will automatically select an available container to execute the contract, thereby achieving efficient execution of the smart contract.

[0112] The contract container pool can improve the execution efficiency and reliability of smart contracts because it can automatically manage and schedule multiple smart contract containers, thus avoiding the performance bottleneck and failure risk of a single container. In addition, the contract container pool can also provide better resource utilization because it can dynamically adjust the number of containers according to actual needs, thus avoiding the problem of resource waste and over-allocation.

[0113] Please continue to see Figure 4 As shown, the architecture also includes a virtual machine module, which includes a contract Firecracker container pool (contract container pool), which includes several contract Firecracker containers (lightweight virtual machines), and the number of contract Firecracker containers contained in the contract Firecracker container pool can be fixed; each contract Firecracker container is the running state of a contract image, and each contract Firecracker container includes a contract process and a Linux kernel. The contract process is the process of starting the contract binary program, and the Linux kernel is the runtime of the basic operating system Linux kernel required by the contract Firecracker container.

[0114] The contract Firecracker container pool in the virtual machine module is responsible for determining the number of lightweight virtual machines that need to be started for the smart contract, and starts the corresponding number of lightweight virtual machines containing the smart contract on the blockchain node; the block scheduling module schedules the contract Firecracker container to execute the tasks in the contract task queue. The contract Firecracker container pulls the transactions in the contract task queue and executes the transactions by calling the smart contract.

[0115] Figure 6 A flowchart of starting a lightweight virtual machine containing a smart contract on a blockchain node according to an embodiment of the present application is shown. Figure 6 As shown, starting a lightweight virtual machine containing a smart contract on a blockchain node may include the following steps:

[0116] In step 610, a pre-prepared kernel image and root file system image are obtained.

[0117] An image is a static file collection that contains an operating system, application, and related dependencies that can be used to create a container. An image is usually read-only and can be used by multiple containers at the same time.

[0118] The kernel image is a static file collection related to the kernel of the operating system; the root file system image (root file system image) is a static file collection related to the root file system of the operating system.

[0119] Specifically, use Firecracker's API (Application Programming Interface) or related tools (such as firectl) to create and run a microVM.

[0120] firectl is a tool for booting and running containers. It provides a convenient way to create and manage containers. The following is an example of creating and running a microVM using the firectl tool.

[0121] First, install Firecracker and firectl.

[0122] Next, prepare a kernel image and a root file system image.

[0123] You can download the kernel image from the Firecracker code repository using the following command:

[0124] Curl-fsSL-o hello-vmlinux.bin https: / / s3.XXX.com / XXX.XXX.XXX / im g / hello / kernel / hello-vmlinux.bin.

[0125] This command is used to download files from the specified URL https: / / s3.XXX.com / XXX.XXX.XXX / img / hello / kernel / hello-vmlinux.bin in silent mode, display an error message when the download fails, and save the downloaded file as a kernel image named hello-vmlinux.bin.

[0126] You can use the following command to image the root file system from the Firecracker code repository:

[0127] curl-fsSL -o hello-rootfs.ext4 https: / / s3.XXX.com / XXX.XXX.XXX / img / hello / fsfiles / hello-rootfs.ext4.

[0128] The command is used to download the file from the specified URL https: / / s3.XXX.com / XXX.XXX.XXX / img / hello / fsfiles / hello-rootfs.ext4 in silent mode, display an error message when the download fails, and save the downloaded file as a root file system image named hello-rootfs.ext4.

[0129] In step 620, the smart contract in binary file form is copied to the root file system image to obtain a new root file system image.

[0130] Then, you need to copy the smart contract in binary form to the root file system image. You can use the following command to mount the root file system image and copy the file:

[0131] First, use the mkdir / tmp / my-rootfs command to create a directory with the path / tmp / my-rootfs; then, use the sudo mount-o loop hello-rootfs.ext4 / tmp / my-rootfs command to mount hello-rootfs.ext4 as a virtual disk to the / tmp / my-rootfs directory; then, use the sudo cp / path / to / your / binary / tmp / my-rootfs / path / inside / rootfs command to copy the binary file named binary in the / path / to / your path to the / tmp / my-rootfs / path / inside directory and name it rootfs; finally, use the sudo umount / tmp / my-rootfs command to unmount the mount point / tmp / my-rootfs.

[0132] Step 610 and step 620 may be steps executed each time a contract task queue corresponding to a smart contract in binary file form is created on a blockchain node.

[0133] Please continue to see Figure 4 As shown, the virtual machine module also includes a contract Firecracker image compiler and a contract Firecracker image repository. The contract Firecracker image compiler is used to package smart contracts in binary file form to obtain a new root file system image; the virtual machine module will put the new root file system image and kernel image into the contract Firecracker image repository. These images can be pulled from the contract Firecracker image repository at any time, and lightweight virtual machines can be started based on these images.

[0134] In step 630, a lightweight virtual machine including a smart contract is started based on the new root file system image and kernel image.

[0135] You can use firectl to start a lightweight virtual machine and execute a smart contract in binary file format using the following command:

[0136] firectl --kernel=hello-vmlinux.bin --root-drive=hello-rootfs.ext4 --kernel-opts="console=ttyS0 reboot=k panic=1pci=off my_binary_path".

[0137] kernel represents the kernel used to start the lightweight virtual machine, root-drive represents the root file system used to start the lightweight virtual machine, and kernel-opts is used to specify the parameters passed to the kernel. The parameter console=ttyS0 specifies the serial port device as the console, where ttyS0 is the first serial port device. This means that the system output (such as logs and error messages) will be displayed through the serial port device; the parameter reboot=k tells the system how to restart in case of a kernel crash. In this case, k indicates that the system should use the kernel to restart. The parameter panic=1 sets the behavior of the system in case of a kernel crash. In this case, 1 means restarting the system immediately after a kernel crash instead of waiting for the user to restart manually. The parameter pci=off disables the PCI bus, which is a bus standard for connecting hardware devices. Disabling PCI can enhance the security of the system, especially in some special application scenarios. my_binary_path is the path to copy the binary file of the smart contract to the root file system image.

[0138] In the embodiment of the present application, by packaging the smart contract image based on the above method, all contract binary files can be adapted, so that the existing blockchain can be directly switched to Firecracker to execute contract transactions.

[0139] Figure 7 An embodiment according to the present application is shown. Figure 2 Flow chart of the steps after step 280 in the embodiment. Figure 7 As shown, for each smart contract in at least one smart contract, after starting a lightweight virtual machine containing the smart contract on a blockchain node according to the number of lightweight virtual machines that need to be started for the smart contract, the method for executing transactions in the blockchain network may further include the following steps:

[0140] In step 2100, the lightweight virtual machine dynamic adjustment step is executed for each smart contract.

[0141] The step of dynamically adjusting the lightweight virtual machines may include: obtaining the length of the contract task queue corresponding to the current smart contract; and adjusting the number of lightweight virtual machines corresponding to the current smart contract according to the length of the contract task queue.

[0142] In one embodiment of the present application, the number of lightweight virtual machines corresponding to the current smart contract is adjusted according to the length of the contract task queue, including: if the contract task queue is determined to be a long queue based on the comparison result of the length of the contract task queue and the long queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is increased; if the contract task queue is determined to be a short queue based on the comparison result of the length of the contract task queue and the short queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is reduced, wherein the long queue length threshold is greater than the short queue length threshold.

[0143] Specifically, if the length of the contract task queue is greater than the long queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is increased; if the length of the contract task queue is less than the short queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is reduced.

[0144] The above-mentioned dynamic adjustment process of the number of lightweight virtual machines can be performed periodically, and during the adjustment process, the total number of lightweight virtual machines started on a blockchain node can always be kept unchanged.

[0145] The embodiment of the present application realizes dynamic resource allocation under the condition of fixed total resources, which can avoid the situation where the execution speed is uneven when the transactions of different contracts differ greatly, resulting in overall delay.

[0146] Please continue to see Figure 3 As shown, after the transaction to be executed is pulled from the contract task queue corresponding to the smart contract by the lightweight virtual machine and executed, the method may further include the following steps:

[0147] In step 290, when all pending transactions for generating a new block are executed, a new block is generated according to all pending transactions for generating a new block.

[0148] Please continue to see Figure 4 As shown, the block scheduling module also includes a block generation submodule. After all pending transactions for generating a new block are executed, the block generation submodule generates a new block.

[0149] In one embodiment of the present application, after generating a new block based on all pending transactions for generating the new block, the method may further include the following steps: sending the new block to other blockchain nodes in the blockchain network for consensus in the blockchain network; if the consensus on the new block is passed, storing the new block in the blockchain node.

[0150] Please continue to see Figure 4As shown in the figure, the architecture includes a consensus module and a storage module. The storage module includes a state database submodule and a block ledger submodule. The consensus module performs consensus voting on new blocks through PoW (Proof of Work) and PoS (Proof of Stake). After the consensus is passed, the block ledger submodule stores the text file of the new block, so that the new block is put on the chain. The state database submodule is used to store the latest variable status, such as the latest balance after the account transfer.

[0151] Figures 8A-8C A schematic diagram of the process of installing and running a smart contract on a blockchain node according to an embodiment of the present application is shown. Figures 8A-8C The same circular nodes in the same diagram indicate the same location in the process. Figures 8A-8C As shown in the figure, installing and running smart contracts on blockchain nodes can include the following processes:

[0152] Step 810, start.

[0153] In step 820, the user compiles the local smart contract into a binary file and starts a client to access the blockchain.

[0154] Step 830, the user defines the parameters of the contract initialization method, such as the account name and balance in the transfer contract.

[0155] In step 840, the user combines the above request and its signature and sends them to the blockchain node.

[0156] Step 850: The blockchain node authentication module performs signature verification.

[0157] Step 860: Did the signature verification pass?

[0158] If yes, go to step 880 , otherwise go to step 870 .

[0159] Step 870, the blockchain node returns an error indicating signature verification failed.

[0160] The blockchain node returns an error message to the client indicating that the signature verification failed. After this step is completed, go to step 8300.

[0161] In step 880, the blockchain node authentication module performs permission verification, such as whether the user is on the blacklist and whether he has the authority to call the method to create a contract.

[0162] Step 890: Is the authority verification passed?

[0163] If yes, go to step 8110, otherwise go to step 8100.

[0164] Step 8100, the blockchain node returns an error indicating that permission verification failed.

[0165] The blockchain node returns an error message to the client indicating that the permission verification failed. After this step is completed, go to step 8300.

[0166] Step 8110, the transaction pool module receives the transaction and puts it into the transaction pool.

[0167] Step 8120, the block scheduling module prepares to generate a new block and obtains a batch of transactions from the transaction pool.

[0168] Step 8130, the block scheduling module traverses the transactions in sequence.

[0169] Step 8140, is the current transaction a transaction to create a contract?

[0170] Determine whether the current transaction is used to create a smart contract. If yes, go to step 8150, otherwise go to step 8180.

[0171] Step 8150, the block scheduling module creates a new contract task queue.

[0172] Step 8160, the virtual machine module's contract Firecracker image compiler packages a new image for the contract.

[0173] In step 8170, the virtual machine module puts the above image into the contract Firecracker image repository, which can be pulled up at any time.

[0174] You can pull the image from the contract Firecracker image repository at any time to start the contract Firecracker container based on the image.

[0175] Step 8180: The block scheduling module puts the transaction into the corresponding contract task queue of the transaction distribution scheduling module.

[0176] Step 8190, are all transactions stored?

[0177] Determine whether all transactions used to generate a new block have been stored in the corresponding contract task queue. If yes, go to step 8200, otherwise go to step 8130.

[0178] Step 8200, the contract Firecracker container pool module of the virtual machine module starts different numbers of containers for different contracts according to the number of tasks in the contract task queue.

[0179] Start a Firecracker container for the smart contract. The number of Firecracker containers started is determined by the number of tasks in the corresponding contract task queue.

[0180] Step 8210, the block scheduling module schedules the contract Firecracker container to execute the tasks in the contract task queue.

[0181] Step 8220, the contract Firecracker container pulls the transaction in the queue and executes the transaction.

[0182] In step 8230, the number of containers for each contract will be dynamically adjusted during execution.

[0183] Step 8240: After all transactions are executed, the block scheduling module generates a new block.

[0184] Step 8250, after the generation is completed, the node sends the block to other blockchain nodes for consensus.

[0185] Step 8260: All blockchain nodes reach consensus.

[0186] Step 8270, is the consensus passed?

[0187] If consensus is passed, go to step 8290, otherwise go to step 8280.

[0188] Step 8280, returns the result of consensus verification failure.

[0189] The blockchain node returns information indicating that the consensus verification has failed to the client. After this step is completed, go to step 8300.

[0190] Step 8290, store the block and update the data in the status database.

[0191] Step 8300, end.

[0192] Figures 9A-9C A schematic diagram of the process of initiating and executing a common transaction according to an embodiment of the present application is shown. Figures 9A-9C The same circular nodes in the same diagram indicate the same location in the process. Figures 9A-9C As shown, initiating and executing a normal transaction may include the following processes:

[0193] Step 910, start.

[0194] Step 920: The user starts a client for accessing the blockchain.

[0195] Step 930, the user defines the contract, method and parameters to be called, such as the transfer contract, transfer, account names of both parties and transfer amount.

[0196] In step 940, the user combines the above request and its signature and sends it to the blockchain node.

[0197] Step 950: The blockchain node authentication module performs signature verification.

[0198] Step 960: Did the signature verification pass?

[0199] If yes, go to step 980 , otherwise go to step 970 .

[0200] Step 970, the blockchain node returns an error indicating signature verification failed.

[0201] The blockchain node returns an error message to the client indicating that the signature verification failed. After this step is completed, go to step 9300.

[0202] Step 980: The blockchain node authentication module performs permission verification, such as whether the user is on the blacklist and whether he has the permission to call the contract method.

[0203] Step 990: Is the authority verification passed?

[0204] If yes, go to step 9110, otherwise go to step 9100.

[0205] Step 9100, the blockchain node returns an error indicating that permission verification failed.

[0206] The blockchain node returns an error message to the client indicating that the permission verification failed. After this step is completed, go to step 9300.

[0207] Step 9110, the transaction pool module receives the transaction and puts it into the transaction pool.

[0208] Step 9120, the block scheduling module prepares to generate a new block and obtains a batch of transactions from the transaction pool.

[0209] Step 9130, the block scheduling module traverses the transactions in sequence.

[0210] Step 9140: Is the current transaction a transaction for creating a contract?

[0211] Determine whether the current transaction is used to create a smart contract. If yes, go to step 9150, otherwise go to step 9180.

[0212] Step 9150, the block scheduling module creates a new contract task queue.

[0213] Step 9160, the virtual machine module's contract Firecracker image compiler packages a new image for the contract.

[0214] Step 9170, the virtual machine module puts the above image into the contract Firecracker image repository, which can be pulled up at any time.

[0215] You can pull the image from the contract Firecracker image repository at any time to start the contract Firecracker container based on the image.

[0216] Step 9180: The block scheduling module puts the transaction into the corresponding contract task queue of the transaction distribution scheduling module.

[0217] Step 9190, are all transactions stored?

[0218] Determine whether all transactions used to generate a new block have been stored in the corresponding contract task queue. If yes, go to step 9200, otherwise go to step 9130.

[0219] Step 9200, the contract Firecracker container pool module of the virtual machine module starts different numbers of containers for different contracts according to the number of tasks in the contract task queue.

[0220] Start a Firecracker container for the smart contract. The number of Firecracker containers started is determined by the number of tasks in the corresponding contract task queue.

[0221] Step 9210, the block scheduling module schedules the contract Firecracker container to execute the tasks in the contract task queue.

[0222] Step 9220, the contract Firecracker container pulls the transaction in the queue and executes the transaction.

[0223] In step 9230, the number of containers for each contract will be dynamically adjusted during execution.

[0224] Step 9240: After all transactions are executed, the block scheduling module generates a new block.

[0225] Step 9250, after the generation is completed, the node sends the block to other blockchain nodes for consensus.

[0226] Step 9260: All blockchain nodes reach consensus.

[0227] Step 9270, is the consensus passed?

[0228] If consensus is passed, go to step 9290, otherwise go to step 9280.

[0229] Step 9280, returns the result of consensus verification failure.

[0230] The blockchain node returns information indicating that the consensus verification has failed to the client. After this step is completed, go to step 9300.

[0231] Step 9290, store the block and update the data in the status database.

[0232] Step 9300, end.

[0233] As you can see, Figures 9A-9C The process shown is similar to Figures 8A-8C The main differences in the illustrated process are step 920 , step 930 , and step 980 .

[0234] Figures 10A-10B A flow chart of a dynamic container scheduling process based on Firecracker according to an embodiment of the present application is shown. Figures 10A-10B The same circular nodes in the diagram indicate the same position in the process. Figures 10A-10B As shown in the figure, the dynamic container scheduling process based on Firecracker can include the following steps:

[0235] Step 1001, start.

[0236] Step 1002, the block scheduling module initializes the contract task queue. Each contract has a queue to store tasks to be processed.

[0237] Step 1003, the virtual machine module initializes the contract container pool. The size of the contract container pool is fixed, and the same contract can have multiple contract containers.

[0238] Step 1004, the block scheduling module continuously sends new transactions to the contract task queue.

[0239] Step 1005: The block scheduling module periodically traverses all contract task queues.

[0240] Step 1006, is the current contract task queue not empty and is there an available Firecraker container?

[0241] Determine whether the current contract task queue is not empty and has a corresponding available Firecraker container. If the current contract task queue is not empty and has an available Firecraker container, go to step 1007, otherwise go to step 1010.

[0242] Step 1007, take a task from the queue.

[0243] Take a transaction from the current contract task queue.

[0244] Step 1008, obtain an available Firecracker container.

[0245] Step 1009, running the task in the container.

[0246] Execute transactions from within a Firecracker container.

[0247] Step 1010, query the next contract task queue.

[0248] The next contract task queue is used as the new current contract task queue, and steps 1006 to 1009 are executed on it, thereby traversing the next contract task queue.

[0249] Step 1011: The block scheduling module periodically traverses and dynamically adjusts the Firecracker container allocation.

[0250] Step 1012, obtaining the length of the current task queue.

[0251] Step 1013: If the task queue is too long, it means that the number of containers for the current contract is insufficient and needs to be increased.

[0252] Step 1014: If the task queue is too short, it means that the number of containers for the current contract is too large and the allocation can be reduced.

[0253] Step 1015, end.

[0254] In summary, the method for executing transactions in a blockchain network provided by the embodiments of the present application can at least achieve the following effects:

[0255] 1. For the first time, a lightweight virtual machine based on Firecracker was proposed to execute transactions in the blockchain network. Thanks to the advantages of lightweight virtual machines in isolation performance, startup time, security and ease of use, it can not only ensure that blockchain contract processes can be isolated from each other, and processes cannot access and interfere with each other, effectively enhancing the resource isolation of different contract transactions, but also solve the problem of lightweight, allowing containers to start and run faster, ensuring rapid switching of contract containers, and achieving efficient switching and rotation under limited resources. It is more concurrency-friendly and improves the security and ease of use of transaction execution.

[0256] 2. A contract image packaging method is proposed, which can adapt to all contract binary files, making it easier for existing blockchains to directly switch to Firecracker to execute contract transactions.

[0257] 3. The concept of a contract Firecracker container pool is proposed, and a solution for dynamic adjustment of containers is proposed, so that dynamic resource allocation can be achieved under fixed total resources, avoiding uneven execution speeds when different contract transactions differ greatly, resulting in overall delays in transaction execution.

[0258] 4. When the number of block transactions is large, it can make full use of concurrency and stably achieve high concurrency, and can make full use of concurrency to improve the performance of transaction execution.

[0259] 5. The solutions of the embodiments of the present application can be widely reused in the industry.

[0260] The following describes an embodiment of the device of the present application, which can be used to execute the method for executing transactions in the blockchain network in the above-mentioned embodiment of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method for executing transactions in the blockchain network in the above-mentioned embodiment of the present application.

[0261] Fig.11 A block diagram of a transaction execution device in a blockchain network according to an embodiment of the present application is shown. Fig.11 As shown, according to an embodiment of the present application, a device 1100 for executing transactions in a blockchain network includes: an adding unit 1110, a quantity determining unit 1120, and a starting and executing unit 1130. Among them, the adding unit 1110 is used to add the to-be-executed transaction to the target contract task queue corresponding to the target smart contract on the blockchain node according to the target smart contract identifier contained in the to-be-executed transaction, the smart contract identifier of the target smart contract is the target smart contract identifier, and the blockchain node contains contract task queues corresponding to each smart contract in the at least one smart contract; the quantity determination unit 1120 is used to determine the number of lightweight virtual machines that need to be started for each smart contract in the at least one smart contract according to the number of to-be-executed transactions contained in the contract task queue corresponding to the smart contract; the starting and execution unit 1130 is used to start a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines that need to be started for the smart contract for each smart contract in the at least one smart contract, and pull and execute the to-be-executed transaction from the contract task queue corresponding to the smart contract through the lightweight virtual machine, wherein the operating system components used by the lightweight virtual machine are an independent operating system kernel and a root file system.

[0262] In some embodiments of the present application, based on the aforementioned scheme, the sum of the number of lightweight virtual machines started for each smart contract on the blockchain node is a fixed value.

[0263] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a dynamic adjustment unit; after starting a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines started for the smart contract as needed for each smart contract in the at least one smart contract, the dynamic adjustment unit is used to: perform a lightweight virtual machine dynamic adjustment step for each smart contract respectively, and the lightweight virtual machine dynamic adjustment step includes: obtaining the length of the contract task queue corresponding to the current smart contract; and adjusting the number of lightweight virtual machines corresponding to the current smart contract according to the length of the contract task queue.

[0264] In some embodiments of the present application, based on the aforementioned scheme, the dynamic adjustment unit is configured as follows: if the contract task queue is determined to be a long queue based on the comparison result of the length of the contract task queue and the long queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is increased; if the contract task queue is determined to be a short queue based on the comparison result of the length of the contract task queue and the short queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is reduced, wherein the long queue length threshold is greater than the short queue length threshold.

[0265] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a contract task queue creation unit; before adding the transaction to be executed to the target contract task queue corresponding to the target smart contract on the blockchain node according to the target smart contract identifier contained in the transaction to be executed, the contract task queue creation unit is used to: if the transaction to be executed is a transaction for creating a smart contract, obtain the smart contract in binary file form from the transaction to be executed; and create a contract task queue corresponding to the smart contract in binary file form on the blockchain node.

[0266] In some embodiments of the present application, based on the aforementioned scheme, the startup and execution unit 1130 is configured to: obtain a pre-prepared kernel image and root file system image; copy the smart contract in binary file form to the root file system image to obtain a new root file system image; and start a lightweight virtual machine containing the smart contract based on the new root file system image and the kernel image.

[0267] In some embodiments of the present application, based on the aforementioned scheme, the device further includes an acquisition unit and a block generation unit; before adding the transaction to be executed to the target contract task queue corresponding to the target smart contract on the blockchain node, the acquisition unit is used to: add the received transaction to the transaction pool; obtain multiple transactions for generating a new block from the transaction pool; select one transaction from the multiple transactions each time as the transaction to be executed, wherein the number of lightweight virtual machines that need to be started for the smart contract is determined when all transactions for generating the new block are added to the corresponding contract task queue; after pulling and executing the transaction to be executed from the contract task queue corresponding to the smart contract through the lightweight virtual machine, the block generation unit is used to: when all the transactions to be executed for generating the new block are executed, generate a new block according to all the transactions to be executed for generating the new block.

[0268] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a verification unit; before adding the received transaction to the transaction pool, the verification unit is used to: when the blockchain node receives a transaction request carrying a transaction from a client, perform signature verification and authority verification on the transaction request, wherein the received transaction is added to the transaction pool when the transaction request passes the signature verification and the authority verification.

[0269] In some embodiments of the present application, based on the aforementioned scheme, the device also includes a consensus unit; after generating a new block according to all pending transactions for generating the new block, the consensus unit is used to: send the new block to other blockchain nodes in the blockchain network to reach a consensus in the blockchain network; if the consensus on the new block is passed, the new block is stored in the blockchain node.

[0270] Fig.12 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0271] It should be noted that Fig.12 The computer system 1200 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0272] like Fig.12As shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1202 or the program loaded from the storage part 1208 to the random access memory (RAM) 1203, such as executing the method described in the above embodiment. In the RAM 1203, various programs and data required for system operation are also stored. The CPU 1201, the ROM 1202 and the RAM 1203 are connected to each other through the bus 1204. The input / output (I / O) interface 1205 is also connected to the bus 1204.

[0273] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, etc.; an output section 1207 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the I / O interface 1205 as needed. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1210 as needed so that a computer program read therefrom is installed into the storage section 1208 as needed.

[0274] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1209, and / or installed from a removable medium 1211. When the computer program is executed by a central processing unit (CPU) 1201, various functions defined in the system of the present application are executed.

[0275] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0276] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0277] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0278] As one aspect, the present application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiment; or may exist independently without being assembled into the electronic device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by an electronic device, the electronic device implements the method described in the above embodiment.

[0279] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0280] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation methods of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the implementation methods of the present application.

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

[0282] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0283] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for executing transactions in a blockchain network, characterized in that: The method comprises: According to the target smart contract identifier included in the to-be-executed transaction, the to-be-executed transaction is added to the target contract task queue corresponding to the target smart contract on the blockchain node, the smart contract identifier of the target smart contract is the target smart contract identifier, and the blockchain node contains contract task queues corresponding to each smart contract in the at least one smart contract; For each smart contract in the at least one smart contract, determine the number of lightweight virtual machines that need to be started for the smart contract according to the number of transactions to be executed contained in the contract task queue corresponding to the smart contract; For each smart contract in the at least one smart contract, a lightweight virtual machine containing the smart contract is started on the blockchain node according to the number of lightweight virtual machines that need to be started for the smart contract, and the lightweight virtual machine is used to pull and execute transactions to be executed from the contract task queue corresponding to the smart contract, wherein the operating system components used by the lightweight virtual machine are an independent operating system kernel and root file system.

2. The method for executing transactions in a blockchain network according to claim 1, characterized in that: The sum of the number of lightweight virtual machines started for each smart contract on the blockchain node is a fixed value.

3. The method for executing transactions in a blockchain network according to claim 1, characterized in that: After, for each of the at least one smart contract, starting a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines needed to be started for the smart contract, the method further includes: The lightweight virtual machine dynamic adjustment step is performed for each smart contract, and the lightweight virtual machine dynamic adjustment step includes: Get the length of the contract task queue corresponding to the current smart contract; The number of lightweight virtual machines corresponding to the current smart contract is adjusted according to the length of the contract task queue.

4. The method for executing transactions in a blockchain network according to claim 3, characterized in that: The adjusting the number of lightweight virtual machines corresponding to the current smart contract according to the length of the contract task queue includes: If the contract task queue is determined to be a long queue according to the comparison result between the length of the contract task queue and the long queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is increased; If the contract task queue is determined to be a short queue based on the comparison result of the length of the contract task queue and the short queue length threshold, the number of lightweight virtual machines corresponding to the current smart contract is reduced, wherein the long queue length threshold is greater than the short queue length threshold.

5. The method for executing transactions in a blockchain network according to claim 1, characterized in that: Before adding the to-be-executed transaction to a target contract task queue corresponding to the target smart contract on the blockchain node according to the target smart contract identifier included in the to-be-executed transaction, the method further includes: If the transaction to be executed is a transaction for creating a smart contract, obtaining a smart contract in binary file form from the transaction to be executed; A contract task queue corresponding to the smart contract in binary file form is created on the blockchain node.

6. The method for executing transactions in a blockchain network according to claim 5, characterized in that: The step of starting a lightweight virtual machine including the smart contract on the blockchain node comprises: Get the pre-prepared kernel image and root file system image; Copy the smart contract in binary file form to the root file system image to obtain a new root file system image; A lightweight virtual machine including the smart contract is started based on the new root file system image and the kernel image.

7. The method for executing transactions in a blockchain network according to claim 1, characterized in that: Before adding the to-be-executed transaction to a target contract task queue corresponding to the target smart contract on the blockchain node, the method includes: Add the received transaction to the transaction pool; Acquire multiple transactions for generating new blocks from the transaction pool; Selecting one transaction from the plurality of transactions each time as a transaction to be executed, wherein determining the number of lightweight virtual machines that need to be started for the smart contract is performed when all transactions for generating the new block are added to a corresponding contract task queue; After pulling and executing the to-be-executed transaction from the contract task queue corresponding to the smart contract through the lightweight virtual machine, the method further includes: When all pending transactions for generating the new block are executed, a new block is generated according to all pending transactions for generating the new block.

8. The method for executing transactions in a blockchain network according to claim 7, characterized in that: Before adding the received transaction to the transaction pool, the method further includes: When the blockchain node receives a transaction request carrying a transaction from a client, it performs signature verification and authority verification on the transaction request, wherein the received transaction is added to the transaction pool only when the transaction request passes the signature verification and the authority verification.

9. The method for executing transactions in a blockchain network according to claim 7, characterized in that: After generating a new block according to all pending transactions for generating the new block, the method further includes: Sending the new block to other blockchain nodes in the blockchain network to reach consensus in the blockchain network; If the consensus on the new block is passed, the new block is stored in the blockchain node.

10. A device for executing transactions in a blockchain network, characterized in that: The device comprises: an adding unit, configured to add the to-be-executed transaction to a target contract task queue corresponding to the target smart contract on the blockchain node according to the target smart contract identifier included in the to-be-executed transaction, wherein the smart contract identifier of the target smart contract is the target smart contract identifier, and the blockchain node includes contract task queues corresponding to each smart contract in at least one smart contract; A quantity determination unit, configured to determine, for each smart contract in the at least one smart contract, the number of lightweight virtual machines that need to be started for the smart contract according to the number of transactions to be executed contained in the contract task queue corresponding to the smart contract; A startup and execution unit is used to start a lightweight virtual machine containing the smart contract on the blockchain node according to the number of lightweight virtual machines that need to be started for each smart contract in the at least one smart contract, and pull and execute transactions to be executed from a contract task queue corresponding to the smart contract through the lightweight virtual machine, wherein the lightweight virtual machine uses an independent operating system kernel and root file system.

11. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for executing transactions in a blockchain network as described in any one of claims 1 to 9 is implemented.

12. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement the method for executing transactions in a blockchain network as described in any one of claims 1 to 9.

13. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method for executing transactions in a blockchain network as described in any one of claims 1 to 9.

Images