Block chain generation method, device and equipment based on smart contract

Abstract

The invention relates to the technical field of block chains, and provides a block chain generation method, device and equipment based on a smart contract, which are used for improving the operation efficiency of a block chain. According to the method, a contract container pool containing a fixed number of containers is provided, and each container is shared by different intelligent contracts, so that when a preset block generation condition is met, at least one target container is selected for each calling type of intelligent contract from the contract container pool based on the current transaction bearing capacity of each container, and the intelligent contract is generated according to the selected target container. According to the technical scheme of the invention, each smart contract is called to process the corresponding transaction data, so that the container resource is dynamically allocated to each smart contract under the condition that the total resource of the container is fixed, the problem that the overall generation speed of the block chain is lagged due to non-uniform operation speed when the transaction data volumes corresponding to different smart contracts are greatly different is avoided, and the user experience is improved. And the generation speed of the new block is improved, so that the overall operation efficiency of the regional chain is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to the field of blockchain technology, and provides a method, device and equipment for generating a blockchain based on a smart contract. Background Art

[0002] Blockchain is a chain data structure that has two major characteristics: decentralization and difficulty in tampering. Based on these two characteristics, the information recorded in the blockchain is more authentic and reliable.

[0003] The core of blockchain is smart contract technology. Smart contracts are written by developers and published to each node that maintains the blockchain. In actual applications, smart contracts can be applied to public chains or alliance chains.

[0004] Smart contracts (such as Solidity contracts) on public chains (such as Ethereum) stipulate that each operation performed by each node requires the consumption of certain resources (such as billing); thus, in the process of generating each block, when the code logic and calculation process executed by each node are relatively complex, a large amount of resources will be consumed, which will bring serious burden to the operation and maintenance of the blockchain. On the other hand, the development language used by smart contracts on public chains is not rich enough and has certain limitations. For example, Solidity contracts only support the development of Solidity language.

[0005] However, smart contracts on consortium chains (such as Changan Chain and Hyperledger Fabric) do not provide relevant regulations on resource consumption and support development using native languages ​​​​(such as Golang and Java). Therefore, they can solve the problems existing in smart contracts on the above-mentioned public chains.

[0006] However, when the smart contract on the alliance chain is called, the native language used usually occupies at least one process. When the processing logic of the smart contract is too complicated, it will increase the CPU and memory overhead, and also require a certain amount of network overhead, etc. In this way, in the process of generating each block, it will cause the blockchain overhead to be large, resulting in a slower startup speed of the blockchain and affecting the efficiency of blockchain use.

[0007] Therefore, realizing a universal lightweight operation solution for smart contracts is a key issue that needs to be urgently solved in blockchain technology. Summary of the invention

[0008] The embodiments of the present application provide a method, device and equipment for generating a blockchain based on a smart contract, which are used to improve the operating efficiency of the regional chain and reduce resource overhead.

[0009] On the one hand, an embodiment of the present application provides a blockchain generation method based on a smart contract, which is applied to a network node maintaining a blockchain, including:

[0010] When the preset block generation conditions are met, a batch of transaction data is selected from the transaction pool, and the contract type of each transaction data is obtained respectively;

[0011] Store at least one first transaction data in the batch of transaction data into a contract task queue; wherein each first transaction data corresponds to a smart contract whose contract type is a call contract;

[0012] For at least one smart contract obtained, the following operations are performed respectively: based on the current transaction carrying capacity of each container in the contract container pool maintained by the network node, at least one target container is selected from the contract container pool, and the at least one target container is used to call a smart contract to process the corresponding first transaction data in the contract task queue to obtain a transaction result;

[0013] A new block is generated based on at least one transaction result obtained, and after the new block passes the consensus verification with other nodes having a consensus mechanism between the network nodes, the new block is stored on the chain.

[0014] On the other hand, an embodiment of the present application provides a blockchain generation device based on a smart contract, comprising:

[0015] The acquisition module is used to select a batch of transaction data from the transaction pool when the preset block generation conditions are met, and obtain the contract type of each transaction data respectively;

[0016] A transaction storage module, used to store at least one first transaction data in the batch of transaction data into a contract task queue; wherein each first transaction data corresponds to a smart contract whose contract type is a call contract;

[0017] The container allocation module is used to perform the following operations for at least one smart contract obtained: based on the current transaction carrying capacity of each container in the contract container pool maintained by the network node, select at least one target container from the contract container pool, and use the at least one target container to call a smart contract to process the corresponding first transaction data in the contract task queue to obtain a transaction result;

[0018] The block generation module is used to generate a new block based on at least one transaction result obtained, and after the new block passes the consensus verification with other nodes having a consensus mechanism between the network nodes, the new block is stored on the chain.

[0019] Optionally, the container allocation module is specifically used for:

[0020] Querying whether there is at least one idle container in the contract container pool to which the first transaction data is not allocated;

[0021] If yes, use the at least one free container as at least one target container of the smart contract;

[0022] Otherwise, query whether the smart contract has been allocated at least one container;

[0023] When no container is allocated to the smart contract, at least one target container is selected from the containers in the contract container pool that have been allocated to other smart contracts;

[0024] When at least one container has been allocated to the smart contract, a target container is selected based on the current transaction carrying capacity of each of the at least one container.

[0025] Optionally, the container allocation module is specifically used for:

[0026] For at least one other smart contract that has been assigned multiple containers, the following operations are respectively performed: from multiple containers of the other smart contract, a candidate container is selected in order of transaction carrying capacity from small to large, and based on a preset load balancing rule, the current transaction carrying capacity of the candidate container is distributed to other containers of the other smart contract;

[0027] At least one selected candidate container is used as at least one target container of the smart contract.

[0028] Optionally, the container allocation module is specifically used for:

[0029] Selecting a target container from the at least one container in ascending order of transaction carrying capacity, and determining whether the target container meets a preset allocation condition;

[0030] If the target container meets the preset allocation conditions, a candidate container is selected from multiple containers of at least one other smart contract in the order of transaction carrying capacity from small to large, and based on the preset load balancing rule, the current transaction carrying capacity of at least one candidate container is distributed to other containers of the same smart contract;

[0031] At least one container to be adjusted whose current transaction carrying capacity is greater than a preset upper limit in the at least one container is obtained, and the current transaction carrying capacity of each of the at least one container to be adjusted is distributed to the at least one candidate container.

[0032] Optionally, the preset allocation condition includes at least one of the following:

[0033] The current transaction carrying capacity of the target container is greater than a preset carrying threshold;

[0034] The current transaction carrying capacity of the target container is greater than the minimum transaction carrying capacity of the containers corresponding to other smart contracts.

[0035] Optionally, the device further includes a contract installation module, which is used to create a new contract task queue for at least one second transaction data in the batch of transaction data whose contract type is a creation-class contract, and each new contract task queue is used to store the first transaction data for calling the new smart contract;

[0036] Create a new directory in the project repository and save the compiled binary file of the new smart contract into the new directory;

[0037] Configure dependencies and function libraries for the new smart contract in the new directory, and modify the container configuration file to start the new smart contract.

[0038] Optionally, after starting the new smart contract, the transaction storage module is further used to:

[0039] The first transaction data that calls the new smart contract in the batch of transaction data is stored in the corresponding contract task queue.

[0040] Optionally, the device further comprises a security verification module, and before selecting a batch of transaction data from the transaction pool, the security verification module is used to:

[0041] Receive at least one smart contract published by the target object;

[0042] A security authentication of at least one of a signature and an authority of the target object;

[0043] After the security verification is passed, the first transaction data of each of the at least one contract is stored in the transaction pool.

[0044] Optionally, each container in the contract container pool corresponds to a container transaction queue for storing the first transaction data processed by it, and each container transaction queue is stored on a device located outside the network node.

[0045] Optionally, the type of the container is a runc container.

[0046] On the other hand, an embodiment of the present application provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the steps of the above-mentioned blockchain generation method based on smart contracts are implemented.

[0047] On the other hand, an embodiment of the present application provides a computer-readable storage medium having computer-executable instructions stored thereon, which, when executed by an electronic device, implement the steps of the above-mentioned smart contract-based blockchain generation method.

[0048] On the other hand, an embodiment of the present application provides a computer program product, comprising a computer program, which, when executed by an electronic device, implements the steps of the above-mentioned smart contract-based blockchain generation method.

