A blockchain service management method and a blockchain node

By setting a proxy process as the parent process on the blockchain node, the problem of limited processing capacity and service interruption of the blockchain node is solved, achieving stable and scalable blockchain service management and avoiding the loss of access information.

CN114936116BActive Publication Date: 2026-04-21ANT BLOCKCHAIN TECHNOLOGY (SHANGHAI) CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-05-30
Publication Date
2026-04-21

AI Technical Summary

Technical Problem

Existing blockchain node service configuration schemes suffer from limited processing capacity, difficulty in meeting high throughput requirements, and service interruptions and loss of access information due to single-process failures.

Method used

By setting up a proxy process on the blockchain node as the parent process for all blockchain services, the proxy process listens to the network port and the child processes read the buffer data, thereby achieving service stability and scalability.

Benefits of technology

It ensures the stable operation of blockchain services, avoids service interruptions and loss of access information, supports high throughput requirements, and facilitates scalable adjustment of service capabilities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114936116B_ABST
    Figure CN114936116B_ABST
Patent Text Reader

Abstract

A blockchain service management method and a blockchain node are disclosed. The method is executed by the blockchain node, which runs a first process and a second process. The first process is the parent process of the second process. The second process is used to provide a first blockchain service. The first process listens on a first port. The second process obtains access information through a buffer corresponding to the first port. The method includes: the first process receiving an exit message indicating that the second process has exited; the first process responding to the exit message starting a third process corresponding to the first blockchain service, such that the third process obtains access information through the buffer corresponding to the first port; the third process is a child process of the first process.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a blockchain service management method and a blockchain node. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and has been widely applied in numerous fields. Summary of the Invention

[0003] The purpose of this invention is to provide a blockchain service management method and a blockchain node, so as to achieve the effect of not losing access information for blockchain services.

[0004] This specification provides a blockchain service management method, executed by a blockchain node. The blockchain node runs a first process and a second process, the first process being the parent process of the second process. The second process provides a first blockchain service, the first process listens on a first port, and the second process obtains access information through a buffer corresponding to the first port. The method includes:

[0005] The first process receives an exit message indicating that the second process has exited;

[0006] In response to the exit message, the first process starts a third process corresponding to the first blockchain service, so that the third process obtains access information through the buffer; the third process is a child process of the first process.

[0007] The second aspect of this specification provides a blockchain node in which a first process and a second process are running. The first process is the parent process of the second process. The second process is used to provide a first blockchain service. The first process is used to listen to a first port. The second process is used to obtain access information through the buffer corresponding to the first port. The first process is used to receive an exit message indicating that the second process has exited.

[0008] The first process is also used to respond to the exit message by starting a third process corresponding to the first blockchain service, so that the third process obtains access information through the buffer corresponding to the first port; the third process is a child process of the first process.

[0009] Thirdly, a computer-readable storage medium is provided having a computer program or instructions stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0010] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores a computer program or instructions, and the processor, when executing the computer program or instructions, implements the method described in the first aspect.

[0011] By utilizing one or more of the methods, nodes, computing devices, and storage media mentioned above, it is possible to achieve the effect of not losing access information for blockchain services. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A blockchain architecture diagram is shown in one embodiment;

[0014] Figure 2 This is a schematic diagram of a blockchain service management method in one embodiment of this specification;

[0015] Figure 3 This is a flowchart of a blockchain service management method in one embodiment of this specification;

[0016] Figure 4 This is a schematic diagram of a blockchain node in one embodiment of this specification;

[0017] Figure 5 This is a schematic diagram of another blockchain node in one embodiment of this specification;

[0018] Figure 6 This is a schematic diagram of yet another type of blockchain node in one embodiment of this specification;

[0019] Figure 7 This is a schematic diagram of a blockchain service management method in another embodiment of this specification. Detailed Implementation

[0020] 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 some embodiments of this specification, and not all 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.

