Method for operating a blockchain network and blockchain network

Abstract

The present disclosure relates to a method for operating a blockchain network, comprising: configuring one or more nodes of nodes of the blockchain network to be implemented based on a serverless system, wherein each of the one or more nodes is provided with an API gateway and a serverless engine by a corresponding serverless system; and for each of the one or more nodes: receiving a transaction via the API gateway; in response to receiving a transaction event, the serverless engine allocating memory and computing resources to create one or more computing instances for transaction processing; and in response to not receiving an event within a predetermined time, the serverless engine releasing the memory and computing resources to destroy the created one or more computing instances. The present disclosure also relates to a method for operating a node in a blockchain network, a blockchain network, and a node in a blockchain network.

Description

Technical Field

[0001] This disclosure relates to one or more embodiments of a blockchain network operation method, a node operation method in a blockchain network, a blockchain network, and a node in a blockchain network. Background Technology

[0002] Typically, during the operation of a blockchain network, each node remains operational for extended periods. This can lead to significant waste of operating costs for low-frequency (or even ultra-low-frequency) transactions. Low-frequency (or even ultra-low-frequency) transactions may occur in the application of consortium blockchain technology, such as bidding transactions involving multiple parties.

[0003] With the development of blockchain technology, business processing models based on consortium blockchain networks are becoming increasingly common. Multiple service providers can form a consortium, and each service provider's server (or server cluster) can be considered a node in the consortium blockchain network. For any given service provider, the nodes managed by that service provider are typically responsible for accepting business-related transactions initiated by its clients, broadcasting these transactions to the entire network, and having each node execute the transactions and write them to the blockchain for distributed notarization. Summary of the Invention

[0004] One of the objectives of this disclosure is to provide a method for operating a blockchain network, a method for operating nodes in a blockchain network, a blockchain network, and nodes in a blockchain network.

[0005] According to one aspect of one or more embodiments of this disclosure, a method for operating a blockchain network is provided, comprising: configuring one or more nodes of the blockchain network to be implemented based on a serverless system, wherein each of the one or more nodes is provided with an API gateway and a serverless engine by a corresponding serverless system; and for each of the one or more nodes: receiving a transaction through the API gateway; in response to receiving a transaction event, allocating memory and computing resources in the serverless engine to create one or more computing instances for transaction processing; and in response to not receiving an event within a predetermined time, releasing memory and computing resources in the serverless engine to destroy the one or more computing instances created.

[0006] According to another aspect of one or more embodiments of this disclosure, a method for operating a blockchain network is provided, comprising: configuring one or more nodes of the blockchain network as being implemented based on a serverless system, wherein each of the one or more nodes is provided with an API gateway, a serverless engine, and a backend storage service by a corresponding serverless system; and for a first node of the one or more nodes: receiving a transaction from a client via the API gateway; in response to receiving a transaction event, allocating memory and computing resources in the serverless engine to create one or more computing instances for transaction verification; in response to successful transaction verification, sending an activation event to a second node of the one or more nodes; in response to meeting block production conditions, generating a block through the one or more computing instances and performing a consensus process with other nodes of the blockchain network for the block; and in response to successful consensus, chain-storing the block through the backend storage service.

[0007] According to another aspect of one or more embodiments of this disclosure, a method for operating a blockchain network is provided, comprising: configuring one or more nodes of the blockchain network to be implemented based on a serverless system, wherein each of the one or more nodes is provided with a serverless engine by a corresponding serverless system; and for each of the one or more nodes: running in an inactive state; being activated in response to receiving an event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction processing; and in response to not receiving an event within a predetermined time, the serverless engine releases memory and computing resources to destroy the one or more computing instances created, and returns to running in the inactive state.