[0049] The beneficial effects of the blockchain generation method based on smart contracts in this application are as follows:

[0050] The concept of contract container pool is proposed. Each network node maintaining the blockchain maintains a contract container pool containing multiple containers, and the containers in the contract container pool are shared by different smart contracts. In this way, when the preset block generation conditions are met, for at least one smart contract that calls a class contract, the corresponding first transaction data is stored in the contract task queue respectively. Based on the current transaction carrying capacity of each container in the contract container pool, at least one target container is selected from the contract container pool for each smart contract to call each smart contract to process the corresponding first transaction data in the contract task queue. In this way, when the total container resources are fixed, container resources can be dynamically allocated to each smart contract based on the current transaction carrying capacity of each container, avoiding the problem of uneven running speed when the transaction data corresponding to different smart contracts differ greatly, resulting in the overall generation speed of the blockchain lagging behind, and improving the speed of generating new blocks based on the transaction results of each transaction data, thereby improving the overall operation efficiency of the regional chain.

[0051] On the other hand, since each container is an independent and lightweight operating environment, each container can execute in parallel when calling smart contracts, reducing resource overhead and further improving the operating efficiency of the blockchain.

[0052] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0054] Figure 1 A schematic diagram of a blockchain provided for an embodiment of the present application;

[0055] Figure 2 An application scenario diagram applicable to the embodiment of the present application;

[0056] Figure 3 An architectural diagram of a blockchain generation system provided in an embodiment of the present application;

[0057] Figure 4 A schematic diagram of the entire life cycle process of blockchain generation provided in the embodiment of the present application;

[0058] Figure 5A A flow chart of a security verification method provided in an embodiment of the present application;

[0059] Figure 5B A flowchart of a blockchain generation method based on a smart contract provided in an embodiment of the present application;

[0060] Figure 6 A flow chart of a method for dynamically allocating containers for smart contracts provided in an embodiment of the present application;

[0061] Figure 7 A schematic diagram of a container allocation process provided in an embodiment of the present application;

[0062] Fig. 8A A schematic diagram of a container allocation method provided in an embodiment of the present application;

[0063] Figure 8B A schematic diagram of another container allocation method provided in an embodiment of the present application;

[0064] Figure 8C A schematic diagram of another container allocation method provided in an embodiment of the present application;

[0065] Fig.9A A flow chart of a method for installing a smart contract provided in an embodiment of the present application;

[0066] Fig. 9B A schematic diagram of the command for installing a smart contract provided in an embodiment of the present application;

[0067] Fig.10 A flowchart of a blockchain generation method from smart contract creation to transaction processing provided in an embodiment of the present application;

[0068] Fig.11 A schematic diagram of a transfer process provided in an embodiment of the present application;

[0069] Fig.12 A structural diagram of a blockchain generation device based on a smart contract provided in an embodiment of the present application;

[0070] Fig.13 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0071] In order to make the purpose, technical scheme and advantages of the present application clearer, the technical scheme in the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other arbitrarily. In addition, although the logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.

[0072] It is understandable that in the following specific implementation methods of this application, if data related to the target object is involved, when the various embodiments of this application are applied to specific products or technologies, relevant permissions or consents need to be obtained, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0073] To facilitate understanding of the technical solutions provided in the embodiments of the present application, some key terms used in the embodiments of the present application are explained here:

[0074] Blockchain: also known as distributed data record book, is a chain data structure that combines data blocks in a sequential manner in chronological order, and uses cryptography to ensure that it cannot be tampered with or forged, realizing a decentralized distributed account book. It is generally composed of consensus, block and state data storage, cryptographic identity security, etc. Since the account book is distributed and the blocks are agreed upon, it has the characteristics of being tamper-proof, traceable, and jointly maintained. Figure 1 As shown in , it is a schematic diagram of the structure of the blockchain provided in an embodiment of the present application. A blockchain is formed by connecting blocks in series in sequence.

[0075] Blocks are used to record data sets and status results divided according to certain conditions. They are formed after all nodes reach a consensus. Blocks can be divided by time or by the number of computing tasks. The present application embodiment does not limit the specific division method of blocks. Figure 1As shown, a rectangular box represents a block, and a block can generally include a block header and a block body. Among them, the block header includes the previous block address (Prev-block), and the previous block address can usually be stored in the block header in the form of a previous block hash code (pre-hash). All blocks are connected in series through the pointing of the previous block address to form a blockchain. The block body is used to store specific data, such as the security verification results and transaction results in the embodiments of the present application.

[0076] Smart Contract: A computer protocol designed to communicate, verify or execute contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, which are traceable and irreversible. The purpose of smart contracts is to provide a security method superior to traditional contracts and reduce transaction costs.

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

[0078] runC: A lightweight tool for running containers created according to the Open Container Initiative (OCI) specification.

[0079] Transaction: Equivalent to the computer term transaction, a transaction includes operations that need to be submitted to the blockchain service for execution, as well as the corresponding transaction results. It does not refer only to transactions in a business context. In view of the conventional use of the term "transaction" in blockchain technology, the embodiments of this application follow this convention; for example, transactions may include deployment transactions and invoke transactions. Deployment transactions are used to publish smart contracts to the network nodes of the blockchain and prepare them to be invoked; invoke transactions are used to query (i.e., read operations) or update (i.e., write operations, including addition, deletion, and modification) the status database in the ledger.

[0080] Transaction Pool (also called Mempool): refers to a collection of transactions that have not been packaged into a block and are waiting to be written into a block. In a blockchain network, each network node maintains a transaction pool to store newly generated transactions. Every time a new transaction is generated, the transaction will be broadcast to the entire blockchain network. If the new transaction complies with the transaction rules and verification rules of the blockchain network, it will be added to the transaction pool of the network node. Transactions in the transaction pool need to be verified and confirmed before they are packaged into a block.

[0081] The transaction pool is one of the important components of the blockchain network. While ensuring that transactions are processed smoothly, it can also improve the efficiency and performance of the blockchain.

[0082] Contract container pool: It is a smart contract execution environment based on blockchain technology. It can automatically manage and schedule multiple containers to achieve efficient smart contract execution. The contract container pool is usually composed of multiple containers running smart contracts. Each container can execute smart contracts independently. When a new smart contract needs to be executed, the contract container pool will automatically select an available container to execute the new smart contract, thereby achieving efficient execution of smart contracts.

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

[0084] The following is an overview of the design concepts of the embodiments of the present application.

[0085] The core of blockchain is smart contract technology, which is written by developers and published on blockchain nodes. Blockchain includes public chain and consortium chain.

[0086] The public chain is represented by Ethereum. Ethereum's solidity contract will charge for each operation. In this way, in the process of generating each block, when the code logic and calculation process executed by each node are more complicated, a lot of fees will be consumed. In addition, Solidity contracts only support Solidity language for development, and there are language-level limitations.

[0087] The execution of smart contracts on consortium chains (such as Changan Chain and Hyperledger Fabric) does not actually consume any fees, and supports development in native languages ​​(such as Golang and Java). However, a smart contract on Changan Chain will start a process. When the transaction processing logic in the smart contract is too complex, it will occupy most of the resources, resulting in slow execution of other smart contracts. After the process is started, it will access the other party's file system or network, and the isolation is poor. The virtualization technology based on FirecrackerFabric has better isolation, but it requires a processor with hardware virtualization support (such as Intel VT-x or AMD-V) to support it. Although Hyperledger Fabric uses the Docker container method, the storage and resource usage of the Docker container is large, and the startup time is slow. Therefore, the operation of smart contracts on Hyperledger Fabric still has problems such as insufficient lightness during process isolation, incomplete hardware support, and generality.