[0021] Figure 1 A blockchain architecture diagram is shown in one embodiment. Figure 1 As shown, a blockchain 100, for example, contains 6 nodes. The connections between nodes schematically represent P2P (Peer-to-Peer) connections. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain produces the same state by executing the same transactions, and each node stores the same state database. This can be understood as... Figure 1 Although the example shows a blockchain with 6 nodes, this specification's embodiments are not limited to this and may include other numbers of nodes. Specifically, the nodes in the blockchain can satisfy the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as the existence of Byzantine nodes within the blockchain, while the blockchain does not exhibit Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require a number of nodes greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0022] Because blockchain nodes typically possess multiple functions, they usually run various blockchain services to provide different functionalities, such as computation services, consensus services, caching services, pre-execution services, block management services, and network services. Existing blockchain node service configuration schemes are usually based on a single physical node and a single process. This means that multiple blockchain services run on a single physical node, and each service is typically provided through the execution of a single process on that physical node. This approach has the following problems: First, due to the limited processing power of a single physical node, it may be unable to meet the processing demands of high-throughput blockchain services. Expanding the processing power of a single physical node often involves improving its hardware resources, such as upgrading the CPU or increasing memory. However, improving the processing resources of a single physical node is not easy and often has limitations. In other words, this approach struggles to meet the demands of highly scalable and high-throughput blockchain services. Second, since each blockchain service typically relies on a single process on the physical node, if that process encounters problems, such as logical errors or exits, the corresponding blockchain service will experience service anomalies or interruptions. Third, each blockchain service process typically listens for access to its service port. While listening, it creates a buffer for that service port and retrieves access messages by reading this buffer. If the service process (i.e., the process providing the blockchain service, or the corresponding process for that blockchain service) exits unexpectedly, it loses its listening to the service port, and the corresponding buffer for that port is also lost. Therefore, subsequent access information for its service port will be lost. Even if another corresponding process for the same blockchain service is started after the first process exits, the access information during the interval between the exit of the first process and the start of the second will still be lost.

[0023] To address the aforementioned technical problems, this specification provides a blockchain service management method in its embodiments. The core idea is to set up a proxy process on the blockchain node, which serves as the parent process for all corresponding processes of blockchain services. When the corresponding process of any blockchain service exits due to a fault or unexpected event, the proxy process receives a message from the operating system indicating that the blockchain service has exited. The proxy process can then start a new process to resume providing the blockchain service. Furthermore, when any blockchain service aims to provide services externally through any network port, the proxy process listens on that network port, and the blockchain service's process obtains access information for the blockchain service from the receive buffer corresponding to that network port. Specifically, Figure 2 This is a schematic diagram of a blockchain service management method according to one embodiment of this specification. Figure 2 As shown, a proxy process is configured within this blockchain node. This proxy process is the parent process of all corresponding processes running on this blockchain node. The following explanation uses the first blockchain service on this blockchain node as an example. The first blockchain service aims to provide services to the outside world through the node's first network port. The proxy process's child process—child process 1—is used to provide the first blockchain service (i.e., the corresponding process for the first blockchain service is child process 1). Listening on the first network port is handled by the proxy process, while reading from the port's receive buffer is performed by child process 1. If child process 1 exits due to an error or malfunction, the proxy process restarts a new child process, such as child process 2, to continue providing the first blockchain service. Child process 2 still reads external access information for the first blockchain service from the first network port's receive buffer.

[0024] Furthermore, unlike existing blockchain node schemes where a blockchain node typically corresponds to a single physical node, the blockchain service management scheme in this specification's embodiments allows a blockchain node to include multiple physical nodes, each of which can run one or more blockchain services. Also, unlike existing schemes where a blockchain service typically has only one corresponding process on a single physical node, in this specification's blockchain service management scheme, a blockchain service on a blockchain node can have multiple corresponding processes across the multiple physical nodes included in the blockchain node, and can also have multiple corresponding processes on a single physical node.