[0008] According to another aspect of one or more embodiments of this disclosure, a method for operating a node in a blockchain network is provided, comprising: implementing the node based on a serverless system, wherein the serverless system provides an API gateway, a serverless engine, and backend storage services; receiving transactions through the API gateway; in response to receiving a transaction event, allocating memory and computing resources in the serverless engine to create one or more computing instances for transaction processing; and in response to not receiving an event within a predetermined time, releasing memory and computing resources in the serverless engine to destroy the one or more computing instances created.

[0009] According to another aspect of one or more embodiments of this disclosure, a blockchain network is provided, comprising a plurality of nodes, wherein each of the plurality of nodes is implemented based on a serverless system and is provided with an API gateway, a serverless engine, and a backend storage service by a corresponding serverless system, wherein the plurality of nodes includes a first node configured to: receive transactions from clients via an API gateway; in response to receiving a transaction event, allocate memory and computing resources in the serverless engine to create one or more computing instances for transaction verification; in response to successful transaction verification, send an activation event to a second node among the one or more nodes; in response to meeting block production conditions, generate a block through the one or more computing instances and conduct a consensus process with other nodes of the blockchain network for the block; and in response to successful consensus, chain-store the block through the backend storage service.

[0010] According to another aspect of one or more embodiments of this disclosure, a node in a blockchain network is provided, which is implemented based on a serverless system, including a serverless engine provided by the serverless system, wherein the serverless engine is configured to: run in an inactive state; be activated in response to receiving an event, allocate memory and computing resources to create one or more computing instances for transaction processing; and in response to not receiving an event within a predetermined time, release memory and computing resources to destroy the one or more computing instances created, and return to running in the inactive state.

[0011] Other features and advantages of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0012] The accompanying drawings, which form part of this specification, illustrate one or more embodiments of this disclosure and, together with the specification, serve to explain the principles of one or more embodiments of this disclosure.

[0013] One or more embodiments of this disclosure can be more clearly understood with reference to the accompanying drawings and the following detailed description, wherein:

[0014] Figure 1 This is a schematic diagram of an example consortium blockchain network;

[0015] Figure 2 This is a partial flowchart of a method for operating a blockchain network according to one or more exemplary embodiments of this disclosure;

[0016] Figures 3 to 5This is a schematic diagram illustrating a method of operating a blockchain network according to one or more exemplary embodiments of this disclosure;

[0017] Figures 6 to 8 This is a schematic diagram of a blockchain network according to one or more exemplary embodiments of this disclosure. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments in this specification, and not all of them. However, it should be understood that one or more embodiments of this disclosure can be presented in many different ways and are not limited to the embodiments described below. It should also be understood that one or more embodiments of this disclosure can be combined in various ways to provide more additional embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0019] It should be understood that the same reference numerals denote the same elements in all the accompanying drawings. For clarity, the dimensions of certain features may be modified in the drawings.

[0020] It should be understood that the terminology used herein is for describing specific embodiments only and is not intended to be limiting. All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. For the sake of brevity and / or clarity, well-known functions or structures may not be described in detail.

[0021] In this document, the term "connection" is intended to encompass a physical, electrical, and / or communicative connection between one feature and another feature, and there may or may not be an intermediate feature between the two features. When the connection is a communicative connection, even if A and B are mentioned as "directly connected," it is only intended to emphasize that the connection between A and B does not involve one or more features emphasized in one or more embodiments of this disclosure, but does not imply a limitation that A and B can be connected without any components. Those skilled in the art will understand that A and B can be connected via cables, routers, gateways, channels, links, networks, etc. It should be noted that in the accompanying drawings of one or more embodiments of this disclosure, whether the connection between A and B is direct or indirect, it is represented by a straight line or other graphic element connecting A and B.

[0022] In this document, the term “A or B” includes both “A and B” and “A or B”, rather than exclusively including only “A” or only “B”, unless otherwise specified.

[0023] In this document, the term "exemplary" means "used as an example, instance, or illustration," and not as a "model" to be precisely copied. Any implementation described herein is not necessarily to be construed as preferred or advantageous over other implementations. Moreover, one or more embodiments of this disclosure are not limited to any expressed or implied theory given in the foregoing technical field, background, summary of invention, or detailed description.