[0088] In view of this, the embodiment of the present application provides a blockchain generation method based on smart contracts. The method proposes the concept of a contract container pool. Each network node that maintains the blockchain maintains a contract container pool containing multiple containers, and the containers in the contract container pool are shared by different smart contracts. In this way, when the preset block generation conditions are met, for at least one smart contract that calls a class contract, based on the current transaction carrying capacity of each container in the contract container pool, at least one target container is selected from the contract container pool for each smart contract to call each smart contract to process the corresponding first transaction data in the contract task queue, so that when the total container resources are fixed, In this case, container resources can be dynamically allocated to each smart contract based on the current transaction carrying capacity of each container, avoiding the problem of uneven running speed when the transaction data volumes corresponding to different smart contracts differ greatly, which leads to the overall generation speed of the blockchain lagging behind. The speed of generating new blocks based on the transaction results of each transaction data is improved, thereby improving the overall operation efficiency of the regional chain; and the container type in the contract container pool is runC container. Since runC container is lighter than other containers and has better isolation, it ensures that smart contracts can run efficiently in parallel, and processes cannot access and interfere with each other, thereby improving the operation performance of the blockchain.

[0089] After introducing the design ideas of the embodiments of the present application, the following briefly introduces the application scenarios to which the technical solutions of the embodiments of the present application can be applied. It should be noted that the application scenarios introduced below are only used to illustrate the embodiments of the present application and are not limited. In the specific implementation process, the technical solutions provided by the embodiments of the present application can be flexibly applied according to actual needs.

[0090] The method provided in the embodiment of the present application can be applied to most scenarios involving the generation of new blocks. Figure 2 As shown, a schematic diagram of an application scenario provided in an embodiment of the present application is provided. In this scenario, a terminal device 201 and a blockchain network 202 may be included.

[0091] The terminal device 201 can be, for example, a mobile phone, a tablet computer (PAD), a laptop computer, a desktop computer, a smart TV, a smart vehicle device, a smart wearable device, or any other device capable of submitting a transaction. The terminal device 201 can be installed with a target application, which has the function of presenting and submitting transaction tasks. The application involved in the embodiment of the present application can be a software client, or a client such as a web page or a small program, and the specific type of the client is not limited.

[0092] The blockchain network 202 is used to provide actual container scheduling and contract execution, as well as to store status data related to the execution of transaction tasks of the entire system (such as the results after each transaction), to ensure the credibility between nodes in the system. The blockchain network 202 can be a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, i.e., content delivery networks (CDNs), and big data and artificial intelligence platforms, but is not limited to these.

[0093] In the embodiment of the present application, the terminal device 201 and the blockchain network 202 can be directly or indirectly connected to each other through the communication network 203. The communication network 203 can be a wired network or a wireless network, for example, the wireless network can be a mobile cellular network, or a wireless fidelity (Wireless-Fidelity, WIFI) network, and of course, it can be other possible networks, which are not limited in the embodiment of the present application.

[0094] See also Figure 3 , is an architecture diagram of a blockchain generation system based on a smart contract provided in an embodiment of the present application, which mainly includes a network module, an authentication module, a transaction pool module, a block scheduling module, a virtual machine module, a consensus module, and a storage module. When each module executes a blockchain generation service, the role and interaction of each module are as follows:

[0095] (1) Network module: This is the module for network nodes in the blockchain network to interact with the outside world. It is used to complete tasks such as transaction upload and data query.

[0096] Transaction on-chain is used to package the transaction data sent by the receiving object and the smart contract used to execute each transaction data in the process of generating a new block, and store them in the blockchain ledger and database.

[0097] Data query is used to receive query statements sent by objects and query data in the blockchain.

[0098] (2) Authentication module, which is a module for performing security verification on requests in the blockchain network, including signature verification and permission verification, where:

[0099] Signature verification is used to verify the signature of the requester.

[0100] Permission verification is used to verify the identity and permissions of the requester, that is, whether he has the permission to perform the requested operation.

[0101] (3) Transaction pool module: a module for caching transaction data and smart contracts.

[0102] (4) Block scheduling module: a module that processes transaction data in the transaction pool and generates new blocks. It is used for tasks such as transaction data distribution and block generation.

[0103] Transaction distribution scheduling is used to distribute the transaction data to be processed to the contract task queue, and the container calls the corresponding smart contract for processing. During the processing, each container corresponds to a container transaction queue, which is used to store all transaction data processed by each container, and the correspondence between smart contracts and containers can be recorded in the contract container table, such as which smart contract a container calls, all containers allocated by a smart contract, etc.

[0104] Block generation is used to generate a new block after all transaction data in the contract task queue has been processed.

[0105] Optionally, the container transaction queue of each container may be stored on a device outside the network node, so that when the network node crashes, the data of the new block to be generated can be recovered from the container transaction queue, thereby improving data fault tolerance.

[0106] (5) Virtual machine module, which is a module for executing transaction data, including contract runC project creation, contract runC project storage and contract container pool allocation, among which:

[0107] The contract runC project is created to build the contract project through the lightweight runC so that it can be started and run quickly.

[0108] Contract runC project storage is used to compile the created smart contract and store the compiled binary file in the project warehouse.

[0109] Contract container pool allocation is used to allocate a fixed number of containers to different smart contracts. The number of containers allocated to different smart contracts can be the same or different, and different smart contracts can share a container. For example, smart contract 1 is allocated runC container 1 and runC container 2, and smart contract 2 is allocated runC container 1. The number of containers corresponding to each smart contract can be dynamically adjusted according to actual conditions.

[0110] (6) Consensus module: This module is used by each network node in the blockchain network to perform consensus voting on the generated new blocks.

[0111] (7) Storage module: a module for storing blockchain data in each network node in the blockchain network. Based on the different storage contents, it is divided into a state database and a block ledger, where:

[0112] State database, a database used to store the latest variable status in the blockchain.

[0113] Blockchain ledger is a text file used to store each block in the blockchain.

[0114] Figure 3 The system architecture shown serves as the operating basis for the entire blockchain generation. It combines lightweight runC containers and dynamic adjustment of containers, so that when the total resources of runC containers are fixed, dynamic allocation of runC containers can be achieved, avoiding uneven execution speeds when the transaction data volumes of different smart contracts differ greatly, resulting in the problem of lagging overall blockchain generation efficiency, thereby ensuring efficient and stable operation of the blockchain.

[0115] Below, in combination with the application scenarios and system architecture described above, the full life cycle process of generating a blockchain based on a smart contract provided by an exemplary embodiment of the present application is described with reference to the accompanying drawings, such as Figure 4 As shown in the figure, it mainly includes three parts: smart contract installation based on runC container, transaction operation based on smart contract and dynamic allocation of runC container. Among them, in the smart contract installation part based on runC container, it mainly includes the steps of smart contract being compiled into binary file for chain, packaging binary file and configuring, initializing smart contract, etc.; in the transaction operation part based on smart contract, it mainly starts the process of runC container calling smart contract to process the received transaction data; in the dynamic allocation part of runC container, it mainly dynamically allocates runC container in contract container pool to different smart contract processes.

[0116] In the process of generating a blockchain, the runC container in the embodiment of the present application can ensure that the processes of scheduling smart contracts in the blockchain are isolated from each other, and the processes cannot access and interfere with each other. In this way, when the number of transactions is large, concurrency can be fully utilized to improve the operation efficiency of the blockchain; at the same time, the dynamic allocation of the runC container can ensure that the runC container can be quickly switched between different smart contracts, thereby achieving efficient rotation under limited container resources and improving the operation efficiency of the blockchain. This method is relatively lightweight and can be widely reused in the industry.

[0117] It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present application, and the implementation methods of the present application are not limited in this regard.

[0118] In the embodiment of the present application, in the process of processing transaction data to generate blocks, it is necessary to first deploy the smart contract used to process transaction data on the network node of the blockchain and perform security verification. The specific process is as follows Figure 5A As shown, it mainly includes the following steps:

[0119] S500_1: The network node receives at least one smart contract published by the target object.

[0120] In specific applications, after the target object writes a smart contract using the development language, the smart contract is compiled into a computer executable binary file and the binary file is published to the network node of the blockchain.

[0121] It should be noted that at least one smart contract can be written for the same target object or for different target objects.

[0122] S500_2: The network node performs security authentication on at least one of the signature and the authority of the target object.

[0123] In one example, after receiving at least one smart contract published by the target object, the network node will verify the signature of the target object. The verification method includes but is not limited to encryption algorithm, public key cryptography system and digital signature algorithm. When the signature verification is passed, the authority of the target object is verified, such as whether the target object is in the blacklist, whether the target object has the authority to operate the smart contract, etc.

[0124] S500_3: After the security verification is passed, the first transaction data of at least one contract is stored in the transaction pool.