[0025] The blockchain service management scheme provided by the embodiments of this specification has the following advantages: First, as mentioned above, in existing blockchain service configuration schemes, each blockchain service process typically listens for access to its service port. If a service process exits unexpectedly, it loses its listening to the service port and the corresponding buffer, resulting in the loss of access information for that service port. Even if another corresponding process is subsequently started to provide the same service, access information during the interval between the execution of the two processes will still be lost. However, the blockchain service management scheme provided by the embodiments of this specification uses a parent process—a proxy process—to listen to the service port, while the child process—the service process—reads the service port's buffer to obtain access data. Thus, when the service process itself exits, its parent process's listening to the port still exists, and the port's buffer will not be lost. Therefore, when the parent process restarts a new process to provide the same service, the new process can read the access information for the blockchain service from the buffer, and even access information during the interval between the execution of the two processes will not be lost. Secondly, in existing blockchain node solutions, a blockchain node typically corresponds to a single physical node, and each blockchain service on that node typically corresponds to a process on that physical node. Therefore, if the physical node crashes due to a fault or accident, all blockchain services on that node will cease to be available, meaning the blockchain node itself will inevitably fail. Similarly, if the process corresponding to a blockchain service on that physical node unexpectedly exits, the corresponding blockchain service will be interrupted for at least a period of time. However, in the blockchain service management solution provided in the embodiments of this specification, a blockchain node can include multiple physical nodes, and each blockchain service can have multiple corresponding processes on one or more of these physical nodes. Furthermore, if one physical node crashes, the various services of the blockchain node can still be provided by the corresponding processes on the other physical nodes included in that blockchain node, so the blockchain node will not fail. And since each blockchain service can have multiple corresponding processes on one or more physical nodes, the exit of any one of these processes will not cause the service to be interrupted. In other words, the blockchain service management solution provided in the embodiments of this specification can provide blockchain nodes and blockchain services with more stable operating conditions. Third, by providing more physical nodes for blockchain nodes and more corresponding processes on one or more physical nodes for blockchain services, it is easier to expand the service capacity of blockchain services; it is also easier to determine the number of physical nodes and service processes required based on the specific throughput requirements of blockchain nodes and their blockchain services, and to make scalable adjustments to their service capabilities.

[0026] The following section further elaborates on the detailed process of this method.

[0027] Figure 3 This is a flowchart of a blockchain service management method according to one embodiment of this specification. Figure 3 As shown, this method is executed by a blockchain node, which runs a first process and a second process. The first process is the parent process of the second process. The second process provides a first blockchain service. The first process listens on a first port, and the second process obtains access information through the buffer corresponding to the first port. The method includes steps S31-S33. These will be described in detail below. Figure 3 The steps shown.

[0028] First, in step S31, the first process receives an exit message indicating that the second process has exited.

[0029] In this step, the first process, as the proxy process described earlier, is the parent process of all corresponding processes for blockchain services (including the first blockchain service) on the blockchain node. The second process is the process used to provide the first blockchain service (that is, the corresponding process for the first blockchain service). Therefore, the first process is also the parent process of the second process.

[0030] In computer science, a parent process typically refers to a process that has created one or more child processes. A child process is a process created by another process (its parent process). Generally, a child process can inherit most of the attributes of its parent process. In different implementations, the parent process (e.g., the first process) can generate its child process (e.g., the second process) in different specific ways, and this specification does not limit this. For example, in one implementation, the parent process can make a specific system call (e.g., a fork call) to create its child process. The child process can then make another system call (e.g., an exec call) to load an application (e.g., an application providing a first blockchain service).

[0031] In this specification, "port" primarily refers to a network port in a logical sense based on network communication protocols. For example, a port in the TCP / IP protocol. Typically, different network services can use different port numbers, such as port 80 for web browsing services and port 21 for FTP services. Depending on the implementation, different blockchain services may use different ports, and this specification does not impose any restrictions on this. As mentioned earlier, the first process listens on the network port (first port) of the first blockchain service. Since the second process is a child process of the first process, it can inherit the attributes of the first process, which may include the identifier of the corresponding buffer for the first port established when the first process listens on the first port, and read the buffer through this identifier to obtain access information for the first blockchain service. According to one implementation, the identifier may, for example, be a file identifier or handle corresponding to the buffer.