[0024] In this document, the term "substantially" means any minor variation caused by design or manufacturing defects, device or component tolerances, environmental influences, and / or other factors. The term "substantially" also allows for differences from the perfect or ideal situation due to parasitic effects, noise, and other practical considerations that may exist in actual implementations.

[0025] Additionally, terms such as “first,” “second,” etc., may be used in this document for reference purposes only and are not intended to be limiting. For example, unless the context clearly indicates otherwise, the words “first,” “second,” and other such numerical terms relating to structures or elements do not imply order or sequence.

[0026] It should also be understood that when the term “including / contains” is used herein, it indicates the presence of the indicated feature, whole, step, operation, unit and / or component, but does not preclude the presence or addition of one or more other features, wholes, steps, operations, units and / or components and / or combinations thereof.

[0027] It should be noted that the transaction described in this specification refers to a piece of data created by a user through a blockchain client and ultimately published to the blockchain's distributed database. A transaction is a data structure defined in the blockchain protocol; for a piece of data to be stored on the blockchain, it needs to be encapsulated as a transaction.

[0028] Transactions in blockchain can be categorized into narrow and broad definitions. A narrow transaction refers to a value transfer initiated by a user on the blockchain; for example, in a traditional blockchain network, a transaction might be a transfer initiated by a user. A broad transaction, on the other hand, refers to business data with a specific intent that a user submits to the blockchain. For instance, an operator might build a consortium blockchain based on actual business needs, deploying other types of online services unrelated to value transfer (such as rental services, vehicle dispatching, insurance claims, credit services, and medical services). In such a consortium blockchain, a transaction could be a business message or request with a specific business intent submitted by a user.

[0029] In this article, the client initiates a business, that is, the client initiates a business-related transaction (referred to as a business-related transaction in this article).

[0030] Figure 1 This is a schematic diagram of an example consortium blockchain network. This example consortium blockchain network has multiple participants, each of whom can have one or more consortium blockchain nodes. Each consortium blockchain node can receive transactions from the clients served by that participant, and these transactions are executed and stored in a distributed manner by the nodes across the consortium blockchain network.

[0031] For low-frequency (or even ultra-low-frequency) transaction scenarios, such as bidding transactions involving multiple parties, the current approaches include: Approach 1: Not using blockchain technology. This approach uses a traditional ledger model, the disadvantage of which is the difficulty in preventing information tampering. Approach 2: Running individual nodes in the blockchain for an extended period. In this approach, due to the extremely low transaction frequency, the cost per transaction becomes very high. Approach 3: Spreading the blockchain's operating costs by mixing various transaction types. Because the business needs of consortium participants differ, it is difficult to unify the requirements for how to network and maintain the consortium blockchain, thus creating difficulties in consortium networking.

[0032] This disclosure provides a method for operating a blockchain network according to one or more embodiments, which implements at least one node in the blockchain network based on serverless technology. When a transaction occurs, an event triggers the computation instances of each node in the blockchain to complete the consensus and block production of the transaction. When no transactions occur within a certain period of time, the computation instances are destroyed, thereby saving operating costs.

[0033] Serverless is a cloud-native development model that allows developers to focus on building and running applications without managing servers. Servers still exist in serverless solutions, but they are decoupled from application development. Cloud providers handle routine tasks such as provisioning, maintaining, and scaling server infrastructure. Developers can simply package their code into containers for deployment. Once deployed, serverless applications respond to demand and automatically scale as needed. Serverless products from public cloud providers are typically metered on demand using an event-driven execution model. Therefore, there are no charges when serverless functionality is idle.

