CN119539944A

CN119539944A - Transaction execution method, device, computer readable medium and electronic device

Info

Publication number: CN119539944A
Application number: CN202311094685.6A
Authority: CN
Inventors: 卢光宏
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-08-28
Filing date: 2023-08-28
Publication date: 2025-02-28

Abstract

The embodiment of the application provides a method, a device, a computer readable medium and electronic equipment for executing transactions in a blockchain network, wherein the method comprises the steps of adding transactions to be executed to a target contract task queue corresponding to a target intelligent contract by a blockchain node, determining the number of lightweight virtual machines started for the intelligent contracts according to the number of the transactions to be executed contained in the corresponding contract task queue for each intelligent contract, starting the lightweight virtual machines containing the intelligent contracts on the blockchain node according to the number of the lightweight virtual machines for each intelligent contract, and pulling and executing the transactions to be executed from the contract task queues corresponding to the intelligent contracts through the lightweight virtual machines, wherein operating system components used by the lightweight virtual machines are independent operating system kernels and root file systems. The embodiment of the application can enhance the resource isolation during the execution of different transactions and reduce the starting time.

Description

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

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a method and apparatus for executing a transaction in a blockchain network, a computer readable medium, and an electronic device.

Background

At the heart of the blockchain is the smart contract technology. The federation chains, including the channa chains and HYPERLEDGER FABRIC, all use smart contract technology.

However, the existing intelligent contracts have the problems of long container starting time and poor resource isolation between different intelligent contracts when the intelligent contracts are used, and cannot meet the high concurrency requirement of blockchain transactions.

Disclosure of Invention

The embodiment of the application provides a method and a device for executing transactions in a blockchain network, a computer readable medium and electronic equipment, so that the resource isolation of different transactions during execution can be enhanced at least to a certain extent, and the starting time is reduced.

Other features and advantages of the application will be apparent from the following detailed description, or may be learned by the practice of the application.

According to one aspect of the embodiment of the application, a method for executing transactions in a blockchain network is provided, the method comprises the steps of adding a target intelligent contract identifier contained in the transactions to be executed into a target contract task queue corresponding to the target intelligent contract on a blockchain node, wherein the intelligent contract identifier of the target intelligent contract is the target intelligent contract identifier, the blockchain node contains contract task queues respectively corresponding to intelligent contracts in at least one intelligent contract, determining the number of lightweight virtual machines required to be started for the intelligent contracts according to the number of the transactions to be executed contained in the contract task queues corresponding to the intelligent contracts for each intelligent contract in the at least one intelligent contract, starting the lightweight virtual machines containing the intelligent contracts on the blockchain node according to the number of the lightweight virtual machines required to be started for the intelligent contracts, and pulling and executing the tasks to be executed corresponding to the intelligent contracts from the lightweight virtual machines through the lightweight virtual machines, wherein the transaction is an independent operating system, and a system is used as a kernel.

According to one aspect of the embodiment of the application, an executing device of a transaction in a blockchain network is provided, wherein the executing device comprises an adding unit, a starting and executing unit and a system executing unit, wherein the adding unit is used for adding the transaction to be executed into a target contract task queue corresponding to a target intelligent contract according to the target intelligent contract identifier contained in the transaction to be executed, wherein the target intelligent contract identifier is the target intelligent contract identifier, the blockchain node comprises contract task queues respectively corresponding to intelligent contracts in at least one intelligent contract, the quantity determining unit is used for determining the quantity of lightweight virtual machines required to be started for the intelligent contract according to the quantity of the transaction to be executed contained in the contract task queue corresponding to the intelligent contract aiming at each intelligent contract in the blockchain node, and starting the lightweight virtual machines containing the intelligent contracts according to the quantity of the intelligent contract to be started, and independently operating the system by pulling the lightweight virtual machines from the contract task queue corresponding to the intelligent contract according to the quantity of the intelligent contract, and operating the system is enabled to be executed by the system.

In some embodiments of the application, based on the foregoing scheme, the sum of the number of lightweight virtual machines launched for each smart contract on the blockchain node is a fixed value.

In some embodiments of the application, based on the foregoing scheme, the apparatus further comprises a dynamic adjustment unit, and after the lightweight virtual machines including the smart contracts are started on the blockchain node according to the number of the lightweight virtual machines required to be started for each of the at least one smart contract, the dynamic adjustment unit is configured to perform a lightweight virtual machine dynamic adjustment step for each smart contract, respectively, the lightweight virtual machine dynamic adjustment step including acquiring a length of a contract task queue corresponding to a 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.

In some embodiments of the present application, based on the foregoing solution, the dynamic adjustment unit is configured to increase the number of lightweight virtual machines corresponding to the current smart contract if the contract task queue is determined to be a long queue according to a comparison result of the length of the contract task queue and a long queue length threshold, and decrease the number of lightweight virtual machines corresponding to the current smart contract if the contract task queue is determined to be a short queue according to a comparison result of the length of the contract task queue and a short queue length threshold, where the long queue length threshold is greater than the short queue length threshold.

In some embodiments of the application, based on the scheme, the device further comprises a contract task queue creation unit, wherein before adding the transaction to be executed to a target contract task queue corresponding to a target intelligent contract on a blockchain node according to a target intelligent contract identifier contained in the transaction to be executed, the contract task queue creation unit is used for acquiring the intelligent contract in a binary file form from the transaction to be executed if the transaction to be executed is the transaction for creating the intelligent contract, and creating the contract task queue corresponding to the intelligent contract in the binary file form on the blockchain node.

In some embodiments of the present application, based on the foregoing solution, the starting and executing unit is configured to obtain a kernel image and a root file system image that are prepared in advance, copy the smart contract in the binary file form into the root file system image to obtain a new root file system image, and start a lightweight virtual machine that includes the smart contract based on the new root file system image and the kernel image.

In some embodiments of the application, the device further comprises an acquisition unit and a block generation unit, wherein before adding the transaction to be executed to a target contract task queue corresponding to a target intelligent contract on a blockchain node, the acquisition unit is used for adding the received transaction to a transaction pool, acquiring a plurality of transactions for generating a new block from the transaction pool, selecting one transaction from the plurality of transactions each time as the transaction to be executed, wherein the determination of the number of lightweight virtual machines required to be started for the intelligent contract is performed under the condition that all transactions for generating the new block are added to a corresponding contract task queue, and after pulling and executing the transaction to be executed from the contract task queue corresponding to the intelligent contract through the lightweight virtual machines, the block generation unit is used for generating the new block according to all transactions to be executed for generating the new block when all transactions to be executed for generating the new block are completed.

In some embodiments of the application, based on the foregoing, the apparatus further comprises a verification unit, and before adding the received transaction to the transaction pool, the verification unit is configured to perform signature verification and authority verification on the transaction request, when the block link point receives the transaction request carrying the transaction sent by the client, where adding the received transaction to the transaction pool is performed if the transaction request passes the signature verification and the authority verification.

In some embodiments of the application, the apparatus further comprises a consensus unit for sending the new block to other blockchain nodes in the blockchain network for consensus in the blockchain network after generating a new block according to all transactions to be performed for generating the new block, and storing the new block in the blockchain node if the consensus for the new block passes.

According to an aspect of an embodiment of the present application, there is provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method of executing a transaction in a blockchain network as described in the above embodiments.