[0032] When the second process exits, it can send an exit message (such as a SIGCHLD message) to its parent process (the first process). The first process can receive the exit message and thus confirm that the second process has exited.

[0033] As described above, a blockchain node may include at least one physical node. In one implementation, at least one physical node may include a first physical node, in which the first process and the second process are running. Figure 4 This is a schematic diagram of a blockchain node in one embodiment of this specification. For example... Figure 4 As shown, the blockchain node includes physical node 1, on which a proxy parent process and its various child processes for providing various blockchain services can run, including child process 1 for providing the first blockchain service.

[0034] A blockchain node may include multiple physical nodes, on which different physical nodes may run their own proxy parent processes and different processes providing the same blockchain service. Therefore, in one embodiment, at least one physical node may further include a second physical node, on which a fourth process and a fifth process run; the fourth process is the parent process of the fifth process, which is used to provide the first blockchain service. Figure 5 This is a schematic diagram of another blockchain node in one embodiment of this specification, such as... Figure 5As shown, the blockchain node includes multiple physical nodes, namely physical node 1, physical node 2, ... Each of physical node 1 and physical node 2 runs a proxy process, and each proxy process on physical node 1 and physical node 2 has a subprocess 1 and a subprocess 2, respectively. Both subprocess 1 and subprocess 2 are used to provide the first blockchain service. Depending on the implementation, proxy processes on other physical nodes besides physical node 1 and physical node 2 may also have subprocesses used to provide the first blockchain service.

[0035] Multiple processes providing the same blockchain service can also run on the same physical node. Therefore, in one implementation, a sixth process also runs on the first physical node. The sixth process is a subprocess of the first process and is used to provide the first blockchain service. Figure 6 This is a schematic diagram of yet another type of blockchain node in one embodiment of this specification. For example... Figure 6 As shown, multiple child processes can run in physical node 1, such as child process 1 and child process 2. Both child process 1 and child process 2 are used to provide the first blockchain service.

[0036] In step S33, the first process responds to the exit message and starts a third process corresponding to the first blockchain service, so that the third process obtains access information through the buffer corresponding to the first port; the third process is a child process of the first process.

[0037] In this step, after the first process receives the exit message from the second process, it starts a sub-process—the third process—to provide the first blockchain service. In one implementation, the first process can create the third process in the same way as the second process, and the third process can load the same application as the second process (the application that provides the first blockchain service).

[0038] Since the third process is also a child process of the first process, it can inherit the attributes of the first process, including the identifier of the corresponding buffer for the first port. The third process can also read the buffer using this identifier to obtain access information for the first blockchain service. Because the first port is constantly being listened to by the first process, even during the period between the exit of the second process and the start of the third process, the first process continues to listen to the first port, and the buffer corresponding to the first port created by the first process remains. Therefore, even during the interval between the exit of the second process and the start of the third process, external access information for the first blockchain service will still be stored in the buffer and will not be lost. After the third process starts, it can still read the buffer using the buffer identifier to obtain the access information for the first blockchain service during that period. During this interval, for users accessing the first blockchain service from the outside, since their access information is not lost, they may not perceive any interruption to the blockchain service, except for a slight delay in access response time.

[0039] In some application scenarios, although the service process has not exited, it may be in an abnormal state internally, such as falling into an unrecoverable logical exception, causing the service process to be unable to continue providing normal services. To address the problem of a service process existing but unable to provide normal services, in one implementation, a heartbeat mechanism can be used between the proxy process and the child process providing the service to determine whether the child process is in a normal state. When the child process is in an abnormal state, it can be terminated, and other child processes can be restarted to provide the same service. Therefore, according to one implementation, the first process can also wait to receive a first heartbeat message from a seventh process at a predetermined time. The seventh process is a child process of the first process, and the seventh process is used to provide a second blockchain service. If the first process does not receive the first heartbeat message at the predetermined time, the first process starts an eighth process to provide the second blockchain service, and the eighth process is a child process of the first process.