[0034] The difference between serverless computing and other cloud computing models lies in the fact that the cloud provider manages the cloud infrastructure and application scaling. Serverless applications are deployed in containers, which automatically start on demand when invoked. In the standard Infrastructure as a Service (IaaS) cloud computing model, users need to pre-purchase capacity units. That is, they must pay the public cloud provider for always-available server components to run the application. Users are responsible for scaling up server capacity when demand is high and scaling down when it is no longer needed. Even when the application is idle, the cloud infrastructure required to run the application must remain ready. Serverless architecture is the opposite; applications only start when needed. The public cloud provider allocates resources to the application code only when an event triggers its execution. Once the code finishes executing, the user no longer pays. In addition to cost and efficiency advantages, serverless computing also frees developers from the tedious daily tasks associated with application scaling and server provisioning.

[0035] When using serverless computing, routine tasks such as managing the operating system and file system, security patching, load balancing, capacity management, scaling, logging, and monitoring are all handled by the cloud service provider. You can build fully serverless applications, or you can create applications that incorporate some serverless components and some traditional microservice components.

[0036] In the serverless model, the cloud provider runs the physical servers and dynamically allocates resources on behalf of the user, who can then directly deploy their code to the production environment. Serverless computing products are generally divided into two categories: Backend as a Service (BaaS) and Function as a Service (FaaS). BaaS allows developers to access a wide variety of third-party services and applications. For example, cloud providers can offer authentication services, additional encryption, cloud access to databases, and high-confidence data usage. In BaaS, serverless functions are typically invoked through application programming interfaces (APIs). Under FaaS, developers still need to write custom server-side logic, but it can run in containers that are fully managed by the cloud service provider.

[0037] Figure 2 This is a partial flowchart of a method 100 for operating a blockchain network according to one or more exemplary embodiments of this disclosure.

[0038] The blockchain network can be a consortium blockchain or other types of blockchain networks. In the case of a consortium blockchain, each node in the blockchain network can be associated with a corresponding participant in the consortium blockchain network and provide corresponding services.

[0039] In Method 100, one or more nodes in the blockchain network are configured to be implemented based on a serverless system. Each of these nodes is provided with a serverless engine by the corresponding serverless system. A serverless engine is a standardized concept, also known as a Serverless App Engine (SAE). It is an application-oriented serverless PaaS (Platform-as-a-Service) platform that helps PaaS layer users achieve low-barrier microservice application deployment to the cloud by eliminating the need for IaaS maintenance, using it on demand, and paying only for what they use. Compared to other serverless products, it abstracts the concept of applications and provides a complete microservice solution, supporting mainstream microservice development frameworks such as Spring Cloud, Dubbo, and HSF, achieving a perfect combination of serverless architecture and microservice architecture.

[0040] For each of the one or more nodes, for example, if no event is received, it runs in an inactive state (Operation 110). If the blockchain node receives an event and is activated, the serverless engine allocates memory and computing resources to create one or more compute instances for that node to process transactions (Operation 120). Compute instances are entities that provide computing power, such as ECS, Alibaba Cloud container instances, ECI instances, etc. Each serverless provider has its own way of creating compute instances. In a serverless scenario, compute instances can usually start quickly, for example, in milliseconds. For each of the one or more nodes, if an event indicating a new transaction is received after completing Operation 120, and one or more compute instances for that node have been created and not destroyed, these one or more compute instances can be used to process the new transaction. If no event to activate the blockchain node is received within a predetermined time after completing Operation 120, the serverless engine releases memory and computing resources to destroy the one or more compute instances created, thus restoring the node to an inactive state (Operation 130), i.e., returning to Operation 110.

[0041] In some embodiments, events received by a serverless node may include transaction events from its API gateway. These events could be triggered by transactions received from clients served by the blockchain network via the API gateway, or by other nodes in the blockchain network (including those based on or not based on serverless) via the API gateway. The client can be the initiator of the transaction. In some blockchain networks, such as the MyChain blockchain network, a client simply sends a transaction to a node in the blockchain network. When a client initiates a transaction to the API gateway, it triggers (or activates) the serverless engine of the blockchain node associated with that API gateway. Since this blockchain node needs to reach consensus with other nodes in the blockchain network, it needs to send events to other nodes, for example, via their API gateways, to trigger their serverless engines to achieve consensus. Upon receiving the trigger event, other nodes create (or use existing computing instances) to process the transaction. In this case, one node in the blockchain network is triggered by the client, while other nodes are triggered by that node. In other blockchain networks, such as the Fabric blockchain network, the client needs to send transactions to all participating nodes to collect endorsements. In this scenario, all participating nodes in the blockchain network can be triggered by the client.