According to one aspect of an embodiment of the present application, there is provided an electronic device including one or more processors, and a storage device for storing one or more programs, which when executed by the one or more processors, cause the one or more processors to implement a method of executing transactions in a blockchain network as described in the above embodiments.

According to an aspect of an embodiment of the present application, there is provided a computer program product including computer instructions stored in a computer-readable storage medium, from which computer instructions a processor of a computer device reads, the processor executing the computer instructions, causing the computer device to perform a method of executing a transaction in a blockchain network as described in the above embodiments.

According to the technical scheme provided by the embodiments of the application, the contract task queues corresponding to the intelligent contracts are respectively arranged on the blockchain nodes, the transactions to be executed are added into the corresponding target contract task queues according to the target intelligent contract identifications contained in the transactions to be executed, then, a lightweight virtual machine containing the intelligent contracts is created for each intelligent contract, the transactions are pulled and executed from the contract task queues corresponding to the intelligent contracts through the lightweight virtual machine corresponding to the intelligent contracts, the number of the lightweight virtual machines required to be started for each intelligent contract is determined according to the number of the transactions to be executed contained in the contract task queues corresponding to each intelligent contract, therefore, the concurrency performance is effectively improved, high concurrency can be smoothly realized when the number of the transactions is large, meanwhile, the lightweight virtual machine is pulled and executed by using an independent operating system kernel and a root file system, the resource isolation and security of different transactions are effectively enhanced, in addition, compared with the starting time of a common container, the lightweight virtual machine is not required to be switched, the starting time is short, the virtual machine is required to be started, and the virtual machine is more fast, and the starting time is shortened, therefore, the starting speed of the virtual machine is required to be switched, and the virtual machine is fast, and the starting time is required to be started.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is evident that the drawings in the following description are only some embodiments of the present application and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art. In the drawings:

FIG. 1 shows a schematic diagram of an exemplary system architecture to which the technical solution of an embodiment of the application may be applied;

FIG. 2 illustrates a flow chart of a method of executing a transaction in a blockchain network in accordance with an embodiment of the application;

FIG. 3 shows a flowchart of steps preceding step 260, details of step 270, and steps following step 280 in the embodiment of FIG. 2, according to one embodiment of the application;

FIG. 4 illustrates an architecture diagram of a blockchain node in accordance with an embodiment of the application;

FIG. 5 shows a flowchart of steps preceding step 260 in the embodiment of FIG. 2, according to one embodiment of the present application;

FIG. 6 illustrates a flowchart of starting a lightweight virtual machine containing a smart contract on a blockchain node in accordance with an embodiment of the application;

FIG. 7 shows a flowchart of steps subsequent to step 280 in the embodiment of FIG. 2, in accordance with one embodiment of the present application;

8A-8C illustrate a flow diagram of installing and running a smart contract on a blockchain node in accordance with an embodiment of the application;

9A-9C illustrate a flow diagram of initiating and executing a generic transaction, according to one embodiment of the application;

FIGS. 10A-10B illustrate a flow diagram of a FIRECRACKER-based container dynamic scheduling flow, according to one embodiment of the application;

FIG. 11 illustrates a block diagram of an execution device of a transaction in a blockchain network in accordance with an embodiment of the application;

fig. 12 shows a schematic diagram of a computer system suitable for use in implementing an embodiment of the application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments can be embodied in many different forms and should not be construed as limited to the examples set forth herein, but rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the application may be practiced without one or more of the specific details, or with other methods, components, devices, steps, etc. In other instances, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the application.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

In the related art, public chains and federated chains are two common types of blockchains. Public chains including ethernet and alliance chains including chandelier and HYPERLEDGER FABRIC all use smart contract technology, however, the intelligence they provide has the following disadvantages at about the time of use:

the solidity on-line date of the ethernet is charged for each operation, and too complex code logic and calculation process consume a lot of cost, and the contract language is not rich enough, so that a certain limit is provided.

In federation chains such as channa chains and HYPERLEDGER FABRIC, intelligent contract execution does not actually consume money, so native languages (e.g., golang and Java) can be used, but these languages usually occupy a process, can directly operate memory, occupy a network, consume a CPU, etc., and can access the counterpart's file system or network. One contract of the long security chain starts a process, and one contract transaction logic is too complex to preempt most of the resources, resulting in slow execution of other contract transactions. HYPERLEDGER FABRIC adopts a mode of a Docker container, but the Docker container is large in storage and resource occupation, and is relatively heavy in starting time.

Therefore, the application firstly provides a method for executing transactions in a blockchain network. The execution method of the transaction in the blockchain network provided by the embodiment of the application can overcome the defects, can solve the problem of resource isolation of different contract transactions, can solve the problem of slow starting time of a Docker container, is more friendly in concurrency, and can also improve the usability of executing the transaction based on intelligent contracts.

Fig. 1 shows a schematic diagram of an exemplary system architecture to which the technical solution of an embodiment of the present application may be applied. As shown in fig. 1, the system architecture 100 may include a user terminal 110 and a blockchain network 130, where the blockchain network 130 includes a plurality of blockchain nodes, and specifically may 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, where the user terminal 110 and the blockchain network 130 are connected by a communication link 120, and a communication connection is established between any two blockchain nodes, so that the user terminal 110 may communicate with any one blockchain node in the blockchain network 130, and any two blockchain nodes in the blockchain network 130 may also communicate with each other. Each blockchain node has a set of lightweight virtual machines and a contract task queue corresponding to the intelligent contract deployed thereon, each blockchain node has a blockchain stored thereon, and user terminal 110 has a client deployed thereon that can be used to access blockchains located on blockchain nodes in blockchain network 130. When the method for executing a transaction in a blockchain network provided by the present application is applied to the system architecture shown in fig. 1, a process may be that, firstly, a user sends a transaction request including the transaction to a first blockchain node 131 in the 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 intelligent contract identifier according to the received intelligent contract identifier in the transaction, and adds the transaction to the contract task queue, and then, pulls and executes the transaction from the contract task queue through a certain lightweight virtual machine in a set of lightweight virtual machines corresponding to the intelligent contract identifier.

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 from the smart contract included in the transaction and adds the transaction to the new contract task queue.

In some embodiments of the present application, each blockchain node is deployed with a transaction pool, each blockchain node adds the received transaction to the transaction pool, and each blockchain node fetches the transaction from the transaction pool that needs to be added to the contract task queue.

In some embodiments of the application, each blockchain node adds a transaction in the transaction request to the transaction pool if the received transaction request completes validation.

It should be understood that the number of user terminals in fig. 1 and blockchain nodes in the blockchain network is merely illustrative. The number of the blockchain nodes in the blockchain network can be arbitrary, that is, the number of the blockchain nodes in the blockchain network can be more than 5 or less than 5.

It should be noted that fig. 1 shows only one embodiment of the present application. Although in the solution of the embodiment of fig. 1, the blockchain nodes in the blockchain network are servers, and the user terminals are desktops, in other embodiments of the application, the blockchain nodes and the user terminals may be various types of terminal devices such as notebooks, desktops, tablets, vehicle terminals, portable wearable devices, workstations, etc., while in the solution of the embodiment of fig. 1, the device types of the blockchain nodes in the blockchain network are the same, in other embodiments of the application, different types of devices may be used for the blockchain nodes in the blockchain network, and the transaction performed on one blockchain node is obtained directly from the user terminal by the blockchain node, but in other embodiments of the application, the transaction performed on one blockchain node may also be obtained from other blockchain nodes by the blockchain node, for example, when the resources of one blockchain node are insufficient, the received transaction may be forwarded to the other blockchain node for execution. The embodiments of the present application should not be limited in any way, nor should the scope of the application be limited in any way.