[0040] According to another implementation, the first heartbeat information may further include the status information of the seventh process; then, the first process may determine whether the seventh process is running normally based on the status information; if the result is not, the seventh process is terminated and the eighth process for providing the second blockchain service is started.

[0041] The heartbeat mechanism described above can also be a two-way heartbeat mechanism between the parent process and the service child process, that is, the parent process and the service child process send heartbeat information to each other. Figure 7 This is a schematic diagram of a blockchain service management method according to another embodiment of this specification. For example... Figure 7As shown, the parent process can periodically send heartbeat information to the service child process. The service child process then sends a response message (which is also a heartbeat message sent from the service child process to the parent process) to the parent process based on this heartbeat information. The parent process then determines the status of the service child process based on this response message. Therefore, according to one implementation, the first heartbeat information may include the response message from the seventh process to the second heartbeat information sent to it by the first process.

[0042] According to another embodiment, a blockchain node is also provided. The blockchain node runs a first process and a second process, the first process being the parent process of the second process. The second process provides a first blockchain service, the first process listens on a first port, the second process obtains access information through a buffer corresponding to the first port, and the first process receives an exit message indicating that the second process has exited.

[0043] The first process is also used to respond to the exit message by starting a third process corresponding to the first blockchain service, so that the third process obtains access information through the buffer corresponding to the first port; the third process is a child process of the first process.

[0044] According to one implementation, when the first process listens to the first port, it is further specifically used to obtain the identifier of the buffer corresponding to the first port; when the second process obtains access information through the buffer corresponding to the first port, it is specifically used to obtain the identifier based on inheritance from the first process, and obtain the access information through the buffer corresponding to the first port according to the identifier.

[0045] According to one implementation, the blockchain node may correspond to at least one physical node, the at least one physical node including a first physical node in which the first process and the second process are running.

[0046] According to one implementation, at least one physical node may further include a second physical node, in which a fourth process and a fifth process are running; the fourth process is the parent process of the fifth process, and the fifth process is used to provide a first blockchain service.

[0047] According to one implementation, a sixth process may also run in the first physical node. The sixth process is a subprocess of the first process and is used to provide the first blockchain service.

[0048] According to one implementation, the first process can also be used to,

[0049] Waiting to receive the first heartbeat information sent by the seventh process at a predetermined time, the seventh process being a child process of the first process, and the seventh process being used to provide the second blockchain service;

[0050] If the first heartbeat information is not received within the predetermined time, an eighth process for providing the second blockchain service is initiated, wherein the eighth process is a subprocess of the first process.

[0051] According to one implementation, the first heartbeat information may include the status information of the seventh process;

[0052] The first process can be further used for...

[0053] Based on the status information, determine whether the seventh process is running normally;

[0054] If the result is negative, terminate the seventh process and start the eighth process to provide the second blockchain service.

[0055] According to one implementation, the first heartbeat information may include response information from the seventh process to the second heartbeat information sent to it by the first process.

[0056] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any of the methods described above.

[0057] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements any of the methods described above.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

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

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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 blockchain service management method, executed by a blockchain node, wherein the blockchain node runs a first process and a second process, the first process being the parent process of the second process, the second process providing a first blockchain service, the first process listening on a first port, the attributes of the first process including an identifier of a buffer corresponding to the first port, and the second process obtaining access information for the first blockchain service through the buffer; the method includes: The first process receives an exit message indicating that the second process has exited; In response to the exit message, the first process starts a third process corresponding to the first blockchain service, so that the third process accesses the buffer through the identifier of the buffer and obtains the access information; the third process is a child process of the first process, and the third process obtains the identifier based on inheritance from the first process.

2. The method according to claim 1, wherein, The first process is used to listen on the first port; the second process is used to obtain access information for the first blockchain service through the buffer corresponding to the first port, including: The first process listens to the first port and obtains the identifier of the buffer corresponding to the first port; the second process obtains the identifier based on its inheritance from the first process, finds the buffer according to the identifier, and obtains access information from the buffer.