[0042] API gateways can be provided by the serverless system on which the nodes are based. In a microservices scenario, each microservice has its own access endpoint. When services interact with each other, maintaining, configuring, and managing each microservice becomes difficult. In this situation, an API gateway can provide services to service consumers in a unified way, thereby simplifying service access. In this case, the API gateway acts as a facade for API access, and each microservice registers with the API gateway. By aggregating microservices through registration, the API gateway provides a unified access method for microservices, thus reducing the cost of using and managing microservices. Furthermore, API gateways also provide common services such as access control, degradation and rate limiting, security control, and lifecycle management to simplify the use of microservices.

[0043] In some embodiments, events received by a serverless node may include activation events from other serverless nodes, without going through an API gateway. In other words, interaction between serverless nodes can be achieved through an API gateway or through communication between serverless engines. For example, if nodes are deployed on different serverless service provider platforms, they typically cannot communicate directly and need to interact through an API gateway. If nodes are deployed on the same serverless service provider platform, and that platform provides a communication mechanism between serverless engines, such as calling storage, computing, or middleware services, then the two nodes can communicate directly through the serverless engines (without going through an API gateway).

[0044] Processing a transaction by one or more computing instances may include: verifying the transaction; executing the transaction in response to verification; generating a block and initiating a consensus process with other nodes in the blockchain network for that block in response to meeting block production conditions; and storing the block on a blockchain via a backend storage service in response to consensus passing. Block production conditions may include the block size reaching a given size, the number of transactions reaching a given number, or a given time elapsed (e.g., 3 seconds). In low-frequency transaction scenarios, a given time elapsed is typically used as the block production condition. After a block is produced, the blockchain node can initiate consensus or receive a consensus proposal.

[0045] For example, when a node is determined to be a ledger node through competition or negotiation, it can initiate consensus with other blockchain nodes (i.e., validator nodes). Specifically, the blockchain node generates a state tree, a transaction tree, and a receipt tree based on the transaction content and execution results of each transaction stored within it, and records the root hashes corresponding to the root nodes of these three trees in the block header. Then, the blockchain node packages a set of transactions and generates a new block, broadcasting the block or block header to each validator node, thus initiating a consensus proposal. The validator nodes execute the aforementioned set of transactions, verify the root hashes in the block header, and, after confirming that the proposal has passed verification, append the block containing this set of transactions to the end of the existing blockchain (also referred to as chained storage or on-chain storage), and update the world state based on the execution results of this set of transactions. The blockchain node can put the block on-chain after confirming that the consensus has passed; of course, it can also put it on-chain before confirming that the consensus has passed, and then roll back if a problem is found. When the blockchain node is a validator node rather than a ledger node, it can receive consensus proposals initiated by ledger nodes. The blockchain node can compare the root nodes of the three trees generated by its own node with the root nodes contained in the block header of the consensus proposal. If the comparison results are consistent, the consensus proposal is deemed to have passed verification; otherwise, it is deemed to have failed verification. After successful verification, the blockchain node stores the block in a chain using the backend storage service described below.