[0125] When the signature and permission verification of the target object is passed, the first transaction data of at least one contract can be stored in the transaction pool for processing.

[0126] In the embodiments of the present application, by performing security verification on the signature and permissions of the target object, the security of the contract deployed on the network node can be ensured, thereby ensuring the security of transaction processing.

[0127] After deploying at least one smart contract, you can generate a blockchain by running the smart contract. Figure 5B As shown, the process of the blockchain generation method based on the smart contract provided in the embodiment of the present application is provided. The method can be executed by any network node in the maintenance blockchain, and mainly includes the following steps:

[0128] S501: When the preset block generation conditions are met, the network node selects a batch of transaction data from the transaction pool and obtains the contract type of each transaction data respectively.

[0129] In an optional embodiment, the preset block generation conditions include but are not limited to the number of transactions in the transaction pool reaching a preset number threshold, reaching a preset block generation time, and the operation and maintenance personnel triggering a generation instruction based on actual conditions.

[0130] In the embodiment of the present application, the transaction data in the blockchain will be stored in the transaction pool. Among them, different transaction data may correspond to different contract types, including but not limited to call contracts, create contracts, update contracts, etc. These transaction data of different contract types are mixed and stored in the transaction pool, and the transaction data of different contract types are processed differently.

[0131] For example, calling a class contract indicates that the smart contract corresponding to the transaction data already exists, and the corresponding smart contract can be directly called to process the transaction data.

[0132] For another example, creating a class contract indicates that the smart contract corresponding to the transaction data has not yet been published to the network node. The smart contract needs to be compiled and uploaded to the chain before the newly created smart contract is called to process the corresponding transaction data.

[0133] For another example, an update contract indicates that the smart contract corresponding to the transaction data already exists, but it is not the latest version. The smart contract needs to be updated and the corresponding transaction data needs to be processed with the updated smart contract.

[0134] In an embodiment of the present application, when the preset block generation conditions are met, when the network node selects a batch of transaction data from the transaction pool for batch processing, the contract type of each transaction data in the batch of transaction data is obtained respectively, and then processed according to the corresponding contract type.

[0135] S502: Store at least one first transaction data of a batch of transaction data whose contract type is a calling contract into a contract task queue.

[0136] For at least one first transaction data in a batch of transaction data, since the contract type of each first transaction data is a calling contract, the smart contracts corresponding to these first transaction data already exist and can be directly called to process the first transaction data. Therefore, the first transaction data is stored in the contract task queue waiting for processing.

[0137] Among them, each first transaction data corresponds to a smart contract whose contract type is a calling contract, and the same smart contract can be used to process different first transaction data.

[0138] For example, the calling contract corresponding to the first transaction data 1 and the first transaction data 2 is a transfer contract, and the calling contract corresponding to the first transaction data 3 is a loan contract.

[0139] In an embodiment of the present application, a contract container pool is allocated to each network node in the blockchain, the total number of containers in each contract container pool is fixed, and the containers in the contract container pool can be shared by different smart contracts, thereby achieving efficient rotation of containers between different smart contracts.

[0140] Optionally, the type of container in the contract container pool is a runC container, that is, a container run by the runC tool. Since the Docker engine runs in the background, it may cause additional resource consumption and logical complexity, and runC does not have all the functions of Docker and only focuses on the event of running containers. Therefore, runC has the advantages of lighter weight, simpler architecture, higher flexibility, fewer dependencies, and faster running speed compared to Docker; at the same time, compared to Firecracker, runC has the advantages of lighter weight, lower resource overhead, faster startup speed, higher compatibility (compatible with Docker and Kubernetes), simpler configuration, and wider hardware support (runC can run on any system that supports Linux namespaces and cgroups, while Firecracker requires a processor with hardware virtualization support (such as Intel VT-x or AMD-V)). Therefore, runC is more suitable for lightweight multi-contract task scenarios, and runC supports various underlying environments, which is more suitable for the execution of blockchain contracts.

[0141] It should be noted that the total number of containers in the contract container pool is set according to actual needs, and the embodiment of the present application does not impose any restrictive requirements. The total number of containers in the contract container pool corresponding to different network nodes may be the same or different.

[0142] S503: For each smart contract, the network node selects at least one target container from the contract container pool based on the current transaction carrying capacity of each container in the contract container pool maintained by the network node, and uses the at least one target container to call the smart contract to process the corresponding first transaction data in the contract task queue to obtain a transaction result.

[0143] In an optional implementation, in the contract container pool corresponding to each network node, the correspondence between the container and the smart contract is not fixed, and the network node can dynamically adjust the number of containers allocated to each smart contract according to actual conditions.

[0144] For details, see the process of dynamically allocating containers for each smart contract. Figure 6 As shown, it mainly includes the following steps:

[0145] S5031: Query whether there is at least one idle container in the contract container pool that is not allocated with the first transaction data. If so, execute S5032; if not, execute S5033.

[0146] In an embodiment of the present application, the corresponding first transaction data is processed by calling a smart contract through a container. Each container corresponds to a container transaction queue stored on an external device other than a network node, which is used to store the first transaction data processed by the container. Therefore, by searching the container transaction queue of each container, the current transaction capacity of each container, that is, the number of first transaction data processed by each container, can be obtained. When the container transaction queue of a container is empty, that is, the container is not assigned the first transaction data that needs to be processed, that is, the container is an idle container.

[0147] By querying free containers, the utilization rate of container resources in the contract container pool can be improved, the processing efficiency of transaction data can be improved, and the overall operation efficiency of the blockchain can be improved.

[0148] S5032: Use at least one idle container as at least one target container of the smart contract.

[0149] When there is at least one idle container in the contract container pool, the at least one idle container can be used as at least one target container for calling the smart contract for transaction processing, thereby making full use of the container resources in the contract container pool.

[0150] Optionally, when there is at least one idle container, all or part of the idle containers can be used as the target container of the smart contract.

[0151] S5033: Check whether the smart contract has been allocated at least one container. If not, execute S5034; if so, execute S5035.

[0152] When there are no free containers in the contract container pool, it is possible to query whether the smart contract has been allocated at least one container, so as to allocate a container to the smart contract according to the query result, thereby ensuring the processing efficiency of the first transaction data corresponding to the smart contract.

[0153] S5034: Select at least one target container from the containers in the contract container pool that have been allocated to other smart contracts.

[0154] When there are no free containers in the contract container pool and the smart contract has not been assigned any container, it means that all containers in the contract container pool have been assigned to other smart contracts. Therefore, it is necessary to select at least one target container for the smart contract from the containers that have been assigned to other smart contracts.

[0155] In the embodiments of the present application, when selecting a target container from the containers of other smart contracts, it should be ensured that the transaction data of other smart contracts are processed by containers, which imposes certain restrictions on the selection of the target container. This is because if the other smart contract has only one container, if the container is allocated to the smart contract, it will result in other smart contracts not being allocated containers, thereby reducing the processing efficiency of the transaction data corresponding to other smart contracts. Therefore, when selecting a target container from the containers of other smart contracts, it is necessary to allocate container resources for the smart contract from other smart contracts that allocate multiple containers (i.e., the number of containers is greater than 1).

[0156] like Figure 6 As shown, the process of S5034 may include the following steps:

[0157] S5034_1: For each other smart contract that has been assigned multiple containers, select a candidate container from the multiple containers of the other smart contract in the order of transaction carrying capacity from small to large, and based on the preset load balancing rules, distribute the current transaction carrying capacity of the candidate container to other containers of the other smart contract.

[0158] In specific applications, when selecting a candidate container from multiple containers of each smart contract, the container with the smallest transaction carrying capacity can be used as a candidate container, thereby ensuring that when reducing the number of containers of each other smart contract whose number of containers is greater than 1, the processing efficiency of the first transaction data of other smart contracts is minimally affected.

[0159] Among them, after each candidate container is used as the target container of the smart contract, the candidate container cannot call other smart contracts to process the corresponding first transaction data. In this way, the first transaction data processed by each candidate container needs to be allocated to other containers of the same other smart contract for processing.

[0160] In an optional embodiment, when allocating the first transaction data processed by a candidate container to other containers, in order to ensure the processing speed of each container, the current transaction capacity of each candidate container can be evenly distributed to other containers of the same other smart contract so that the transaction volumes processed by other containers are as similar as possible.