It is easy to understand that the method for executing the transaction in the blockchain network provided by the embodiment of the application is generally executed by a server, and correspondingly, the executing device for the transaction in the blockchain network is generally arranged in the server. However, in other embodiments of the present application, the terminal device may also have a similar function as the server, so as to execute the execution scheme of the transaction in the blockchain network provided by the embodiment of the present application.

Therefore, the embodiment of the application can be applied to a terminal or a server. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligent platforms. The terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the present application is not limited herein.

The scheme of the embodiment of the application can be applied to the field of block chain. Blockchains are novel application modes of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. The blockchain (Blockchain), essentially a de-centralized database, is a string of data blocks that are generated in association using cryptographic methods, each of which contains information from a batch of network transactions for verifying the validity (anti-counterfeit) of its information and generating the next block. The blockchain may include a blockchain underlying platform, a platform product services layer, and an application services layer.

The blockchain underlying platform may include processing modules for user management, basic services, smart contracts, and operational monitoring. The system comprises a user management module, a base service module, a public and private key generation (account management), a key management and a corresponding relation maintenance (authority management) of a user real identity and a blockchain address, and the like, wherein the user management module is responsible for identity information management of all blockchain participants, comprises maintenance of public and private key generation (account management), key management, maintenance of a corresponding relation between the user real identity and the blockchain address (authority management) and the like, and provides rule configuration (wind control audit) of risk control under the authorized condition, the base service module is deployed on all blockchain node devices and is used for verifying the validity of service requests, recording the valid requests after the valid requests are completed, for a new service request, the base service firstly carries out interface adaptation analysis and authentication processing (interface adaptation), then carries out encryption (consensus management) on the service information, and carries out recording and storage on a shared account book (network communication) after the encryption, the intelligent contract module is responsible for registration issuing of contracts and contract triggering and contract execution, developers can define contract logic through programming languages, issue contract logic on the blockchain (contract registering), call keys or other event triggering execution according to contract logic, and complete contract logic, and provide updating and upgrading main function monitoring and main contract updating function, and monitoring device in real-time monitoring and monitoring conditions in a cloud monitoring and monitoring device.

The platform product service layer provides basic capabilities and implementation frameworks of typical applications, and developers can complete the blockchain implementation of business logic based on the basic capabilities and the characteristics of the superposition business. The application service layer provides the application service based on the block chain scheme to the business participants for use.

The implementation details of the technical scheme of the embodiment of the application are described in detail below:

Fig. 2 illustrates a flow chart of a method of executing a transaction in a blockchain network according to an embodiment of the application, which may be executed by any blockchain node in the blockchain network, which may be any device capable of computing and processing, such as a user terminal or cloud server, including but not limited to a cell phone, a computer, a smart voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, a smart watch, etc. Referring to fig. 2, the method for executing the transaction in the blockchain network at least includes the following steps:

Step 260, adding the transaction to be executed to a target contract task queue corresponding to the target intelligent contract on the blockchain node according to the target intelligent contract identifier included in the transaction to be executed, wherein the intelligent contract identifier of the target intelligent contract is the target intelligent contract identifier, and the blockchain node includes contract task queues respectively corresponding to each intelligent contract in at least one intelligent contract.

Step 270, for each of the at least one smart contract, determining a number of lightweight virtual machines that need to be started for the smart contract based on a number of transactions to be performed contained in a contract task queue corresponding to the smart contract.

Step 280, starting the lightweight virtual machines containing the intelligent contracts on the blockchain node according to the number of the lightweight virtual machines required to be started for each intelligent contract in at least one intelligent contract, and pulling and executing the transaction to be executed from a contract task queue corresponding to the intelligent contract through the lightweight virtual machines, wherein operating system components used by the lightweight virtual machines are independent operating system kernels and root file systems.

Before describing the above steps in detail, the steps that need to be performed before step 260 are described.

Fig. 3 shows a flowchart of the steps preceding step 260, the details of step 270, and the steps following step 280 in the embodiment of fig. 2, according to one embodiment of the application. Referring to fig. 3, before adding a transaction to be executed to a target contract task queue corresponding to a target intelligent contract on a blockchain node, the method for executing the transaction in the blockchain network may include the following steps:

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

It will be readily appreciated that the transactions received by the blockchain node are in the form of transaction information.

A Transaction Pool (also called Mempool) of blockchains refers to a collection of transactions waiting to be written to a block that are not packed into the block. In a blockchain network, each node maintains a pool of transactions for storing new transactions generated by users. When a user initiates a transaction, the transaction is broadcast throughout the network. If the transaction meets the transaction rules and validation rules of the blockchain network, the transaction is added to the transaction pool of the node. Transactions in the transaction pool need to wait to be verified and validated before waiting to be packed into blocks. By using the transaction pool technology, the efficiency and performance of the blockchain can be improved while the smooth processing of the transaction can be ensured.

FIG. 4 illustrates an architecture diagram of a blockchain node in accordance with an embodiment of the present application. Next, a scheme of an embodiment of the present application will be described with reference to fig. 4. Referring to fig. 4, the architecture includes a network module, which is a module for performing network interaction outside a block chain node pair, and includes a transaction uplink sub-module and a data query sub-module, wherein the transaction uplink sub-module is used for receiving a transaction sent to the block chain node by a user through a client, and the data query sub-module is used for receiving a query statement sent by the user and directly querying data in a block chain.

In one embodiment of the application, the method for executing the transaction in the blockchain network may further comprise the step of performing signature verification and authority verification on the transaction request when the blockchain link point receives the transaction request carrying the transaction sent by the client, before adding the received transaction to the transaction pool, wherein adding the received transaction to the transaction pool is performed under the condition that the transaction request passes the signature verification and the authority verification.

The blockchain network comprises a plurality of blockchain nodes, and the blockchain node receiving the transaction request can be any blockchain node in the blockchain network, such as the blockchain node nearest to the requester, or the blockchain node randomly determined from the blockchain network.

By carrying out signature verification and authority verification on the transaction request, the validity of the transaction request can be verified, illegal transactions are prevented from being added into a transaction pool by mistake, and illegal transactions can be prevented from being uplink by mistake.

In one embodiment of the application, the transaction request is subjected to signature verification by receiving a transaction request and a digital signature which are sent by a client and carry transactions, wherein the digital signature is obtained by encrypting a digest of the transaction request by a requester of the transaction request by using a private key of the requester, decrypting the digital signature by using a public key of the requester of the transaction request to obtain a first digest, carrying out hash operation on the transaction request by using a hash function to obtain a second digest, determining that the signature verification is passed if the first digest is consistent with the second digest, and otherwise determining that the signature verification is not passed.

The transaction request can contain the identity of the requester, and the authority verification can be performed on the transaction request by judging whether the transaction request is matched with the authority corresponding to the identity. The identity of the requesting party may be the public key of the requesting party, or may be any other type of ID capable of uniquely identifying a requesting party.