[0046] Serverless systems also provide backend storage services for blockchain nodes, serving as an intermediary service for providing storage functions (such as persistent storage capabilities). The backend storage service is not limited to the content stored; users can specify the storage performance and method, such as Alibaba Cloud NAS storage service, block storage, OSS, databases, etc. All content requiring storage can be stored using the backend storage service, for example, the state of each variable after the previous calculation. In one or more embodiments of this disclosure, serverless nodes can read the data required for transaction processing and / or store the results of transaction processing through the backend storage service. The content stored by serverless nodes through the backend storage service is no different from the content stored in existing blockchain networks, including but not limited to blocks, world state, node keys, etc. In existing blockchain networks, due to the high frequency of transactions, a transaction pool is needed to ensure that transactions have a temporary storage place before being packaged. However, in scenarios with low-frequency transactions, a transaction pool is not necessary. Typically, after a transaction occurs, a block is packaged within a specified time. A block contains only a limited number of blocks, so the role of the transaction pool is not very significant; received transactions can be temporarily stored in memory. In some cases, to avoid unexpected events, transaction logs, such as those from Red Hat, may be written, and these transaction logs can also be stored through a backend storage service.

[0047] The following is combined with Figures 3 to 5 A specific example is used to illustrate how a blockchain network operates according to one or more embodiments of this disclosure. For example... Figure 3 As shown, the client sends a transaction to the blockchain network, for example, by submitting the transaction to the API gateway of a serverless node (represented as "Blockchain Node 1" in the diagram). At this time, Blockchain Node 1 is inactive; it is not allocated computing or memory resources within the serverless platform, and the platform only runs a serverless engine service for it. Figure 4 As shown, after receiving a transaction event, the serverless engine allocates memory and computing resources to create one or more computing instances. It then reads data from the backend storage service as needed, such as historical transaction information, completes transaction verification, and sends an event to activate the corresponding consortium participant's node (shown as "Blockchain Node 2"). Upon receiving the activation event, Blockchain Node 2's serverless engine allocates memory and computing resources to create one or more computing instances and reads data from the backend storage service as needed to complete transaction verification and execution. All participating nodes then reach consensus and produce blocks, storing the execution results in the backend storage service. Figure 5 As shown, when the serverless engine of each node (represented as "blockchain node 1...N") does not receive any transaction requests during the set idle time period, it releases computing and memory resources to destroy one or more computing instances created and restores the system to an inactive state.

[0048] Figures 6 to 8 This is a schematic diagram of a blockchain network according to one or more exemplary embodiments of the present disclosure. In the blockchain networks according to various embodiments of the present disclosure, one or more nodes are implemented based on a serverless system. Figure 6 In the exemplary embodiment shown, all nodes in the blockchain network, illustrated as nodes 1 to 6, are implemented based on a serverless system, and all nodes are based on the same serverless system, illustrated as serverless system A. Figure 7 In the exemplary embodiment shown, all nodes in the blockchain network are implemented based on a serverless system, and each node is distributed across multiple serverless systems, illustrated as serverless systems A to C. Figure 8In the exemplary embodiment shown, some nodes of the blockchain network (nodes 1 to 4 shown) are implemented based on a serverless system, while other nodes (nodes 5 and 6 shown) are not implemented based on a serverless system.

[0049] In a blockchain network according to embodiments of this disclosure, one or more nodes are implemented based on a serverless system. A first node is configured to: receive transactions from clients via an API gateway; in response to receiving a transaction event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction verification; in response to successful transaction verification, send an activation event to a second node; in response to meeting block production conditions, generate a block using one or more computing instances and conduct a consensus process with other nodes in the blockchain network for the block; and in response to successful consensus, chain-store the block using a backend storage service. The second node is configured to: in response to receiving an activation event, allocate memory and computing resources to create one or more computing instances for transaction verification; in response to successful transaction verification and meeting block production conditions, generate a block using one or more computing instances and conduct a consensus process with other nodes in the blockchain network for the block; and in response to successful consensus, chain-store the block using a backend storage service.

[0050] Using the blockchain network and its operation method according to embodiments of this disclosure, when a transaction occurs, the consensus and block generation service capabilities of the transaction are provided through serverless technology. This eliminates the need to maintain long-running service nodes and only requires a small storage cost, greatly reducing the transaction cost of ultra-low frequency transaction blockchains.