[0161] S5034_2: Select at least one candidate container as at least one target container of the smart contract.

[0162] In specific applications, after the first transaction data processed by each candidate container is distributed to other containers under the same smart contract, the current transaction carrying capacity of each candidate container is zero, that is, it becomes an idle container. Therefore, at least one candidate container can be used as at least one target container of the smart contract to process the first transaction data of the smart contract.

[0163] S5035: Select a target container based on the current transaction carrying capacity of at least one container.

[0164] When there is no free container in the contract container pool and the smart contract has been allocated at least one container, it indicates that the corresponding first transaction data can be processed using the at least one container allocated to the smart contract.

[0165] In the embodiment of the present application, although at least one container has been allocated to the smart contract, in order to avoid the problem of container overload and lowering the overall speed of each container, the principle of load balancing should also be followed when selecting a target container from at least one container of the smart contract.

[0166] like Figure 6 As shown, the process of S5035 may include the following steps:

[0167] S6035_1: Select a target container from at least one container in ascending order of transaction carrying capacity.

[0168] In one example, to ensure the running speed of the container, when the smart contract has allocated at least one container, a container with the smallest transaction carrying capacity can be selected from the at least one container as the target container for processing the first transaction data of the smart contract.

[0169] S6035_2: Determine whether the target container meets the preset allocation conditions. If so, execute S6035_3; if not, end.

[0170] Optionally, the preset allocation condition includes at least one of the following: the current transaction carrying capacity of the target container is greater than a preset carrying threshold, and the current transaction carrying capacity of the target container is greater than the minimum transaction carrying capacity of containers corresponding to other smart contracts.

[0171] S6035_3: Select a candidate container from multiple containers of at least one other smart contract in order of transaction carrying capacity from small to large, and distribute the current transaction carrying capacity of at least one candidate container to other containers of the same smart contract based on a preset load balancing rule.

[0172] Since the target container is the container with the smallest transaction carrying capacity among at least one container, when the target container meets the above-mentioned preset allocation conditions, it indicates that at least one container of the smart contract is overloaded, that is, the number of containers allocated to the smart contract is small, and the number of containers of the smart contract needs to be increased.

[0173] In an optional implementation, when the current transaction carrying capacity of the target container is greater than a preset carrying threshold, or the current transaction carrying capacity of the target container is greater than the minimum transaction carrying capacity of the container corresponding to other smart contracts, for at least one other smart contract to which multiple containers have been allocated, a candidate container with the smallest transaction carrying capacity is selected, and the current transaction carrying capacity of each candidate container is evenly distributed to other containers of the same smart contract, so that the transaction volumes processed by other containers are as similar as possible.

[0174] S6035_4: Obtain at least one container to be adjusted whose current transaction carrying capacity is greater than a preset upper limit from among the at least one container, and distribute the current transaction carrying capacity of each of the at least one container to be adjusted to at least one candidate container.

[0175] In specific applications, after the first transaction data processed by each candidate container is allocated to other containers under the same smart contract, each candidate container becomes an idle container. Therefore, the first transaction data processed by at least one container to be adjusted whose current transaction carrying capacity is greater than the preset upper limit in at least one container of the smart contract can be evenly allocated to each candidate container to increase the number of containers of the smart contract. At the same time, the number of first transaction data processed by the container to be adjusted is reduced, thereby improving the overall operation speed of each container.

[0176] S504: The network node generates a new block based on at least one transaction result obtained, and saves the new block on the chain after the new block passes the consensus verification with other nodes that have a consensus mechanism between the network nodes.

[0177] When all the acquired transaction data are processed, a new block is generated based on at least one transaction result and broadcast to the blockchain. In the blockchain, since each network node is decentralized and parallel, in order to maintain the stability and fairness of the blockchain, each network node needs to verify the new block through the consensus mechanism, and after the consensus verification is passed, the new block is saved on the chain.

[0178] It should be noted that the embodiments of the present application do not impose any restrictions on the consensus mechanism of the new block, including but not limited to Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT), etc.

[0179] As an example, based on Figure 3 The system architecture shown, Figure 7 The specific process of dynamically allocating containers for a smart contract is given, which mainly includes the following steps:

[0180] S701: The virtual machine module initializes a contract container pool including multiple runC containers.

[0181] Among them, each smart contract can correspond to multiple runC containers.

[0182] S702: The block scheduling module initializes the container transaction queue of each runC container.

[0183] Each container transaction queue is used to store the first transaction data processed by a runC container.

[0184] S703: The block scheduling module obtains the corresponding smart contract A for the received first transaction data 1.

[0185] S704: The block scheduling module obtains the contract container table of smart contract A.

[0186] Among them, the contract container table records the runC container allocated to smart contract A.

[0187] S705: The block scheduling module queries whether there is an idle container in the contract container pool. If so, execute S706; if not, execute S707.

[0188] Among them, the idle container is a container that is not assigned to any smart contract, that is, the amount of transaction data that needs to be processed by it is zero.

[0189] S706: The block scheduling module allocates the idle container to smart contract A to process the first transaction data 1.

[0190] Take the case where the contract container pool contains 3 containers. Assume that the initialization result of the contract container pool is as follows: Fig. 8AAs shown, runC container 1 in the contract container pool has been allocated to smart contract B and smart contract C, runC container 2 has been allocated to smart contract B, and runC container 3 has not been allocated to any smart contract and becomes an idle container. Therefore, runC container 3 is allocated to smart contract A to process the first transaction data 1.

[0191] S707: The block scheduling module queries whether smart contract A has been allocated at least one runC container based on the contract container table. If so, execute S708; if not, execute S712.

[0192] S708: Select a target container with the smallest transaction carrying capacity from at least one runC container of smart contract A to call smart contract A to process the first transaction data 1.

[0193] Assume that the contract container table records that runC container 3 has been allocated to smart contract A. Therefore, runC container 3 is selected to call smart contract A to process the first transaction data 1.

[0194] S709: Determine whether the current transaction carrying capacity of the target container is greater than the preset carrying threshold, or whether the current transaction carrying capacity of the target container is greater than the minimum transaction carrying capacity of the container corresponding to other smart contracts. If so, execute S710, if not, end.

[0195] like Figure 8B As shown, after using runC container 3 to call smart contract A to process the first transaction data 1, in order to avoid the transaction carrying capacity of runC container 3 being too large and thus reducing the overall operating speed of each container, it is necessary to compare the transaction carrying capacity of runC container 3 with the preset carrying threshold and the minimum transaction carrying capacity of runC containers corresponding to smart contracts B and C, so as to meet the load balancing principle and ensure the overall operating efficiency of the blockchain.

[0196] S710: Select a candidate container with the smallest transaction carrying capacity from multiple containers of other smart contracts, and distribute the current transaction carrying capacity of the candidate container to other containers of the same smart contract.

[0197] In one example, when the current transaction carrying capacity of runC container 3 is greater than the preset carrying threshold, or when the current transaction carrying capacity of runC container 3 is greater than the minimum transaction carrying capacity of the containers corresponding to smart contracts B and C, it is necessary to increase the container allocated to smart contract A.

[0198] like Figure 8BAs shown, the number of containers corresponding to smart contract C is equal to 1, and the number of containers corresponding to smart contract B is greater than 1, so a candidate container is selected from runC container 1 and runC container 2 corresponding to smart contract B. Assuming that the transaction carrying capacity of runC container 2 is less than the transaction carrying capacity of the container, runC container 2 is added as a candidate container to smart contract A, and the first transaction data of smart contract B processed by runC container 2 is distributed to runC container 1 for processing.

[0199] S711: Allocate the transaction carrying capacity of the container to be adjusted whose current transaction carrying capacity is greater than the preset upper limit in the container corresponding to smart contract A to the candidate container.

[0200] like Figure 8B As shown, the transaction carrying capacity of runC container 3 is overloaded, and runC container 2 is ready to add smart contract A. Therefore, the first transaction data of smart contract A processed by runC container 3 can be evenly distributed to runC container 2 for processing, thereby reducing the processing pressure of runC container 3 and improving the overall running speed of each container.