Specifically, whether the authority verification is passed or not is judged by judging whether the requester of the transaction request is in a blacklist, whether the authority is available for transmitting the transaction, whether the authority is available for calling a method for creating the contract, and the like.

With continued reference to fig. 4, the architecture further includes an authentication module and a transaction pool module, where the authentication module includes a signature verification sub-module and an authority verification sub-module, the signature verification is performed by the signature verification sub-module, the authority verification is performed by the authority verification sub-module, and the transaction pool module is configured to cache the received transaction in the transaction pool.

In step 220, a plurality of transactions for generating a new block are obtained from the pool of transactions.

When a new block is to be generated, a batch of transactions for generating the new block is obtained from the transaction pool to generate the new block based on the batch of transactions.

With continued reference to FIG. 4, the architecture further includes a block scheduling module for scheduling transactions in the transaction pool and generating new blocks. The block scheduling module is responsible for retrieving a plurality of transactions from the transaction pool for generating new blocks.

In step 230, one transaction at a time is selected from the plurality of transactions as a transaction to be performed.

And taking each transaction as a transaction to be executed, and sequentially executing subsequent operations on each transaction to be executed until all transactions for generating new blocks are added to the corresponding contract task queues.

The block scheduling module of fig. 4 is configured to traverse each of the plurality of transactions in turn.

Fig. 5 shows a flow chart of steps preceding step 260 in the embodiment of fig. 2 according to an embodiment of the present application. Referring to fig. 5, 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 included in the transaction to be executed, the method for executing the transaction in the blockchain network may further include the following steps:

in step 240, if the transaction to be performed is a transaction for creating a smart contract, a smart contract in the form of a binary file is obtained from the transaction to be performed.

One transaction to be performed may be a transaction for creating a smart contract, or may be a normal transaction, i.e., a transaction that does not require the creation of a smart contract, which is typically a transaction that requires execution of a transaction through a created smart contract.

Smart contract (Smart contract) is a computer protocol that aims to propagate, verify, or execute contracts in an informative manner. Smart contracts allow trusted transactions to be made without a third party, which transactions are irreversible.

If a smart contract in binary form is included in a transaction to be performed, it is a transaction for creating a smart contract.

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

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

The block scheduling module of fig. 4 creates a new contract task queue corresponding to the smart contract in the event that the transaction to be performed is a transaction for creating the smart contract.

The steps shown in fig. 2 are described in detail below.

In step 260, according to the target intelligent contract identifier included in the transaction to be executed, the transaction to be executed is added to a target contract task queue corresponding to the target intelligent contract on the blockchain node, the intelligent contract identifier of the target intelligent contract is the target intelligent contract identifier, and the blockchain node includes a contract task queue corresponding to each intelligent contract in at least one intelligent contract.

With continued reference to fig. 4, the block scheduling module specifically includes a transaction distribution scheduling sub-module, where the transaction distribution scheduling sub-module includes a contract task queue corresponding to each intelligent contract, and all tasks corresponding to the corresponding intelligent contracts are stored in the contract task queue. The block scheduling module is responsible for placing the transaction to be executed into the transaction distribution scheduling sub-module, and the transaction distribution scheduling sub-module schedules and distributes the transaction to be executed into the corresponding contract task queue for execution.

The smart contract identification included in the transaction to be performed is used to uniquely identify one smart contract. The transaction to be executed may be a normal transaction, in which case the smart contract identifier included in the transaction to be executed is used to identify the smart contract used to execute the transaction to be executed, and the transaction to be executed may also be a transaction used to create the smart contract.

In this step, the transaction to be executed is added to the corresponding contract task queue according to the intelligent contract required for executing the transaction to be executed. Transactions that are added to the contract task queue may also be referred to as tasks.

Before the transaction to be performed is obtained, a contract task queue corresponding to one or more intelligent contracts may exist on the blockchain node. Each intelligent contract corresponds to a contract task queue.

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

Before performing step 270, the method may further include determining whether all transactions for generating a new chunk have been added to the corresponding contract task queue.

With continued reference to fig. 3, for each of the at least one smart contract, determining, according to the number of transactions to be performed included 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 may specifically include the following steps:

in step 270', in the case that all transactions for generating new blocks are added to the corresponding contract task queues, for each of the at least one smart contract, the number of lightweight virtual machines that need to be started for the smart contract is determined according to the number of transactions to be performed contained in the contract task queue corresponding to the smart contract.

That is, determining the number of lightweight virtual machines that need to be started for the smart contract is done with all transactions for creating new blocks added to the corresponding contract task queues.

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

The number of the lightweight virtual machines started on one blockchain node can be always controlled to be a fixed value, and the total resources used by the blockchain node are ensured to be unchanged, so that resource management is effectively realized.

In one embodiment of the application, the method for determining the number of the lightweight virtual machines required to be started for the intelligent contracts according to the number of the transactions to be executed contained in the contract task queues corresponding to the intelligent contracts comprises the steps of determining the sum of the numbers of the transactions to be executed contained in each contract task queue, determining the number proportion of the transactions to be executed contained in each contract task queue according to the sum of the numbers, and taking the product of the number proportion corresponding to the current intelligent contracts and a fixed value as the number of the lightweight virtual machines required to be started for the current intelligent contracts.

Since the product of the number duty cycle and the fixed value may be a fraction, the rounding operation may be performed during actual computation, only by making the sum of the number of lightweight virtual machines started for each smart contract on the blockchain node a fixed value.

In one embodiment of the application, determining the number of lightweight virtual machines to be started for the smart contracts according to the number of transactions to be executed contained in a contract task queue corresponding to the smart contracts comprises determining the logic complexity of each smart contract, determining the product of the logic complexity of each smart contract and the number of transactions to be executed contained in the contract task queue of the smart contract for each smart contract, determining the sum of the products of the numbers corresponding to each smart contract, determining the product of the number corresponding to the current smart contract and the product of the number corresponding to the current smart contract as the number of lightweight virtual machines to be started for the current smart contract.

The logic complexity may 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.

In the embodiment of the application, the logic complexity of the intelligent contract is further considered when the number of the lightweight virtual machines required to be started for the intelligent contract is determined, so that the number of the lightweight virtual machines required to be started for the intelligent contract can be more accurately determined, and further transactions to be executed contained in each contract task queue can be efficiently and synchronously executed.

In step 280, for each of the at least one smart contract, starting a lightweight virtual machine comprising the smart contract on the blockchain node according to the number of lightweight virtual machines required to be started for the smart contract, and pulling and executing a transaction to be executed from a contract task queue corresponding to the smart contract through the lightweight virtual machine, wherein an operating system component used by the lightweight virtual machine is an independent operating system kernel and root file system.

Lightweight virtual machines (microVM) are created based on FIRECRACKER, which may also be referred to as contracts FIRECRACKER containers in embodiments of the application. FIRECRACKER is a lightweight virtualization technology based on KVM (Kernel-based Virtual Machine ) aimed at providing secure isolation for serverless and container workloads. FIRECRACKER can start a new micro-virtual machine within hundreds of microseconds, and is very suitable for running tasks in parallel on a large scale. FIRECRACKER have lower resource utilization and startup time than conventional virtual machine and container technologies.

FIRECRACKER has the following advantages:

1. Isolation performance FIRECRACKER provides a stronger isolation performance because it uses a lightweight virtual machine (microVMs) to run the workload. This means that each task runs in its own virtual machine, completely isolated from other tasks and host systems.

2. The starting time is FIRECRACKER, the starting time is very short, and a new micro-virtual machine can be started in hundreds of microseconds. This makes FIRECRACKER well suited for scenarios requiring fast start and stop of tasks, such as serverless computing.

3. Security FIRECRACKER the design focuses on security, which uses a variety of techniques to limit virtual machine access to host system resources. This makes FIRECRACKER more resilient than container technology in the face of security threats.

The container is a stand-alone operating environment in which applications may be run. The container is created based on the image, contains all the content in the image, and can run applications in it. The container is lightweight, can be quickly started and stopped, and can be operated in different environments, such as development, testing, and production environments. Container technology can help developers build, test, and deploy applications more quickly.

The inventors of the present application have found that FIRECRACKER provides significant advantages in terms of barrier properties, start-up time, safety and ease of use over conventional Docker containers. Therefore FIRECRACKER is better suited for scenarios requiring strong isolation performance and fast start-up time, and therefore it is better suited for execution as a blockchain contract process.

All lightweight virtual machines that are started on a blockchain node constitute a pool of contract containers. A pool of contract containers is a blockchain technology-based intelligent contract execution environment that can automatically manage and schedule multiple intelligent contract containers to achieve efficient intelligent contract execution. A contract container pool is typically made up of multiple smart contract containers, each of which can independently execute smart contracts. When a new smart contract needs to be executed, the contract container pool automatically selects an available container to execute the contract, thereby realizing efficient execution of the smart contract.

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, thereby avoiding performance bottlenecks and failure risks of a single container. In addition, the contract container pool can provide better resource utilization, because the container quantity can be dynamically adjusted according to actual requirements, thereby avoiding the problems of resource waste and over-allocation.

With continued reference to FIG. 4, the architecture further includes a virtual machine module including a pool of contract FIRECRACKER containers (pool of contract containers) including a number of contract FIRECRACKER containers (lightweight virtual machines), the number of contract FIRECRACKER containers included in the pool of contract FIRECRACKER containers may be fixed, each contract FIRECRACKER container being a running state of a contract image, each contract FIRECRACKER container including a contract process and a Linux kernel, the contract process being a process that starts a contract binary program, the Linux kernel being a running time of a basic operating system Linux kernel required by the contract FIRECRACKER container.

The contract FIRECRACKER container pool in the virtual machine module is responsible for determining the number of lightweight virtual machines required to be started for the intelligent contract, starting the corresponding number of lightweight virtual machines containing the intelligent contract on the blockchain node, and the block scheduling module schedules the contract FIRECRACKER container to execute tasks in the contract task queue. The contract FIRECRACKER container pulls the transactions in the contract task queue and performs the transactions by invoking the smart contract.

FIG. 6 illustrates a flowchart of starting a lightweight virtual machine containing a smart contract on a blockchain node in accordance with an embodiment of the application. Referring to FIG. 6, starting a lightweight virtual machine containing a smart contract on a blockchain node may include the steps of:

in step 610, a kernel image and a root file system image prepared in advance are acquired.

An image is a collection of static files that contains the operating system, applications, and related dependencies, which can be used to create a container. The mirror is typically read-only and can be used by multiple containers simultaneously.

The kernel image is a static file set related to a kernel of an operating system, and the root file system image is a static file set related to a root file system of the operating system.

Specifically, an API (Application Programming Interface, application program interface) or related tools (e.g., firectl) of FIRECRACKER are used to create and run a microVM.

Firectl is a tool for guiding and running containers that provides a convenient way to create and manage containers. The following is an example of creating and running one microVM using the firectl tool.

First, FIRECRACKER and firectl are installed.

Next, a kernel image and a root file system image are prepared.

The kernel image may be downloaded from the code repository of FIRECRACKER by the following commands:

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

the purpose of this command is to download files from the specified URL https:// s3. XXX.com/XXX.XXX/img/hello/kernel/hello-vmlinux.bin using silent mode and display error messages when the download fails and save the downloaded file as a kernel image named hello-vmlinux.bin.

The root file system image may be commanded from the code repository of FIRECRACKER by:

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

The effect of this command is https:// s3. XXX.com/XXX.XXX/img/hello/fsfiles/he llo-rootfs.ext4-designated URL downloads the file using silent mode and displays an error message when the download fails and saves the downloaded file as a root file system image named hello-rootfs.ext4.

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

Then, the smart contract in binary file form needs to be copied to the root file system image, which can be mounted and copied using the following commands:

A directory with a path of/tmp/my-rootfs is created by using a mkdir/tmp/my-rootfs command, then the hello-rootfs.ext4/tmp/my-rootfs command is used for mounting hello-rootfs.ext4 as a virtual disk under the/tmp/my-rootfs directory, then the binary file-form intelligent contract named as binary under the path of/path/to/you is copied to the/tmp/my-rootfs/path/input directory by using a sudo mount-o loop hello-rootfs command, and is named as rootfs, and finally the/tmp/my-rootfs command is used for unloading the/tmp/my-rootfs.

Steps 610 and 620 may be steps performed each time a contract task queue corresponding to a binary-form intelligent contract is created on a blockchain node.

With continued reference to FIG. 4, the virtual machine module further includes a contract FIRECRACKER mirror compiler and a contract FIRECRACKER mirror repository, the contract FIRECRACKER mirror compiler is configured to package the intelligent contracts in binary file form to obtain a new root file system mirror, the virtual machine module places the new root file system mirror and the kernel mirror into the contract FIRECRACKER mirror repository, and the mirrors can be pulled from the contract FIRECRACKER mirror repository at any time and a lightweight virtual machine can be started based on the mirrors.

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

Firectl can be used to start a lightweight virtual machine and execute a smart contract in binary form by:

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

kernel represents kernel used for starting lightweight virtual machine, root-drive represents root file system used for starting lightweight virtual machine, kernel-opts is used for specifying parameters transferred to kernel. The parameter con= ttyS designates the serial device as a console, wherein ttyS0 is the first serial device. This means that the output of the system (like log and error message) will be displayed by the serial device, and that the parameter reboot=k tells the system in what way to restart when a kernel crash occurs. In this case, k indicates that the system should use the kernel to restart. panic = 1 this parameter sets the behavior of the system when a kernel crash occurs. In this case, 1 represents restarting the system immediately after the kernel crashes, rather than waiting for the user to manually restart. The PCI bus is disabled by the parameter pci=off, which is a bus standard for connecting hardware devices. Disabling PCI may enhance system security, particularly in certain special application scenarios. The my_binary_path is a path to copy the binary file of the smart contract into the root file system image.

In the embodiment of the application, by carrying out mirror image packaging of intelligent contracts based on the mode, all contract binary files can be adapted, and the contract transaction can be carried out in a mode that the existing blockchain is directly switched to FIRECRACKER.

FIG. 7 shows a flowchart of steps subsequent to step 280 in the embodiment of FIG. 2, according to one embodiment of the application. Referring to fig. 7, after the lightweight virtual machines including the smart contracts are started on the blockchain node according to the number of lightweight virtual machines required to be started for each of the at least one smart contract, the method for executing the transaction in the blockchain network may further include the steps of:

In step 2100, a lightweight virtual machine dynamic adjustment step is performed separately for each smart contract.

The step of adjusting the lightweight virtual machines may include obtaining a length of a 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.

In one embodiment of the application, the method for adjusting the number of the lightweight virtual machines corresponding to the current intelligent contract according to the length of the contract task queue comprises the steps of increasing the number of the lightweight virtual machines corresponding to the current intelligent contract if the contract task queue is determined to be a long queue according to the comparison result of the length of the contract task queue and a long queue length threshold value, and reducing the number of the lightweight virtual machines corresponding to the current intelligent contract if the contract task queue is determined to be a short queue according to the comparison result of the length of the contract task queue and a short queue length threshold value, wherein the long queue length threshold value is larger than the short queue length threshold value.

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 intelligent contract is increased, and 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 intelligent contract is decreased.

The above-mentioned dynamic adjustment process for the number of lightweight virtual machines may be performed periodically, and the total number of lightweight virtual machines started on one blockchain node may be kept unchanged throughout the adjustment process.

The embodiment of the application realizes the dynamic allocation of the resources under the condition of fixing the total resources, and can avoid the condition of integral lag caused by uneven execution speed when different contract transactions have larger difference.

With continued reference to FIG. 3, after pulling and executing the transaction to be executed from the contract task queue corresponding to the smart contract by the lightweight virtual machine, the method may further include the steps of:

in step 290, when all transactions to be performed for generating a new chunk are completed, a new chunk is generated according to all transactions to be performed for generating a new chunk.

With continued reference to fig. 4, the block scheduling module further includes a block generating sub-module, and after all transactions to be executed for generating a new block are completed, the block generating sub-module generates the new block.

In one embodiment of the application, after generating a new block based on all transactions to be performed for generating the new block, the method may further include the steps of sending the new block to other blockchain nodes in the blockchain network for consensus in the blockchain network, and storing the new block in the blockchain node if the consensus for the new block passes.

With continued reference to fig. 4, the architecture includes a consensus module and a storage module, where the storage module includes a status database sub-module and a block ledger sub-module. The consensus module performs consensus voting on the new block by means of PoW (Proof of Work), poS (Proof of interest) and the like, and after the consensus passes, the text file of the new block is stored by the block account sub-module, so that the new block is uplink. The status database submodule is used for storing the latest variable status, such as the latest balance after account transfer.

8A-8C illustrate a flow diagram of installing and running a smart contract on a blockchain node in accordance with an embodiment of the application. The same circular nodes in fig. 8A-8C indicate the same locations in the flow. 8A-8C, installing and running a smart contract on a blockchain node may include the following:

step 810, beginning.

Step 820, the user is compiling the local smart contract into a binary file and starting a client accessing the blockchain.

In step 830, the user defines parameters of the contract initialization method, such as account name and balance in the transfer contract.

The user merges the request and its signature onto the blockchain node, step 840.

In step 850, the blockchain node authentication module performs signature verification.

Step 860, signature verification is passed?

If so, go to step 880, otherwise go to step 870.

At step 870, the blockchain node returns an error that fails the signature verification.

The blockchain node returns error information to the client indicating that the signature verification failed. After the completion of the present step, the process goes to step 8300.

In step 880, the blockchain node authentication module performs rights verification, such as whether the user is in a blacklist, whether there is rights to invoke the method of creating the contract.

Step 890, is rights verified passed?

If so, go to step 8110, otherwise go to step 8100.

In step 8100, the blockchain node returns an error that the rights verification failed.

The blockchain node returns error information to the client indicating that the rights verification failed. After the completion of the present step, the process goes to step 8300.

In step 8110, the transaction pool module receives and places the transaction into a transaction pool.

In step 8120, the block scheduling module prepares to generate a new block, and obtains a batch of transactions from the pool.

In step 8130, the block scheduling module traverses the transactions in sequence.

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

It is determined whether the current transaction is used to create a smart contract. If so, go to step 8150, otherwise go to step 8180.

In step 8150, the block scheduling module creates a new contract task queue.

At step 8160, the contract FIRECRACKER mirror compiler of the virtual machine module packages a new mirror for the contract.

In step 8170, the virtual machine module places the images in a contract FIRECRACKER image repository, which can be pulled up at any time.

The image may be pulled from the contract FIRECRACKER image repository at any time to launch the contract FIRECRACKER container based on the image.

In step 8180, the block dispatch module places the transaction in a corresponding contract task queue of the transaction dispatch module.

Step 8190, is all transactions deposited complete?

A determination is made as to whether all transactions for generating a new block have been deposited into the corresponding contract task queue. If so, go to step 8200, otherwise go to step 8130.

In step 8200, the contract FIRECRACKER container pool module of the virtual machine module starts different numbers of containers for different contracts according to the task number of the contract task queue.

For smart contracts, FIRECRACKER containers are started, the number of containers started FIRECRACKER being determined by the number of tasks of the corresponding contract task queue.

In step 8230, the block scheduling module schedules the contract FIRECRACKER container to execute the tasks in the contract task queue.

In step 8230, the contract FIRECRACKER container pulls the transaction in the queue and performs the transaction.

In step 8230, the number of containers per contract may be dynamically adjusted during execution.

In step 8240, the block scheduling module generates a new block after all transactions are performed.

In step 8250, after the generation is completed, the node sends the block to other block chain nodes for consensus.

In step 8260, all block link points are identified.

Step 8270, is consensus passed?

If the consensus passes, go to step 8290, otherwise go to step 8280.

Step 8280, a result of failure of the consensus check is returned.

The blockchain node returns information to the client indicating that the consensus check failed. After the completion of the present step, the process goes to step 8300.

Step 8290 stores the block and updates the data of the status database.

Step 8300 ends.

Fig. 9A-9C illustrate a flow diagram for initiating and executing a generic transaction according to one embodiment of the application. The same circular nodes in fig. 9A-9C indicate the same locations in the flow. Referring to fig. 9A-9C, initiating and executing a normal transaction may include the following:

Step 910, begin.

In step 920, the user initiates a client that accesses the blockchain.

At step 930, the user defines the invoked contract, method, and parameters such as transfer contract, transfer, both account name, and transfer amount.

At step 940, the user merges the request and its signature onto the blockchain node.

In step 950, the blockchain node authentication module performs signature verification.

Step 960, is signature verification passed?

If so, go to step 980, otherwise go to step 970.

At step 970, the blockchain node returns an error that fails the signature verification.

The blockchain node returns error information to the client indicating that the signature verification failed. After the completion of the present step, the process goes to step 9300.

In step 980, the blockchain node authentication module performs rights verification, e.g., whether the user is in a blacklist, whether there is a method of rights to invoke a contract.

Step 990, is rights verified passed?

If so, go to step 9110, otherwise go to step 9100.

In step 9100, the blockchain node returns an error that fails the validation of the rights.

The blockchain node returns error information to the client indicating that the rights verification failed. After the completion of the present step, the process goes to step 9300.

In step 9110, the transaction pool module receives the transaction and places it in a transaction pool.

In step 9120, the block scheduling module prepares to generate a new block, retrieving a batch of transactions from the pool.

In step 9130, the block scheduling module traverses the transactions sequentially.

Step 9140, is the current transaction a transaction to create a contract?