[0051] The foregoing has described one or more exemplary embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0052] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0053] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0054] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0055] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0056] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0057] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0058] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0059] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0060] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0061] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0062] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0063] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take 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.) containing computer-usable program code.

[0064] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0065] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0066] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for operating a blockchain network, comprising: One or more nodes in a blockchain network are configured to be implemented using a serverless system, wherein each of the one or more nodes is provided with an API gateway, serverless engine, and backend storage service by a corresponding serverless system; and For each of the one or more nodes: Receive transactions via API gateway In response to receiving a transaction event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction processing. In response to receiving an activation event, the serverless engine allocates memory and computing resources to create one or more compute instances for transaction processing. In response to the fulfillment of block production conditions, a block is generated through one or more computing instances, and a consensus process is conducted with other nodes in the blockchain network for the block. In response to consensus approval, the blocks are stored in a chain through a backend storage service, and In response to the failure to receive an event within a predetermined time, the serverless engine releases memory and computing resources to destroy one or more computing instances that were created.

2. The method according to claim 1, further comprising: For each of the one or more nodes: The backend storage service reads the data required for transaction processing and / or stores the results of transaction processing.

3. The method according to claim 1 or 2, further comprising: For each of the one or more nodes: In response to successful transaction verification, an activation event is sent to the other nodes in the one or more nodes.

4. The method according to claim 1 or 2, further comprising: For each of the one or more nodes: Transactions are received from clients or other nodes in the blockchain network via an API gateway.

5. The method according to claim 1 or 2, wherein, The blockchain in question is a consortium blockchain.

6. A method for operating a blockchain network, comprising: One or more nodes in the blockchain network are configured to be implemented based on a serverless system, wherein each of the one or more nodes is provided with an API gateway, serverless engine and backend storage service by the corresponding serverless system; For the first node of the one or more nodes: Receive transactions from clients via API gateway In response to receiving a transaction event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction verification. In response to receiving an activation event, the serverless engine allocates memory and computing resources to create one or more compute instances for transaction processing. In response to successful transaction verification, an activation event is sent to the second node among the one or more nodes. In response to meeting the block production conditions, a block is generated through one or more computing instances, and a consensus process is performed on the block with other nodes in the blockchain network. In response to the consensus being passed, the blocks are stored in a chain through a backend storage service.

7. The method according to claim 6, further comprising: For the second node of the one or more nodes: In response to receiving an activation event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction verification; In response to successful transaction verification and fulfillment of block production conditions, a block is generated through one or more computing instances, and a consensus process is conducted with other nodes in the blockchain network for the block; and In response to the consensus being passed, the blocks are stored in a chain through a backend storage service.

8. The method according to claim 6 or 7, further comprising: For each of the one or more nodes: The data required for transaction processing is read from the backend storage service.

9. The method according to claim 6 or 7, further comprising: For each of the one or more nodes: In response to the failure to receive an event within a predetermined time, the serverless engine releases memory and computing resources to destroy one or more computing instances that were created.

10. The method according to claim 6 or 7, wherein, The blockchain in question is a consortium blockchain.

11. The method according to claim 6 or 7, wherein, The block production condition is after a given time has elapsed.

12. A method for operating a blockchain network, comprising: One or more nodes in a blockchain network are configured to be implemented using a serverless system, wherein each of the one or more nodes is provided with a serverless engine and backend storage services by a corresponding serverless system; and For each of the one or more nodes: Running in an inactive state Upon being activated by a received event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction processing. In response to the fulfillment of block production conditions, a block is generated through one or more computing instances, and a consensus process is conducted with other nodes in the blockchain network for the block. In response to the consensus being passed, the blocks are stored in a chain through a backend storage service. In response to the failure to receive an event within a predetermined time, the serverless engine releases memory and computing resources to destroy one or more computing instances created and restores them to an inactive state.

13. The method according to claim 12, wherein, The events include: Transaction events from the API gateway; or Activation events from other nodes in the one or more nodes.