[0201] S712: Select a candidate container with the smallest transaction carrying capacity from the containers of other smart contracts to which multiple containers have been allocated, and distribute the current transaction carrying capacity of the candidate container to other containers of the same other smart contract.

[0202] Assume that the initialization result of the contract container pool is as follows Figure 8C As shown, runC container 1 in the contract container pool has been allocated to smart contract B and smart contract C, runC container 2 has been allocated to smart contract B, and runC container 3 has been allocated to smart contract C. There is no idle container and no container allocated to smart contract A, and smart contract B and smart contract C correspond to two containers respectively. Therefore, at least one of the containers of smart contract B and smart contract C needs to be allocated to smart contract A. When the transaction carrying capacity of runC container 3 allocated to smart contract C is the smallest, runC container 3 is used as a candidate container allocated to smart contract A, and the first transaction data processed by runC container 3 calling smart contract C is allocated to runC container 1 for processing.

[0203] S713: Enable the candidate container to call smart contract A to process the first transaction data 1.

[0204] like Figure 8C As shown, after the first transaction data of the smart contract C processed by the runC container 3 is assigned to the runC container 1 for processing, the runC container 3 becomes an idle container. Therefore, the runC container 3 can be used to call the smart contract A to process the first transaction data 1.

[0205] In the embodiment of the present application, the contract container pool provided contains a fixed number of multiple containers, and can be shared by different smart contracts. Therefore, when calling a smart contract to process the corresponding transaction data, the number of containers corresponding to each smart contract can be dynamically adjusted based on the specific situation of the container allocated to each smart contract, so that when the total container resources are fixed, it can ensure that the container is quickly switched between different smart contracts, and realize the dynamic allocation of containers. In this way, it can avoid the problem of uneven execution speed when the transaction data volume of different smart contracts is greatly different, resulting in the overall running speed lag, and improve the overall operation efficiency of the blockchain. At the same time, because the runC container is lighter and has stronger isolation, it can run at high speed and concurrently when the transaction data volume of the block is large, thereby reducing the overhead of generating blocks and further improving the generation efficiency of the blockchain.

[0206] In some embodiments, the contract type of the transaction data obtained by the network node from the transaction pool may also be a creation contract, and such transaction data is recorded as the second transaction data. For each second transaction data, the network node also needs to create a new smart contract. The specific process is as follows Fig.9A As shown, it mainly includes the following steps:

[0207] S901: The network node creates a new contract task queue for each second transaction data.

[0208] Among them, each new contract task queue is used to store the first transaction data of calling the new smart contract.

[0209] S902: The network node creates a new directory in the project repository and saves the compiled binary file of the new smart contract into the new directory.

[0210] S903: The network node configures dependencies and function libraries for the new smart contract in the new directory, and modifies the container configuration file to start the new smart contract.

[0211] S904: After starting the new smart contract, the first transaction data that calls the new smart contract in a batch of transaction data is stored in the corresponding contract task queue for processing.

[0212] As an example, the process of creating and configuring a new smart contract on a network node is as follows: Fig. 9B As shown, since the embodiment of the present application uses the lightweight runC tool to run the container:

[0213] (1) First, you need to install the runC tool for running containers on the network node.

[0214] In an optional implementation, for network nodes of most Linux systems, a package manager may be used to install the runC tool.

[0215] For example, on Debian or Ubuntu, use the sudo apt-get install runc command to install the runC tool.

[0216] (2) Secondly, the network node generates a container configuration file.

[0217] In an optional implementation, a default configuration file may be generated using the runc spec command. The specific command is as follows:

[0218] mkdir mycontainer

[0219] cd mycontainer

[0220] runc spec

[0221] Through the above command, a container configuration file named config.json can be generated in the mycontainer directory.

[0222] (3) Then, create a new directory for storing the smart contract binary files.

[0223] In an optional implementation, the target object can create a directory for storing the binary files of the smart contract by entering the following command:

[0224] mkdir rootfs

[0225] cp / path / to / your / binary rootfs /

[0226] Through the above two commands, the network node can create a target named rootfs, which is the root file system of the container.

[0227] (4) Further, edit the container configuration file to specify the binary file to run.

[0228] In an optional implementation, during the editing process, args is changed to the path of the binary file relative to the rootfs directory, and the command is as follows:

[0229]

[0230] (5) Finally, use the runC tool to run the container.

[0231] In an alternative implementation, the container can be run using the following command:

[0232] sudo runc run mycontainer

[0233] This command will start a container and run the new smart contract binary in it, achieving process isolation.

[0234] Taking smart contracts as transfer contracts and loan contracts as examples, based on Figure 3 The system architecture shown in the figure describes the blockchain generation method based on smart contracts, including the whole process from smart contract creation to transaction processing, see Fig.10 , mainly includes the following steps:

[0235] S1001: Determine whether to compile the transfer contract, if so, execute S1002, if not, execute S1003.

[0236] When you need to install the runC tool to run the transfer contract called by the container, you need to compile it before calling it, otherwise you can call it directly.

[0237] S1002: Compile the transfer contract into a binary file locally.

[0238] When installing the transfer contract, the transfer contract written in the development language can be converted into a computer executable binary file through compilation.

[0239] S1003: Start a terminal device that can access the blockchain.

[0240] After the terminal device is activated, the object can conduct transactions through the terminal device.

[0241] S1004: The terminal device defines the input parameters of the transfer contract.

[0242] Optionally, the input parameters of the transfer contract include but are not limited to the information of the two parties to the transfer (such as the name and account number of the payee, the name and account number of the payee, etc.) and the transfer amount.

[0243] like Fig.11 As shown, subject AA transfers 3,000 yuan from account 123456 to account 1789034 of subject BB.

[0244] S1005: The network module receives the contract execution request sent by the terminal device.

[0245] In an optional implementation, the contract execution request includes input parameters, object signature, object identity information and other contents.

[0246] S1006-S1007: The authentication module performs signature verification on the object signature and determines whether the signature verification is successful. If so, execute S1008; if not, execute S1027.

[0247] In the blockchain, network nodes can improve the integrity and security of transaction data by verifying object signatures.

[0248] S1008-S1009: The authentication module verifies the object permissions and determines whether the permissions are verified. If so, execute S1010; if not, execute S1028.

[0249] In the blockchain, network nodes can use the object's identity to determine whether it is on the blacklist and whether it can run the transfer contract, thereby verifying the object's permissions.

[0250] S1010: The transaction pool module stores the transaction data corresponding to the transfer contract into the transaction pool.

[0251] Once the object's signature and permissions are verified, the transaction data corresponding to the transfer contract will be stored in the transaction pool.

[0252] It should be noted that a transaction pool stores all transaction data processed by a network node. Therefore, in addition to transfer transactions, it also includes other transactions.

[0253] S1011: When the preset block generation conditions are met, the block scheduling module selects a batch of transaction data from the transaction pool.

[0254] Optionally, the preset block generation conditions include but are not limited to the number of transactions in the transaction pool reaching a preset number threshold, reaching a preset block generation time, and the operation and maintenance personnel triggering a generation instruction based on actual conditions.

[0255] S1012~S1013: The block scheduling module traverses the transaction data, and determines whether the contract type of the traversed current transaction data is a creation class contract. If so, execute S1014, if not, execute S1018.

[0256] For example, when the contract type of the current transaction data is a loan contract in the creation class contract, the contract has not yet been published on the network node. Therefore, it is necessary to create a loan contract to process the loan transaction before processing the loan transaction.

[0257] For another example, when the contract type of the current transaction data is a transfer contract in the call class contract, the contract has been deployed on the network node. Therefore, there is no need to create a transfer contract to process the transfer transaction, and the transfer transaction can be processed directly.

[0258] S1014: The block scheduling module creates a new contract task queue based on the current transaction data.

[0259] For example, for a newly created loan contract, the block scheduling module creates a new contract task queue for the loan contract to store loan transactions.

[0260] S1015: The virtual machine module creates a new directory in the project repository and saves the compiled binary file of the loan contract into the new directory.

[0261] In specific applications, you can save the binary file of the loan contract into the root file system of the container by entering the command "cp / path / to / your / binary rootfs / ".

[0262] S1016: The virtual machine module configures dependencies and function libraries for the loan contract in a new directory.

[0263] S1017: The virtual machine module modifies the container configuration file to start the loan contract.