It is determined whether the current transaction is used to create a smart contract. If so, go to step 9150, otherwise go to step 9180.

In step 9150, the block scheduling module creates a new contract task queue.

At step 9160, the contract FIRECRACKER mirror compiler of the virtual machine module packages a new mirror for the contract.

In step 9170, the virtual machine module places the images in a contract FIRECRACKER image repository, which can be pulled up at any time.

In step 9180, the block dispatch module places the transaction in a corresponding contract task queue of the transaction dispatch module.

Step 9190, is all transactions deposited complete?

A determination is made as to whether all transactions for generating a new block have been deposited into the corresponding contract task queue. If so, go to step 9200, otherwise go to step 9130.

In step 9200, the contract FIRECRACKER container pool module of the virtual machine module starts different numbers of containers for different contracts according to the task number of the contract task queue.

In step 9210, the block scheduling module schedules the contract FIRECRACKER container to execute the task in the contract task queue.

At step 9220, the contract FIRECRACKER container pulls the transaction in the queue and performs the transaction.

In step 9230, the number of containers per contract is dynamically adjusted during execution.

In step 9240, the block scheduling module generates a new block after all transactions are performed.

In step 9250, after the generation is completed, the node sends the block to other block chain nodes for consensus.

In step 9260, all block link points are commonly known.

Step 9270, is consensus passed?

If the consensus passes, go to step 9290, otherwise go to step 9280.

Step 9280, a result of failure of the consensus check is returned.

The blockchain node returns information to the client indicating that the consensus check failed. After the completion of the present step, the process goes to step 9300.

Step 9290 stores the block and updates the data of the status database.

Step 9300 ends.

It can be seen that the main differences between the process shown in fig. 9A-9C and the process shown in fig. 8A-8C are step 920, step 930 and step 980.

10A-10B illustrate a flow diagram of a FIRECRACKER-based container dynamic scheduling flow, according to one embodiment of the application. The same circular nodes in fig. 10A-10B indicate the same locations in the flow. As shown in fig. 10A-10B, the FIRECRACKER-based container dynamic scheduling process may include the following steps:

step 1001, start.

In step 1002, the block scheduling module initializes a contract task queue, one for each contract, to store pending tasks.

In step 1003, the virtual machine module initializes a pool of contract containers, the pool of contract containers being fixed in size, the same contract having multiple contract containers.

In step 1004, the block scheduling module continually sends the new transaction to the contract task queue.

In step 1005, the block scheduling module periodically traverses all contract task queues at regular time.

Step 1006, is the current contract task queue not empty and FIRECRAKER containers available?

It is determined that the current contract task queue is not empty and that there is a corresponding FIRECRAKER container available. If the current contract task queue is not empty and a FIRECRAKER container is available, then go to step 1007, otherwise go to step 1010.

Step 1007, a task is fetched from the queue.

A transaction is fetched from the current contract task queue.

At step 1008, a usable FIRECRACKER container is obtained.

Step 1009, run the task in the container.

The transaction is performed from FIRECRACKER containers.

Step 1010, query the next contract task queue.

The next contract task queue is taken as a new current contract task queue, and steps 1006-1009 are performed thereon, thereby implementing traversal of the next contract task queue.

In step 1011, the block scheduling module periodically traverses and dynamically adjusts FIRECRACKER the container allocation.

Step 1012, obtaining the length of the current task queue.

If the task queue is too long, step 1013, indicating that the number of containers for the current contract is insufficient, the allocation needs to be increased.

If the task queue is too short, step 1014, indicating that the number of containers for the current contract is too large, the allocation may be reduced.

Step 1015, end.

In summary, according to the execution method of the transaction in the blockchain network provided by the embodiment of the application, at least the following effects can be obtained:

1. The lightweight virtual machine based on FIRECRACKER is provided for executing the transaction in the blockchain network for the first time, and benefits from the advantages of the lightweight virtual machine in the aspects of isolation performance, starting time, safety, usability and the like, the blockchain contract processes can be isolated from each other, the processes cannot access and interfere with each other, the resource isolation of different contract transactions is effectively enhanced, the problem of light weight is solved, the container can be started and operated more rapidly, the contract container can be ensured to be rapidly switched, efficient switching and rotation can be realized under the condition of limited resources, the method is more friendly, and the safety and usability of transaction execution are improved.

2. The packaging method of the contract mirror image is provided, all contract binary files can be adapted, and the contract transaction is conveniently executed in a mode that the existing blockchain is directly switched to FIRECRACKER.

3. The concept of contract FIRECRACKER container pool is provided, and a container dynamic adjustment scheme is provided, so that dynamic resource allocation can be realized under the condition of fixed total resources, and the situation that the transaction execution overall lags due to uneven execution speeds when different contract transactions differ greatly is avoided.

4. When the block transaction quantity is large, concurrency can be fully utilized, high concurrency can be stably realized, concurrency can be fully utilized, and the performance of transaction execution is improved.

5. The scheme of the embodiment of the application can be widely used in industry.

The following describes an embodiment of the apparatus of the present application, which may be used to perform the method of executing transactions in a blockchain network in the above embodiment of the present application. For details not disclosed in the embodiments of the present application, please refer to the embodiments of the method for executing transactions in a blockchain network described above.

FIG. 11 illustrates a block diagram of an execution device of a transaction in a blockchain network in accordance with an embodiment of the application. Referring to fig. 11, an execution apparatus 1100 of a transaction in a blockchain network according to an embodiment of the present application includes an adding unit 1110, a quantity determining unit 1120, and an initiating and executing unit 1130. The adding unit 1110 is configured to add the transaction to be executed to a target contract task queue corresponding to a target intelligent contract on a blockchain node according to a target intelligent contract identifier included in the transaction to be executed, the intelligent contract identifier of the target intelligent contract is the target intelligent contract identifier, the blockchain node includes a contract task queue corresponding to each intelligent contract in at least one intelligent contract, the number determining unit 1120 is configured to determine, for each intelligent contract in the at least one intelligent contract, a number of lightweight virtual machines that need to be started for the intelligent contract according to a number of transactions to be executed included in the contract task queue corresponding to the intelligent contract, and the starting and executing unit 1130 is configured to start, for each intelligent contract in the at least one intelligent contract, a lightweight virtual machine including the intelligent contract on the blockchain node according to a number of lightweight virtual machines that need to be started for the intelligent contract, and pull and execute the transaction to be executed from the contract task queue corresponding to the intelligent contract through the lightweight virtual machine, where the lightweight virtual machine uses an operating system root system of an independent operating system.

In some embodiments of the present application, based on the foregoing, the startup and execution unit 1130 is configured to obtain a kernel image and a root file system image that are prepared in advance, copy the smart contract in the binary file form into the root file system image to obtain a new root file system image, and startup a lightweight virtual machine including the smart contract based on the new root file system image and the kernel image.

It should be noted that, the computer system 1200 of the electronic device shown in fig. 12 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.

As shown in fig. 12, the computer system 1200 includes a central processing unit (Central Processing Unit, CPU) 1201 that can perform various appropriate actions and processes, such as performing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 1202 or a program loaded from a storage section 1208 into a random access Memory (Random Access Memory, RAM) 1203. In the RAM 1203, various programs and data required for the system operation are also stored. The CPU 1201, ROM 1202, and RAM 1203 are connected to each other through a bus 1204. An Input/Output (I/O) interface 1205 is also connected to bus 1204.