3. The method according to claim 1, wherein, The blockchain node corresponds to at least one physical node, and the at least one physical node includes a first physical node, in which the first process and the second process are running.

4. The method according to claim 3, wherein, The at least one physical node further includes a second physical node, in which a fourth process and a fifth process are running; The fourth process is the parent process of the fifth process, which is used to provide the first blockchain service.

5. The method according to claim 3, wherein, The first physical node also runs a sixth process, which is a subprocess of the first process, and the sixth process is used to provide the first blockchain service.

6. The method according to claim 1, further comprising: The first process waits to receive the first heartbeat information sent by the seventh process at a predetermined time. The seventh process is a child process of the first process, and the seventh process is used to provide the second blockchain service. If the first process does not receive the first heartbeat information within the predetermined time, The first process initiates an eighth process to provide a second blockchain service, the eighth process being a child process of the first process.

7. The method according to claim 6, wherein, The first heartbeat information includes the status information of the seventh process; The method further includes: The first process determines whether the seventh process is running normally based on the status information; If the result is negative, terminate the seventh process and start the eighth process to provide the second blockchain service.

8. The method according to claim 6, wherein, The first heartbeat information includes the response information of the seventh process to the second heartbeat information sent to it by the first process.

9. A blockchain node, wherein a first process and a second process are running in the blockchain node, the first process is the parent process of the second process, the second process is used to provide a first blockchain service, the first process is used to listen to a first port, the attributes of the first process include an identifier of a buffer corresponding to the first port, the second process is used to obtain access information for the first blockchain service through the buffer, and the first process is used to receive an exit message indicating that the second process has exited. The first process is also configured to respond to the exit message by starting a third process corresponding to the first blockchain service, such that the third process accesses the buffer through the identifier of the buffer and obtains access information; the third process is a child process of the first process, and the third process obtains the identifier based on inheritance from the first process.

10. The blockchain node according to claim 9, wherein, When the first process listens to the first port, it is specifically used to obtain the identifier of the buffer corresponding to the first port; when the second process obtains access information through the buffer corresponding to the first port, it is specifically used to obtain the identifier based on the inheritance of the first process, and obtain the access information through the buffer corresponding to the first port according to the identifier.

11. The blockchain node according to claim 9, wherein, The blockchain node corresponds to at least one physical node, and the at least one physical node includes a first physical node, in which the first process and the second process are running.

12. The blockchain node according to claim 11, wherein, The at least one physical node further includes a second physical node, in which a fourth process and a fifth process are running; The fourth process is the parent process of the fifth process, which is used to provide the first blockchain service.

13. The blockchain node according to claim 11, wherein, The first physical node also runs a sixth process, which is a subprocess of the first process, and the sixth process is used to provide the first blockchain service.

14. The blockchain node according to claim 9, wherein, The first process is also used for, Waiting to receive the first heartbeat information sent by the seventh process at a predetermined time, the seventh process being a child process of the first process, and the seventh process being used to provide the second blockchain service; If the first heartbeat information is not received within the predetermined time, an eighth process for providing the second blockchain service is initiated, wherein the eighth process is a subprocess of the first process.

15. The blockchain node according to claim 14, wherein, The first heartbeat information includes the status information of the seventh process; The first process is further used for, Based on the status information, determine whether the seventh process is running normally; If the result is negative, terminate the seventh process and start the eighth process to provide the second blockchain service.

16. The blockchain node according to claim 14, wherein, The first heartbeat information includes the response information of the seventh process to the second heartbeat information sent to it by the first process.

17. A computer-readable storage medium having a computer program or instructions stored thereon, which, when executed in a computer, cause the computer to perform the method of any one of claims 1-8.

18. A computing device comprising a memory and a processor, the memory storing a computer program or instructions, the processor executing the computer program or instructions to implement the method of any one of claims 1-8.

Citation Information

Patent Citations

  • System and method for implementing native contract on blockchain

    CN110249307A

  • Business data processing method, device and equipment and storage medium

    CN111352803A