[0264] In specific applications, edit the config.json container configuration file and change args to the path of the binary file relative to the rootfs directory so that the loan contract can be started at any time.

[0265] S1018: The block scheduling module puts the current transaction data into the contract task queue corresponding to the corresponding smart contract.

[0266] For example, when the current transaction data is a transfer transaction, it is stored in the contract task queue corresponding to the transfer contract. When the current transaction data is a loan transaction, it is stored in the contract task queue corresponding to the loan contract.

[0267] S1019: The block scheduling module determines whether the traversal of this batch of transaction data is complete. If so, execute S1020; if not, return to S1012.

[0268] S1020: The block scheduling module allocates containers to each smart contract based on the current transaction carrying capacity of each container in the contract container pool.

[0269] Among them, the number of containers corresponding to each smart contract is not fixed, but can be dynamically adjusted according to the amount of transaction data corresponding to the smart contract, and each container can call different smart contracts for transaction processing. The dynamic allocation process of containers is shown in 7 and will not be repeated here.

[0270] S1021: The block scheduling module schedules each container to call the corresponding smart contract to process the transaction data.

[0271] like Fig.11As shown, assuming that container 1 is allocated to the transfer contract, start the runC tool to run container 1 to call the transfer contract to process the transfer transaction, thereby transferring 3,000 yuan from the account 123456 of object AA to the account 1789034 of object BB.

[0272] S1022: After all the transaction data in this batch are processed, the block scheduling module generates a new block and sends the new block to other network nodes in the blockchain.

[0273] S1023~S1024: The consensus module votes on the new block and determines whether the consensus is passed. If so, execute S1025, if not, execute S1026.

[0274] In one example, assuming that the number of votes for the new block from each network node exceeds half, it is determined that the new block has passed the consensus; otherwise, it is determined that the new block has not passed the consensus.

[0275] S1025: The storage module stores the new block in the block ledger and updates the status database.

[0276] S1026: The network module returns a prompt indicating that consensus verification has failed.

[0277] When a new block fails to pass consensus, a prompt indicating that consensus verification failed is returned.

[0278] S1027: The network module returns a prompt indicating that the signature verification failed.

[0279] When the object signature verification fails, a prompt indicating that the signature verification failed is returned.

[0280] S1028: The network module returns a prompt indicating that the permission verification failed.

[0281] When the object signature verification fails, a prompt indicating that the permission verification failed is returned.

[0282] In the embodiment of the present application, the container is run by the runC tool to call the smart contract in parallel to process the transaction data. Since runC is lightweight enough and supports various underlying environments, it is suitable for multi-contract task scenarios, thereby ensuring that the blockchain generation process is extremely lightweight, has high performance, concurrency, versatility and stable isolation; and since the total data volume of the container in the contract container pool is fixed and can be shared by different smart contracts, the dynamic flow of containers between different smart contracts can be achieved when the total container resources are fixed, which can avoid the problem of uneven execution speed when the transaction data volume of different smart contracts differs greatly, resulting in the overall lag of the blockchain, thereby improving the efficiency and stability of the blockchain operation.

[0283] Based on the same technical concept, an embodiment of the present application provides a blockchain generation device based on a smart contract, which can implement the above-mentioned blockchain generation method based on a smart contract and achieve the same technical effect.

[0284] See also Fig.12 The device includes an acquisition module 1201, a transaction storage module 1202, a container allocation module 1203, and a generation module 1204, wherein:

[0285] The acquisition module 1201 is used to select a batch of transaction data from the transaction pool when the preset block generation conditions are met, and respectively obtain the contract type of each transaction data;

[0286] The transaction storage module 1202 is used to store at least one first transaction data in a batch of transaction data into a contract task queue; wherein each first transaction data corresponds to a smart contract whose contract type is a call contract;

[0287] The container allocation module 1203 is used to perform the following operations for at least one smart contract obtained: based on the current transaction carrying capacity of each container in the contract container pool maintained by the network node, select at least one target container from the contract container pool, and use the at least one target container to call a smart contract to process the corresponding first transaction data in the contract task queue to obtain a transaction result;

[0288] The block generation module 1204 is used to generate a new block based on at least one transaction result obtained, and save the new block on the chain after the new block passes the consensus verification with other nodes that have a consensus mechanism between network nodes.

[0289] Optionally, the container allocation module 1203 is specifically used for:

[0290] Querying whether there is at least one idle container in the contract container pool to which the first transaction data is not allocated;

[0291] If yes, use at least one free container as at least one target container of a smart contract;

[0292] Otherwise, query whether a smart contract has been allocated at least one container;

[0293] When a smart contract is not assigned any container, select at least one target container from the containers in the contract container pool that have been assigned to other smart contracts;

[0294] When a smart contract has been allocated at least one container, a target container is selected based on the current transaction carrying capacity of the at least one container.

[0295] Optionally, the container allocation module 1203 is specifically used for:

[0296] For at least one other smart contract that has been assigned multiple containers, the following operations are respectively performed: from multiple containers of one other smart contract, a candidate container is selected in order of transaction carrying capacity from small to large, and based on a preset load balancing rule, the current transaction carrying capacity of a candidate container is distributed to other containers of one other smart contract;

[0297] At least one selected candidate container is used as at least one target container of a smart contract.

[0298] Optionally, the container allocation module 1203 is specifically used for:

[0299] Selecting a target container from at least one container in ascending order of transaction carrying capacity, and determining whether the target container meets a preset allocation condition;

[0300] If the target container meets the preset allocation conditions, a candidate container is selected from multiple containers of at least one other smart contract in the order of transaction carrying capacity from small to large, and the current transaction carrying capacity of at least one candidate container is distributed to other containers of the same smart contract based on the preset load balancing rule;

[0301] At least one container to be adjusted whose current transaction carrying capacity is greater than a preset upper limit is obtained from at least one container, and the current transaction carrying capacity of each of the at least one container to be adjusted is distributed to at least one candidate container.

[0302] Optionally, the preset allocation condition includes at least one of the following:

[0303] The current transaction capacity of the target container is greater than the preset capacity threshold;

[0304] The current transaction capacity of the target container is greater than the minimum transaction capacity of the containers corresponding to other smart contracts.

[0305] Optionally, the device further includes a contract installation module 1205, which is used to create a new contract task queue for at least one second transaction data in a batch of transaction data whose contract type is a creation-type contract, and each new contract task queue is used to store the first transaction data for calling the new smart contract;

[0306] Create a new directory in the project repository and save the compiled binary file of the new smart contract to the new directory;

[0307] Configure dependencies and libraries for the new smart contract in a new directory and modify the container configuration file to start the new smart contract.

[0308] Optionally, after starting a new smart contract, the transaction storage module 1202 is also used to:

[0309] The first transaction data that calls a new smart contract in a batch of transaction data is stored in the corresponding contract task queue.

[0310] Optionally, the device further includes a security verification module 1206. Before selecting a batch of transaction data from the transaction pool, the security verification module 1206 is used to:

[0311] Receive at least one smart contract published by the target object;

[0312] At least one of the signature and permission of the target object;

[0313] After the security verification is passed, the first transaction data of at least one contract is stored in the transaction pool.

[0314] Optionally, each container in the contract container pool corresponds to a container transaction queue for storing the first transaction data processed by it, and each container transaction queue is stored on a device located outside the network node.

[0315] Optionally, the container type is a runc container.

[0316] The blockchain generation device based on smart contracts provided in the embodiment of the present application proposes the concept of a contract container pool. Each network node maintaining the blockchain maintains a contract container pool containing multiple containers, and the containers in the contract container pool are shared by different smart contracts. In this way, when the preset block generation conditions are met, for at least one smart contract that calls a class contract, the corresponding first transaction data is stored in the contract task queue respectively. Based on the current transaction carrying capacity of each container in the contract container pool, at least one target container is selected from the contract container pool for each smart contract to call each smart contract to process the corresponding first transaction data in the contract task queue. Therefore, when the total container resources are fixed, container resources can be dynamically allocated to each smart contract based on the current transaction carrying capacity of each container, avoiding the problem of uneven running speed when the transaction data corresponding to different smart contracts differ greatly, resulting in the overall generation speed of the blockchain lagging behind, and improving the speed of generating new blocks based on the transaction results of each transaction data, thereby improving the overall operation efficiency of the regional chain; and, since each container is an independent operating environment and is lightweight, each container can be executed in parallel when calling a smart contract, reducing resource overhead, thereby further improving the operation efficiency of the blockchain.