Connected to the I/O interface 1205 are an input section 1206 including a keyboard, a mouse, and the like, an output section 1207 including a Cathode Ray Tube (CRT), a Liquid crystal display (Liquid CRYSTAL DISPLAY, LCD), and the like, and a speaker, and the like, a storage section 1208 including a hard disk, and the like, and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, and the like. The communication section 1209 performs communication processing via a network such as the internet. The 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, or the like is installed as needed on the drive 1210 so that a computer program read out therefrom is installed into the storage section 1208 as needed.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1209, and/or installed from the removable media 1211. When executed by a Central Processing Unit (CPU) 1201, performs the various functions defined in the system of the present application.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of a computer-readable storage medium may include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), a flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

In one aspect, the present application also provides a computer readable medium that may be included in the electronic device described in the above embodiment, or may exist alone without being assembled into the electronic device. The computer-readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to implement the methods described in the above embodiments.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the method according to the embodiments of the present application.

It will be appreciated that in particular embodiments of the present application, where blockchain-related data is involved, user approval or consent is required when the above embodiments of the present application are applied to particular products or technologies, and the collection, use and processing of the related data is required to comply with relevant laws and regulations and standards of the relevant countries and regions.

Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains.

It is to be understood that the application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method of executing a transaction in a blockchain network, the method comprising:

Adding the transaction to be executed to a target contract task queue corresponding to a target intelligent contract on a blockchain node according to a target intelligent contract identifier contained in the transaction to be executed, wherein the intelligent contract identifier of the target intelligent contract is the target intelligent contract identifier, and the blockchain node contains contract task queues respectively corresponding to all intelligent contracts in at least one intelligent contract;

For each intelligent contract in the at least one intelligent contract, determining the number of lightweight virtual machines required to be started for the intelligent contract according to the number of transactions to be executed contained in a contract task queue corresponding to the intelligent contract;

And starting the lightweight virtual machines containing the intelligent contracts on the blockchain node according to the number of the lightweight virtual machines required to be started for each intelligent contract in the at least one intelligent contract, and pulling and executing transactions to be executed from contract task queues corresponding to the intelligent contracts through the lightweight virtual machines, wherein operating system components used by the lightweight virtual machines are independent operating system kernels and root file systems.

2. The method of claim 1, wherein the sum of the number of lightweight virtual machines launched for each smart contract at the blockchain node is a fixed value.

3. The method of claim 1, wherein after starting a lightweight virtual machine containing the smart contract on the blockchain node as many lightweight virtual machines as needed to be started for each of the at least one smart contract, the method further comprises:

executing a lightweight virtual machine dynamic adjustment step for each intelligent contract, respectively, wherein the lightweight virtual machine dynamic adjustment step comprises the following steps:

acquiring the length of a contract task queue corresponding to the current intelligent contract;

and adjusting the number of the lightweight virtual machines corresponding to the current intelligent contract according to the length of the contract task queue.

4. The method of claim 3, wherein adjusting the number of lightweight virtual machines corresponding to the current smart contract based on the length of the contract task queue comprises:

if the contract task queue is determined to be a long queue according to the comparison result of the length of the contract task queue and the long queue length threshold value, increasing the number of lightweight virtual machines corresponding to the current intelligent contract;

And if the contract task queue is determined to be a short queue according to the comparison result of the length of the contract task queue and the short queue length threshold, reducing the number of lightweight virtual machines corresponding to the current intelligent contract, wherein the long queue length threshold is larger than the short queue length threshold.

5. The method of claim 1, wherein before adding the transaction to be performed to a target contract task queue on a blockchain node corresponding to a target smart contract according to a target smart contract identification included in the transaction to be performed, the method further comprises:

If the transaction to be executed is a transaction for creating an intelligent contract, acquiring the intelligent contract in a binary file form from the transaction to be executed;

A contract task queue corresponding to the intelligent contract in binary file form is created on the blockchain node.

6. The method of claim 5, wherein said launching, at said blockchain node, a lightweight virtual machine containing said smart contract, comprises:

acquiring a kernel image and a root file system image which are prepared in advance;

copying the intelligent contract in the binary file form into the root file system image to obtain a new root file system image;

And starting a lightweight virtual machine containing the intelligent contract based on the new root file system image and the kernel image.

7. The method of claim 1, wherein prior to adding the transaction to be performed to a target contract task queue on a blockchain node corresponding to a target smart contract, the method comprises:

adding the received transaction into a transaction pool;

Obtaining a plurality of transactions for generating new blocks from the pool of transactions;

Selecting one transaction at a time from the plurality of transactions as a transaction to be performed, wherein determining the number of lightweight virtual machines that need to be activated for the smart contract is performed with all transactions for generating the new block added to a corresponding contract task queue;

After pulling and executing, by the lightweight virtual machine, a transaction to be executed from a contract task queue corresponding to the smart contract, the method further includes:

When all the transactions to be executed for generating the new block are completed, generating a new block according to all the transactions to be executed for generating the new block.

8. The method of claim 7, wherein prior to adding the received transaction to the pool of transactions, the method further comprises:

When the block link point receives a transaction request carrying a transaction sent by a client, signature verification and authority verification are carried out on the transaction request, wherein the received transaction is added into a transaction pool under the condition that the transaction request passes the signature verification and the authority verification.

9. The method of claim 7, further comprising, after generating a new chunk from all transactions to be performed for generating the new chunk:

transmitting the new block to other blockchain nodes in a blockchain network to perform consensus in the blockchain network;

If the consensus for the new block passes, the new block is stored in the blockchain node.

10. An apparatus for executing a transaction in a blockchain network, the apparatus comprising:

The adding unit is used for adding the transaction to be executed to a target contract task queue corresponding to a target intelligent contract on a blockchain node according to the target intelligent contract identifier contained in the transaction to be executed, wherein the intelligent contract identifier of the target intelligent contract is the target intelligent contract identifier, and the blockchain node contains contract task queues respectively corresponding to all intelligent contracts in at least one intelligent contract;

A quantity determining unit, configured to determine, for each of the at least one smart contract, a quantity of lightweight virtual machines that need to be started for the smart contract according to a quantity of transactions to be executed included in a contract task queue corresponding to the smart contract;

And the starting and executing unit is used for starting the lightweight virtual machines containing the intelligent contracts on the blockchain node according to the number of the lightweight virtual machines which are started for each intelligent contract in the at least one intelligent contract, and pulling and executing transactions to be executed from contract task queues corresponding to the intelligent contracts through the lightweight virtual machines, wherein the lightweight virtual machines use independent operating system kernels and root file systems.

11. A computer readable medium having stored thereon a computer program, which when executed by a processor implements a method of executing a transaction in a blockchain network according to any of claims 1 to 9.

12. An electronic device, comprising:

One or more processors;

Storage means for storing one or more programs which when executed by the one or more processors cause the one or more processors to implement the method of execution of transactions in a blockchain network as in any of claims 1 to 9.

13. A computer program product, characterized in that it comprises computer instructions stored in a computer readable storage medium, from which computer instructions a processor of a computer device reads, the processor executing the computer instructions, causing the computer device to execute the execution method of a transaction in a blockchain network according to any of claims 1 to 9.