14. The method according to claim 12 or 13, further comprising: For each of the one or more nodes: The backend storage service reads the data required for transaction processing and / or stores the results of transaction processing.

15. A method for operating a node in a blockchain network, comprising: This node is implemented based on a serverless system, which provides an API gateway, serverless engine, and backend storage services. Receive transactions via API gateway; In response to receiving a transaction event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction processing; In response to receiving an activation event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction processing; In response to the fulfillment of block production conditions, a block is generated through one or more computing instances, and a consensus process is conducted with other nodes of the blockchain network for the block; In response to the consensus being passed, the blocks are stored in a chain through a backend storage service; as well as In response to the failure to receive an event within a predetermined time, the serverless engine releases memory and computing resources to destroy one or more computing instances that were created.

16. The method of claim 15, further comprising: The backend storage service reads the data required for transaction processing and / or stores the results of transaction processing.

17. The method according to claim 15 or 16, further comprising: In response to successful transaction verification, an activation event is sent to the other nodes in the one or more nodes.

18. The method according to claim 15 or 16, further comprising: Transactions are received from clients or other nodes in the blockchain network via an API gateway.

19. The method according to claim 15 or 16, wherein, The blockchain in question is a consortium blockchain.

20. A blockchain network comprising one or more nodes implemented based on a serverless system, wherein the corresponding serverless system provides an API gateway, a serverless engine, and backend storage services, wherein, The one or more nodes include a first node, which is configured to: Receive transactions from clients via API gateway In response to receiving a transaction event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction verification. In response to receiving an activation event, the serverless engine allocates memory and computing resources to create one or more compute instances for transaction processing. In response to successful transaction verification, an activation event is sent to the second node among the one or more nodes. In response to meeting the block production conditions, a block is generated through one or more computing instances, and a consensus process is performed on the block with other nodes in the blockchain network. In response to the consensus being passed, the blocks are stored in a chain through a backend storage service.

21. The blockchain network according to claim 20, wherein, The second node is configured as follows: In response to receiving an activation event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction verification; In response to successful transaction verification and fulfillment of block production conditions, a block is generated through one or more computing instances, and a consensus process is conducted with other nodes in the blockchain network for the block; and In response to the consensus being passed, the blocks are stored in a chain through a backend storage service.

22. The blockchain network according to claim 20 or 21, wherein, Each of the one or more nodes is further configured to: The data required for transaction processing is read from the backend storage service.

23. The blockchain network according to claim 20 or 21, wherein, Each of the one or more nodes is further configured to: In response to the failure to receive an event within a predetermined time, the serverless engine releases memory and computing resources to destroy one or more computing instances that were created.

24. The blockchain network according to claim 20 or 21, wherein, The blockchain in question is a consortium blockchain.

25. The blockchain network according to claim 20 or 21, wherein, The block production condition is after a given time has elapsed.

26. A node in a blockchain network, implemented based on a serverless system, comprising a serverless engine and backend storage services provided by the serverless system, wherein, The serverless engine is configured as follows: Running in an inactive state Upon being activated by a received event, the serverless engine allocates memory and computing resources to create one or more computing instances for transaction processing. In response to the fulfillment of block production conditions, a block is generated through one or more computing instances, and a consensus process is conducted with other nodes in the blockchain network for the block. In response to consensus approval, the blocks are stored in a chain through a backend storage service, and In response to the failure to receive an event within a predetermined time, the serverless engine releases memory and computing resources to destroy one or more computing instances created and restores them to an inactive state.

27. The node according to claim 26, further comprising an API gateway provided by the serverless system, wherein, The API gateway is configured as follows: Receive transactions from the client and send transaction events to activate the serverless engine.

28. The node according to claim 26 or 27, wherein, The serverless engine is also configured as follows: It is activated by receiving activation events from other nodes in the blockchain network.

29. The node according to claim 26 or 27, wherein, The backend storage service is configured as follows: The backend storage service reads the data required for transaction processing and / or stores the results of transaction processing.

Images