[0317] Based on the same inventive concept as the above method embodiment, an electronic device is also provided in the embodiment of the present application. In one embodiment, the electronic device may be a network node in a blockchain. In this embodiment, the structure of the electronic device may be as follows: Fig.13 As shown, it includes a memory 1301 , a communication module 1303 and one or more processors 1302 .

[0318] The memory 1301 is used to store computer programs executed by the processor 1302. The memory 1301 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and an operating instruction set.

[0319] The memory 1301 may be a volatile memory, such as a random-access memory (RAM); the memory 1301 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD); or the memory 1301 may be any other medium that can be used to carry or store a desired computer program in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1301 may be a combination of the above memories.

[0320] The processor 1302 may include one or more central processing units (CPU) or a digital processing unit, etc. The processor 1302 is used to implement the above-mentioned smart contract-based blockchain generation method when calling the computer program stored in the memory 1301.

[0321] The communication module 1303 is used to communicate with terminal devices and other servers.

[0322] The specific connection medium between the memory 1301, the communication module 1303 and the processor 1302 is not limited in the embodiment of the present application. Fig.13 In the embodiment, the memory 1301 and the processor 1302 are connected via a bus 1304. The bus 1304 is connected to the processor 1302 via a bus 1304. Fig.13 The connections between the other components are only for illustration and are not intended to be limiting. The bus 1304 can be divided into an address bus, a data bus, a control bus, etc. For ease of description, Fig.13 The diagram shows that only one thick line is used, but this does not mean that there is only one bus or only one type of bus.

[0323] The memory 1301 stores a computer storage medium, and the computer storage medium stores computer executable instructions, which are used to implement the blockchain generation method based on smart contracts in the embodiment of the present application. The processor 1302 is used to execute the steps of the blockchain generation method based on smart contracts.

[0324] In some possible implementations, various aspects of the smart contract-based blockchain generation method provided in the present application may also be implemented in the form of a program product, which includes a computer program. When the program product is run on an electronic device, the computer program is used to enable the electronic device to execute the steps of the smart contract-based blockchain generation method according to various exemplary embodiments of the present application described above in this specification.

[0325] The program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0326] The program product of the embodiment of the present application may adopt a portable compact disk read-only memory and include a computer program, and can be run on an electronic device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium containing or storing a program, which can be used by or in combination with a command execution system, apparatus, or device.

[0327] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, wherein a readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with a command execution system, apparatus, or device.

[0328] The computer program embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0329] The computer program for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The computer program may be executed entirely on the user computing device, partially on the user computing device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network or a wide area network, or may be connected to an external computing device.

[0330] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain a computer-usable computer program.

[0331] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

Claims

1. A method for generating a blockchain based on a smart contract, characterized in that: Applied to a network node for maintaining a blockchain, the method comprises: When the preset block generation conditions are met, a batch of transaction data is selected from the transaction pool, and the contract type of each transaction data is obtained respectively; Store at least one first transaction data in the batch of transaction data into a contract task queue; wherein each first transaction data corresponds to a smart contract whose contract type is a call contract; For at least one smart contract obtained, the following operations are performed respectively: based on the current transaction carrying capacity of each container in the contract container pool maintained by the network node, at least one target container is selected from the contract container pool, and the at least one target container is used to call a smart contract to process the corresponding first transaction data in the contract task queue to obtain a transaction result; A new block is generated based on at least one transaction result obtained, and after the new block passes the consensus verification with other nodes having a consensus mechanism between the network nodes, the new block is stored on the chain.

2. The method according to claim 1, characterized in that The step of selecting at least one target container from the contract container pool maintained by the network node for a smart contract based on the transaction quantity allocated to each container in the contract container pool maintained by the network node includes: Querying whether there is at least one idle container in the contract container pool to which the first transaction data is not allocated; If yes, use the at least one free container as at least one target container of the smart contract; Otherwise, query whether the smart contract has been allocated at least one container; When no container is allocated to the smart contract, at least one target container is selected from the containers in the contract container pool that have been allocated to other smart contracts; When at least one container has been allocated to the smart contract, a target container is selected based on the current transaction carrying capacity of each of the at least one container.

3. The method according to claim 2, characterized in that The selecting at least one target container from the containers in the contract container pool that have been allocated to other smart contracts includes: For at least one other smart contract that has been assigned multiple containers, the following operations are respectively performed: from multiple containers of the other smart contract, a candidate container is selected in order of transaction carrying capacity from small to large, and based on a preset load balancing rule, the current transaction carrying capacity of the candidate container is distributed to other containers of the other smart contract; At least one selected candidate container is used as at least one target container of the smart contract.

4. The method according to claim 2, characterized in that The selecting a target container based on the current transaction carrying capacity of each of the at least one container includes: Selecting a target container from the at least one container in ascending order of transaction carrying capacity, and determining whether the target container meets a preset allocation condition; If the target container meets the preset allocation conditions, a candidate container is selected from multiple containers of at least one other smart contract in the order of transaction carrying capacity from small to large, and based on the preset load balancing rule, the current transaction carrying capacity of at least one candidate container is distributed to other containers of the same smart contract; At least one container to be adjusted whose current transaction carrying capacity is greater than a preset upper limit in the at least one container is obtained, and the current transaction carrying capacity of each of the at least one container to be adjusted is distributed to the at least one candidate container.

5. The method according to claim 4, characterized in that The preset allocation condition includes at least one of the following: The current transaction carrying capacity of the target container is greater than a preset carrying threshold; The current transaction carrying capacity of the target container is greater than the minimum transaction carrying capacity of the containers corresponding to other smart contracts.

6. The method according to claim 1, characterized in that For at least one second transaction data in the batch of transaction data whose contract type is a creation-type contract, the method further includes: Creating a new contract task queue for each of the at least one second transaction data, each new contract task queue being used to store the first transaction data for invoking a new smart contract; Create a new directory in the project repository and save the compiled binary file of the new smart contract into the new directory; Configure dependencies and function libraries for the new smart contract in the new directory, and modify the container configuration file to start the new smart contract.

7. The method according to claim 6, characterized in that After starting the new smart contract, the method further includes: The first transaction data that calls the new smart contract in the batch of transaction data is stored in the corresponding contract task queue.

8. The method according to any one of claims 1 to 7, characterized in that Before selecting a batch of transaction data from the transaction pool, the method further includes: Receive at least one smart contract published by the target object; A security authentication of at least one of a signature and an authority of the target object; After the security verification is passed, the first transaction data of each of the at least one contract is stored in the transaction pool.

9. The method according to any one of claims 1 to 7, characterized in that Each container in the contract container pool corresponds to a container transaction queue for storing the first transaction data processed by it, and each container transaction queue is stored on a device located outside the network node.

10. The method according to any one of claims 1 to 7, characterized in that The type of the container is a runc container.

11. A blockchain generation device based on smart contracts, characterized in that: include: The acquisition module is used to select a batch of transaction data from the transaction pool when the preset block generation conditions are met, and obtain the contract type of each transaction data respectively; A transaction storage module, used to store at least one first transaction data in the batch of transaction data into a contract task queue; wherein each first transaction data corresponds to a smart contract whose contract type is a call contract; The container allocation module is used to perform the following operations for at least one obtained smart contract: based on the current transaction carrying capacity of each container in the contract container pool maintained by the network node, select at least one target container from the contract container pool, and use the at least one target container to call a smart contract to process the corresponding first transaction data in the contract task queue to obtain a transaction result; The block generation module is used to generate a new block based on at least one transaction result obtained, and after the new block passes the consensus verification with other nodes having a consensus mechanism between the network nodes, the new block is stored on the chain.

12. An electronic device, characterized in that: The invention comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of any one of the methods of claims 1-10.

13. A computer-readable storage medium, characterized in that: The method comprises a computer program. When the computer program is run on an electronic device, the computer program is used to make the electronic device execute the steps of any one of the methods of claims 1 to 10.

14. A computer program product, characterized in that It includes a computer program, which is stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, so that the electronic device executes the steps of any method described in claims 1-10.

Images