CN116450133A - Node updating method, device, equipment and storage medium of block chain system - Google Patents

Node updating method, device, equipment and storage medium of block chain system Download PDF

Info

Publication number
CN116450133A
CN116450133A CN202210015869.8A CN202210015869A CN116450133A CN 116450133 A CN116450133 A CN 116450133A CN 202210015869 A CN202210015869 A CN 202210015869A CN 116450133 A CN116450133 A CN 116450133A
Authority
CN
China
Prior art keywords
node
code
update
blockchain system
updating
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210015869.8A
Other languages
Chinese (zh)
Inventor
申清瑞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202210015869.8A priority Critical patent/CN116450133A/en
Publication of CN116450133A publication Critical patent/CN116450133A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The embodiment of the application discloses a node updating method, device and equipment of a block chain system and a storage medium, which can be applied to the fields of block chain technology, computer technology and the like. The method comprises the following steps: determining an update source code, compiling the update source code to obtain an executable code corresponding to the update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in the blockchain system to directly run; transmitting the executable codes to each node in the block chain system, so that each node performs node updating and synchronizes updating states in the node operation process based on the executable codes; and determining an updating state synchronization result of each node, and determining that each node synchronously updates the updating source code based on the updating state synchronization result. By adopting the embodiment of the application, the version difference among all nodes in the block chain system can be reduced, the node updating efficiency is improved, and the applicability is high.

Description

Node updating method, device, equipment and storage medium of block chain system
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a method, an apparatus, a device, and a storage medium for updating a node of a blockchain system.
Background
With the continuous development of the blockchain technology, the update scheme of the existing blockchain system mainly comprises the steps that each node in the blockchain system regularly retrieves and downloads the latest update source code, and then the corresponding function or service is updated based on the update source code.
However, under the existing update mechanism, due to reasons such as network delay and inconsistent time for each node to acquire the update source code, part of nodes in the blockchain system cannot be updated in time, so that update version differences exist among the nodes in the blockchain system. And after each node in the blockchain system is updated, the updated service or function is often required to be operated by restarting the node, so that the updating efficiency of the node is affected.
Disclosure of Invention
The embodiment of the application provides a node updating method, device and equipment of a block chain system and a storage medium, which can reduce version differences among nodes in the block chain system, improve node updating efficiency and have high applicability.
In one aspect, an embodiment of the present application provides a method for updating a node of a blockchain system, the method including:
determining an update source code, and compiling the update source code to obtain an executable code corresponding to the update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in a blockchain system to directly run;
transmitting the executable codes to each node in the block chain system, so that each node updates the nodes and synchronizes the update state in the node operation process based on the executable codes;
and determining an update state synchronization result of each node, and determining that each node synchronously updates the update source code based on the update state synchronization result.
In another aspect, an embodiment of the present application provides a method for updating a node of a blockchain system, including:
acquiring an executable code corresponding to an update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in a blockchain system to directly run;
Updating nodes in the node operation process based on the executable codes, and updating states synchronously with other nodes in the block chain system;
and determining a first execution result aiming at the executable code, and if the first execution result is consistent with a second execution result aiming at the executable code by other nodes in the blockchain system, determining that node updating aiming at the updating source code is completed.
In another aspect, an embodiment of the present application provides a node update apparatus of a blockchain system, including:
the code determining module is used for determining an update source code, compiling the update source code to obtain an executable code corresponding to the update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in the blockchain system to directly run;
the code sending module is used for sending the executable codes to all nodes in the block chain system so that all the nodes update the nodes and synchronize update states in the node operation process based on the executable codes;
and the result determining module is used for determining an update state synchronization result of each node and determining that each node synchronously updates the update source code based on the update state synchronization result.
In another aspect, an embodiment of the present application provides a node update apparatus of a blockchain system, including:
the code acquisition module is used for acquiring executable codes corresponding to the update source codes, wherein the update source codes correspond to any programming language, and the executable codes are byte codes in a preset format for supporting each node in the blockchain system to directly run;
the node updating module is used for updating the nodes in the node operation process based on the executable codes and synchronously updating states with other nodes in the block chain system;
and the information processing module is used for determining a first execution result aiming at the executable code, and determining that node updating aiming at the updating source code is completed if the first execution result is consistent with a second execution result aiming at the executable code by other nodes in the blockchain system.
In another aspect, an embodiment of the present application provides an electronic device, including a processor and a memory, where the processor and the memory are connected to each other;
the memory is used for storing a computer program;
the processor is configured to execute the node update method of any of the blockchain systems provided in the embodiments of the present application when the computer program is invoked.
In another aspect, embodiments of the present application provide a computer readable storage medium storing a computer program for execution by a processor to implement a node update method of any one of the blockchain systems provided by embodiments of the present application.
In another aspect, embodiments of the present application provide a computer program product comprising a computer program or computer instructions that, when executed by a processor, implement a node update method for any of the blockchain systems provided by the embodiments of the present application.
In the embodiment of the application, the update source code is compiled into the byte code (executable code) in the preset format supporting the direct operation of each node in the blockchain system, so that the node in the blockchain system can update the node directly based on the executable code, and the node update efficiency is improved. Further, the nodes in the block chain system can participate in node updating through synchronous updating of the states, so that version uniformity of each node in the block chain system is ensured, and applicability is high.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a node update method of a blockchain system provided by embodiments of the present application;
FIG. 2 is a flow chart of a node update method of a blockchain system according to an embodiment of the present disclosure;
FIG. 3 is a schematic view of a source code compiling and applying scenario provided in an embodiment of the present application;
FIG. 4 is another flow chart of a node update method of a blockchain system provided in the embodiments of the present application;
fig. 5 is a schematic view of a scenario of a synchronous update state provided in an embodiment of the present application;
FIG. 6 is a schematic diagram of a node in a blockchain system provided in an embodiment of the present application;
fig. 7 is a schematic view of a scenario of node update based on a wasm file according to an embodiment of the present application;
FIG. 8 is a schematic diagram of a node update apparatus of a blockchain system according to an embodiment of the present disclosure;
FIG. 9 is another schematic diagram of a node update apparatus of a blockchain system according to an embodiment of the present disclosure;
fig. 10 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
Referring to fig. 1, fig. 1 is a schematic diagram of a node updating method of a blockchain system provided in an embodiment of the present application. As shown in FIG. 1, before upgrading each node of the blockchain system, the update source code may be determined and compiled into executable code, i.e., bytecode in a pre-set format that supports direct operation of each node in the blockchain system.
Further, the executable code corresponding to the update source code is sent to each node in the blockchain system, so that each node performs node update in the node operation process based on the received executable code. Such as sending executable code to the blockchain system 10 such that nodes 101, 102, 103, and 104 in the blockchain system 10 perform node updates during node execution based on the executable code. Meanwhile, each node in the blockchain system can synchronize update states with each other at the time of node update, for example, the nodes 101, 102, 103 and 104 can synchronize update states in the update process, so as to achieve the aim of synchronously updating each node as much as possible. Based on the above, the update status synchronization result of each node can be obtained, and based on the update status synchronization result, each node can be determined to perform synchronization update for the update source code.
The blockchain system 101 in the embodiments of the present application may also be referred to as a data sharing system, i.e., a system for sharing data from node to node. For example, the data sharing system may include a plurality of nodes, such as node 101, node 102, node 103, and node 104, where each node may be a computing device accessing the blockchain system, such as a server, a user terminal, etc., where a Peer-To-Peer (P2P) network is formed between the nodes, and the P2P protocol is an application layer protocol running on top of a transmission control protocol (Transmission Control Protocol, TCP) protocol. In the data sharing system, any machine such as a server and a terminal can be added to become a node, the node comprises a hardware layer, a middle layer, an operating system layer and an application layer, and each node can receive relevant information when working normally and maintain shared data in the data sharing system based on the received relevant information.
The servers in the blockchain system (data sharing system) in the embodiment of the present application may be independent physical servers, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be cloud servers that provide cloud computing services. The terminal may be, but is not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, a smart television, etc.
Referring to fig. 2, fig. 2 is a flow chart illustrating a node updating method of a blockchain system according to an embodiment of the present application. As shown in fig. 2, the node updating method of the blockchain system provided in the embodiment of the present application may be applicable to related devices, servers, etc. having communication connection with the blockchain system, and may also be applicable to related nodes in the blockchain system, and specifically includes the following steps:
and S21, determining an update source code, and compiling the update source code to obtain an executable code corresponding to the update source code.
In some possible implementations, the update source code is initial code for updating each node in the blockchain system, i.e., initial code for updating traffic or functionality of each node in the blockchain system, or initial code for updating the system of each node in the blockchain system.
For example, the update source code may be a source code corresponding to a new function developed for each node in the blockchain system, or may be a source code for repairing a defect (bug) related to a service function of each node in the blockchain system, which may be specifically determined based on an actual application scenario requirement, and is not limited herein.
The update source code may correspond to any programming language, that is, the update source code may be a code written in any programming language, specifically may be determined based on the actual application scenario requirement, and is not limited herein.
In some possible implementations, the update source code may be pre-written initial code for updating nodes in the blockchain system, such as online code or upgrade code for some new function that may be written for a developer. Upon determining to update the source code, initial code written by a developer for node updating of each node in the blockchain system may be obtained.
Alternatively, the update source code may be library file code of the target application. The target application program can be any application program operated by each node in the blockchain system. For a target application program, each program function of the target application program can be divided into a plurality of relatively independent library file codes, and when executing a certain program function, the corresponding library file code needs to be called.
Therefore, the update source code may be any library file code of the target application program, and the program function corresponding to the library file code is the newly online program function. Alternatively, the update source code may be initial code developed by a software open toolkit (Software Development Kit, SDK), specifically may be determined based on actual application scenario requirements, and is not limited herein.
When the update source code is determined, a target program function in the target application program can be determined, wherein the target program function is a function that each node in the blockchain system is not on line. And further calling the library file code corresponding to the target program function to obtain the updated source code.
Alternatively, the update source code may be initial code compiled for any node in the blockchain system for updating the nodes in the blockchain system. That is, any node in the blockchain system may issue an update source code, and cause each node in the blockchain system to update a node based on an executable code corresponding to the update source code sent by the node.
In some possible embodiments, after determining the update source code, the update source code may be compiled to obtain executable code corresponding to the update source code.
The executable code corresponding to the update source code is a byte code with a preset format supporting the direct operation of each node in the blockchain system. For updated source code corresponding to any programming language, the updated source code can be compiled into byte codes in a preset format through a compiler, so that each node in the blockchain system can directly run the byte codes.
That is, for update source code corresponding to any programming language, the update source code may be translated into executable code comprising a plurality of instructions in a similar assembly language.
The preset format may be WebAssembly format, or may be other formats, and may specifically be determined based on the actual application scene requirement, which is not limited herein. In the case that the preset format is WebAssembly format, the update source code may be compiled based on a corresponding compiler to obtain a wasm file, where the wasm file is essentially a string of binary bytecodes.
The executable code in the preset format obtained by compiling the update source code may also be referred to as a runtime library file or runtime library code, and the like, which is not limited herein.
Referring to fig. 3, fig. 3 is a schematic view of a source code compiling and applying scenario provided in an embodiment of the present application. As shown in fig. 3, for a source code corresponding to a certain function or service, the source code can be compiled by a WebAssembly compiler to obtain a wasm file composed of binary byte codes. Further, for different users, the user can directly run the wasm file based on the corresponding runtime of the wasm file (the environment in which the wasm file is run), without recompilation of the source code or wasm.
And step S22, the executable codes are sent to all nodes in the block chain system, so that all the nodes update the nodes and synchronize update states in the node operation process based on the executable codes.
In some possible implementations, when the executable code is sent to a node in the blockchain system, the executable code may be sent to a target node in the blockchain system to cause the target node to broadcast the executable code to other nodes in the blockchain system, such that each node in the blockchain system may perform node updates during node operation and synchronize update states to synchronize the node updates.
The target node may be any node in the blockchain system, or may be a central node or a routing node in the blockchain system, or may be specifically determined based on an actual application scenario requirement, which is not limited herein.
For each node in the blockchain system, there is a node identification corresponding thereto, and each node in the blockchain system may store the node identifications of other nodes in the blockchain system for subsequent broadcasting of the generated blocks or other information to other nodes in the blockchain system, such as broadcasting of executable code to other nodes in the blockchain system by a target node in the blockchain, based on the node identifications of the other nodes. Each node can maintain a node identification list shown in the following table, and the node names and the node identifications are correspondingly stored in the node identification list. The node identifier may be an IP (Internet Protocol, protocol of interconnection between networks) address, and any other information that can be used to identify the node, which is only illustrated in the following table by way of example.
Node name Node identification
Node 1 117.114.151.174
Node 2 117.116.189.145
… …
Node N xx.xx.xx.xx
Optionally, in order to ensure information intercommunication in the blockchain system, information connection may exist between each node in the blockchain system, and information transmission may be performed between the nodes through the information connection. Therefore, after the executable code corresponding to the update source code is sent to any node in the blockchain system, other nodes in the blockchain system can acquire the executable code through a consensus mechanism (a consensus algorithm), and the executable code is stored as data in shared data, so that all nodes in the blockchain system acquire the executable code corresponding to the update source code.
In some possible embodiments, when the executable code corresponding to the update source code is sent to each node in the blockchain system, hash calculation may be performed on the executable code to obtain a first digest of the executable code, and the first digest is further encrypted based on a private key of a code issuer of the update source code to obtain a digital signature of the executable code, so as to obtain the digital signature of the executable code corresponding to the update source code.
Further, when the executable code corresponding to the update source code is sent to each node in the blockchain system, the digital signature of the executable code can be sent together, so that each node in the blockchain system can determine whether the executable code is tampered in the transmission process or not based on the digital signature after receiving the executable code and the digital signature thereof, and if the executable code is determined not to be tampered, the node update can be performed based on the executable code.
The code issuing party of the update source code is a source party of the update source code, for example, in the case that the update source code is a pre-written initial code used for updating each node in the blockchain system, the code issuing party of the update source code is a corresponding developer, in the case that the update source code is a library file code of a target application program, the code issuing party of the update source code can be a corresponding target application program, and in the case that the update source code is an initial code compiled by any node in the blockchain system and used for updating each node in the blockchain system, the code issuing party of the update source code can be the node.
It should be noted that the above description of the code issuer of the update source code is merely an example, and may be specifically determined based on the actual application scenario requirement, for example, the code issuer of the update source code may also be a preset administrator, etc., which is not limited herein.
Step S23, determining an update state synchronization result of each node, and determining that each node performs synchronous update for the update source code based on the update state synchronization result.
In some possible implementations, after the update source code is sent to each node in the blockchain system, an update status synchronization result for each node may be determined to further confirm that each node is synchronously updated for the update source code based on the update status synchronization result for each node.
When the update state synchronization result of each node is determined, the update state of each node can be obtained from any node in the blockchain system, that is, the node can obtain the update states of other nodes, and the update state synchronization result is generated and sent based on the update states of each node. Alternatively, the update status of each node in the blockchain system may be directly obtained, and the update status synchronization result of each node may be determined based on the update status of each node in the blockchain system.
For example, when the executable code is sent to a node in the blockchain system, the executable code is sent to a target node in the blockchain system such that the target node broadcasts the executable code to other nodes in the blockchain system. Meanwhile, the target node can acquire the update state of each node and generate an update state synchronization result, so that the update state synchronization result of each node in the blockchain system can be acquired from the target node.
In some possible embodiments, after confirming that each node performs synchronous update for the update source code, an execution result of each node in the blockchain system for the executable code may be further obtained to determine that each node in the blockchain system completes node update based on the execution result corresponding to each node in the blockchain system.
Similarly, when the execution result of each node for the executable code is obtained, the execution result of each node for the executable code may be obtained from any node in the blockchain system, that is, the node may obtain the execution results of other nodes for the executable code, and send the execution results of each node for the executable code. Alternatively, the corresponding execution results may be obtained directly from each node in the blockchain system, without limitation.
For example, when the executable code is sent to a node in the blockchain system, the executable code is sent to a target node in the blockchain system such that the target node broadcasts the executable code to other nodes in the blockchain system. Meanwhile, the target node can acquire the execution result of each node for the executable code, so that the execution result of each node for the executable code in the blockchain system can be acquired from the target node.
Referring to fig. 4, fig. 4 is another flow chart of a node updating method of a blockchain system according to an embodiment of the present application. As shown in fig. 4, the method for updating a node of a blockchain system provided in the embodiment of the present application may be applicable to any node in the blockchain system, and specifically may include the following steps:
Step S41, executable codes corresponding to the update source codes are obtained.
The update source code is an initial code for updating each node in the blockchain system, namely an initial code for updating the service or the function of each node in the blockchain system, or an initial code for updating the system of each node in the blockchain system.
The update source code may correspond to any programming language, that is, the update source code may be a code written in any programming language, specifically may be determined based on the actual application scenario requirement, and is not limited herein.
The update source code may be a pre-written initial code for updating each node in the blockchain system, a library file code of the target application program, or an initial code compiled by any node in the blockchain system for updating each node in the blockchain system, which is not limited herein.
The preset format may be WebAssembly format, or may be other formats, which are not limited herein. In the case that the preset format is WebAssembly format, the update source code may be compiled based on a corresponding compiler to obtain a wasm file, where the wasm file is essentially a string of binary bytecodes. I.e. the executable code corresponding to the update source code may be a wasm file.
In some possible implementations, a target node in the blockchain system may obtain executable code corresponding to the update source code and broadcast the executable code corresponding to the update source code to other nodes. I.e., other nodes in the blockchain than the target node may directly receive the executable code broadcast by the target node.
Optionally, if any node in the blockchain system receives the executable code corresponding to the update source code, other nodes in the blockchain system except the node can acquire the executable code corresponding to the update source code from the node through a consensus mechanism based on the signal connection between the nodes.
In some possible embodiments, when the executable code corresponding to the update source code is acquired, a digital signature corresponding to the executable code may be acquired at the same time, so as to determine whether the executable code is tampered with in the transmission process based on the digital signature of the executable code.
Specifically, after receiving the executable code and the digital signature thereof, a hash calculation may be performed on the executable code, resulting in a second digest of the executable code. And meanwhile, decrypting the digital signature of the executable code based on the public key of the code issuer to obtain a second digest of the executable code.
Further, the first digest and the second digest of the executable code are compared, and if the first digest and the second digest are consistent, it is determined that the executable code is not tampered in the transmission process, and then node updating is performed based on the executable code. If the first abstract and the second abstract are inconsistent, the executable code is determined to be tampered in the transmission process, and the executable code can be discarded and prompt information is sent to reacquire the executable code.
For example, assume that the digital signature of the executable code corresponding to the update source code is "0010101", at which time the digital signature "0010101" can be decrypted based on the public key of the code issuer, resulting in a first digest of the executable code (assumed to be "1000100"). At the same time, hash computation can be performed on the received executable code to obtain a second digest of the executable code. If the second digest of the executable code is "1000100," it may be determined that the executable code was not tampered with during transmission, otherwise it may be determined that the executable code was tampered with during transmission.
And step S42, updating the nodes in the running process of the nodes based on the executable codes, and synchronously updating states with other nodes in the blockchain system.
In some possible embodiments, when updating is performed based on the executable code, since the executable code corresponding to the update source code is a byte code in a preset format, such as a binary byte code, any node in the blockchain system can directly run the executable code to perform node updating in the node running process, so that operations such as compiling the executable code again and restarting the node can be avoided, and the node updating efficiency is improved.
In the node updating process, the state can be updated synchronously with other nodes in the blockchain system, so that all nodes in the blockchain nodes can be ensured to update the nodes based on executable codes.
Specifically, the update status may be executable code corresponding to the update source code received by the node. After receiving the update source code, the update state may be synchronized with each node in the blockchain system to determine that each node in the blockchain system has received executable code. Thus, after each node in the blockchain system is determined to receive the executable code, the node update is performed in the node running process based on the executable code.
Alternatively, the update status may be based on executable code to complete node updates. Based on this, after completing the node update based on the executable code, the update state may be synchronized with other nodes in the blockchain system to determine that each node in the blockchain system completes the node update.
In the process of synchronously updating the states, nodes which are not updated on the basis of the executable codes in time in the blockchain system can be enabled to be updated on the basis of the executable codes in time in the node operation process, so that each node in the blockchain system can be further ensured to be updated on the basis of the received executable codes.
Referring to fig. 5, fig. 5 is a schematic view of a scenario of a synchronous update state provided in an embodiment of the present application. Suppose a blockchain system includes node a, node B, node C, node D, and node E. And the node A receives the executable code corresponding to the update source code and sends the executable code to other nodes in the blockchain system. And, node a performs node update during node operation based on the executable code and updates the state in synchronization with node B, node C, node D, and node E. Node B, node C, node D, and node E may likewise perform node updates based on executable code during synchronization with node B, node C, node D, and node E updating states.
The updating of the state with other nodes in the blockchain system may be performed based on a Raft algorithm, an impact fault tolerance (Power Fault Tolerance, PFT) algorithm, and other consensus algorithms, and may specifically be determined based on actual application scenario requirements, which is not limited herein.
The updating of the node based on the executable code may be to add a new function to the node, or repair a related defect of a certain service function, or the like, specifically may be determined based on the actual application scenario requirement, which is not limited herein.
In some possible embodiments, before the node update is performed in the node running process based on the executable code, the update source code may be acquired, the trust verification is performed based on the update source code and the executable code, and if the executable code passes the verification, the node update is further performed based on the executable code.
Specifically, the update source code may be compiled in the same compiling manner, the compiling result is matched with the executable code, and if the corresponding instructions are the same, it is determined that the executable code passes the verification. It should be noted that, since the node update is performed based on the compiling result of the update source code, the node is required to be restarted to complete the update, and therefore, after it is determined that the executable code passes the verification, the node update is required based on the executable code.
Alternatively, the update source code may be sent to the smart contract, compiled by the smart contract in any compiling manner, and the execution result of the compiling result is determined. And executing the executable codes in advance through the intelligent contract, comparing the executable results corresponding to the executable codes, and determining that the executable codes pass the verification if the executable results are consistent with the executable results.
Step S43, determining a first execution result aiming at the executable code, and if the first execution result is consistent with a second execution result aiming at the executable code by other nodes in the blockchain system, determining that node updating aiming at the updating source code is completed.
In some possible embodiments, after the node update is performed during the node running based on the executable code, an execution result (hereinafter referred to as a first execution result for convenience of description) for the executable code may be determined. The first execution result may be an update result of performing node update based on the executable code, or may be an execution result of executing the executable code again after completing node update.
Further, the first execution result may be compared with execution results (hereinafter referred to as second execution results for convenience of description) of other nodes in the blockchain system for the executable code, and if the first execution result is consistent with the second execution result corresponding to the other nodes, it is determined that the node update is successfully performed based on the executable code, that is, it is determined that the node update for the update source code is completed.
Optionally, a second execution result of the executable result for other nodes in the blockchain system may be obtained, and a target execution result may be determined therefrom. The target execution result is a plurality of execution results in each execution result, the first execution result is matched with the target execution result, if the first execution result is consistent with the target execution result, the successful node update based on the executable code is determined, and the node update aiming at the update source code is determined to be completed.
Alternatively, the first execution result for the executable code may be sent to the smart contract to determine whether the first execution result is erroneous by the smart contract. If the first execution result is accurate, the node update based on the executable code is determined to be successful, namely the node update aiming at the update source code is determined to be completed.
In some possible embodiments, after the other nodes in each blockchain system have different update states, the update state synchronization result of each node may be determined, and the update state synchronization result may be sent to the code publisher (e.g., a related device, a server, etc. having a communication connection with the blockchain system), so that the code publisher further confirms that each node performs synchronous update for the update source code according to the update state synchronization result of each node.
The method comprises the steps that the updating states of all nodes can be obtained from other nodes in the blockchain system, updating state synchronization results are generated based on the updating states of other nodes and the updating states of the nodes, and the updating state synchronization results are sent to a code issuing side, so that the code issuing side further confirms that all nodes synchronously update the updating source codes according to the updating state synchronization results of all the nodes.
In some possible embodiments, after determining that the node update for the update source code is completed, a first execution result may be sent to the code issuer to cause the code issuer to determine that each node in the blockchain system completes the node update based on the execution result corresponding to each node in the blockchain system.
Optionally, a second execution result of other nodes in the blockchain system for the executable code can be obtained first, and then the first execution result and the second execution result are sent to the code issuing party together, so that the code issuing party determines that each node in the blockchain system completes node updating based on the execution result corresponding to each node in the blockchain system.
In some possible implementations, after the node update for the update source code is completed, a first identification of the update source code may be determined and the executable code stored as historical executable code based on the first identification.
The first identifier includes a service identifier of a service corresponding to the update source code or a function identifier of a corresponding function, or may be a program identifier of a certain application program, or the like, which may be specifically determined based on an actual application scenario requirement, and is not limited herein.
That is, for any node in the blockchain system, after the node is updated based on the executable code, the node can store the executable code correspondingly, for example, store the executable code corresponding to the same function or the same service according to the update sequence, thereby realizing recording of the update process corresponding to any function or any service.
Any node in the blockchain system may store the historical executable code in a database or cloud storage space corresponding to the node, without limitation. And when the historical executable code is used, the corresponding update source code identification can be stored together as the identification of the corresponding service or function.
Based on this, since each node in the blockchain system stores the corresponding historical executable code after completing any node update. Therefore, when the node is updated based on the executable code corresponding to the update source code, the executable code corresponding to the update source code can be matched with each history executable code, and if each history executable code includes the executable code corresponding to the update source code, the update of the update source code (if the function corresponding to the update source code is provided), the node is not updated based on the executable code corresponding to the update source code any more. If the executable code corresponding to the update source code is not included in each history executable code, the update of the update source code is not performed, and at this time, the node update can be performed based on the executable code corresponding to the update source code.
Meanwhile, the target identifier corresponding to the first service or the first function may be determined in response to a version query request for any service (hereinafter referred to as a first service for convenience of description) or any function (hereinafter referred to as a first function for convenience of description), and at least one history executable code corresponding to the target identifier may be determined from the history executable codes. And further, based on the determined at least one historical executable code, determining the first function or version update record corresponding to the first service, and realizing effective inquiry of the update record of the specific service or the characteristic function.
Referring to fig. 6, fig. 6 is a schematic structural diagram of a node in a blockchain system provided in an embodiment of the present application. As shown in fig. 6, for any node in the blockchain system, the node includes a network interface module for implementing interaction and communication functions such as data reading and writing, inquiry and data synchronization. If version update excitation of corresponding service or function is returned through the query interface, executable codes corresponding to the update source codes are received through the update interface, and related data are sent to other nodes through the uploading interface.
Wherein the code submitter may send executable code to nodes in the blockchain system through the network interface module by way of remote procedure call (Remote Procedure Call, RPC).
The node also comprises a consensus module, and the steps of synchronizing with the updating states of other nodes in the block chain system, and consensus with a new block in the process of generating the block can be completed based on the consensus module.
The node also comprises a service and function module, and corresponding service logic or functions can be realized based on the service and function module to process corresponding service data or function data.
The node may further include a code management module, configured to store the history executable codes corresponding to each service and function, for example, sort the history executable codes V1, V2, V3, etc. corresponding to the service a according to an update order, so as to query the version update record of the service a.
The node further comprises a database, and data storage such as storage of historical executable codes and the like can be realized through the database.
The data matching, information query and other processes involved in the embodiments of the present application may be implemented through cloud computing technologies. Cloud computing is a computing model that distributes computing tasks over a large number of computer-made resource pools, enabling various application systems to acquire computing power, storage space, and information services as needed. Cloud Computing is a product of fusion of traditional computer and network technology developments such as Grid Computing (Grid Computing), distributed Computing (distributed Computing), parallel Computing (Parallel Computing), utility Computing (Utility Computing), network storage (Network Storage Technologies), virtualization (Virtualization), load balancing (Load balancing), and the like.
The node updating method of the blockchain system provided in the embodiment of the present application is further described below with reference to fig. 7. Fig. 7 is a schematic view of a scenario of node update based on a wasm file according to an embodiment of the present application. As shown in fig. 7, the code publisher provides the update source code for service a, and compiles the update source code into a wasm file of binary bytecode (i.e., executable code) by a WebAssembly compiler and sends it to each node in the blockchain system.
Each node in the blockchain system only stores executable codes V1 and V2 corresponding to the service A in a code management module corresponding to any node between receiving the wasm file, namely, each node is updated for the service A only twice.
Further, for nodes in the blockchain system, each node can update the nodes in the running process of the nodes based on the wasm file, and update states synchronously. For any node, the node may match the execution result of the wasm file with the execution results of the other nodes corresponding to the wasm file, so as to complete the result verification, thereby determining that the update of the service a is successfully completed.
At this time, the code management module corresponding to each node in the blockchain system newly stores the service code V3 corresponding to the service a, that is, the node updates the corresponding wasm file, so as to store the update record for the service a.
In the embodiment of the application, the update source code is compiled into the byte code (executable code) in the preset format supporting the direct operation of each node in the blockchain system, so that the node in the blockchain system can directly operate the executable code to update the node without performing operations such as file replacement, thereby avoiding complex update steps such as restarting the node and improving the node update efficiency. Further, nodes in the block chain system can participate in node updating through synchronous updating of the states, so that version uniformity of each node in the block chain system is ensured, and the phenomena of poor compatibility, even abnormal service or downtime and the like caused by version lag are avoided, and the applicability is high.
Referring to fig. 8, fig. 8 is a schematic structural diagram of a node updating device of a blockchain system according to an embodiment of the present application. The device provided by the embodiment of the application comprises:
the code determining module 81 is configured to determine an update source code, compile the update source code to obtain an executable code corresponding to the update source code, where the update source code corresponds to any programming language, and the executable code is a byte code in a preset format that supports direct operation of each node in the blockchain system;
A code sending module 82, configured to send the executable code to each node in the blockchain system, so that each node updates the node and synchronizes the update status during the node operation based on the executable code;
the result determining module 83 is configured to determine an update status synchronization result of each of the nodes, and determine that each of the nodes performs a synchronization update with respect to the update source code based on the update status synchronization result.
In some possible embodiments, the updating the source code includes at least one of:
pre-written initial code for updating each node in the blockchain system;
library file code of the target application;
and the initial code compiled by any node in the block chain system is used for updating each node in the block chain system.
In some possible embodiments, the code sending module 82 is configured to:
transmitting the executable code to a target node in a blockchain system, so that the target node broadcasts the executable code to other nodes in the blockchain system;
and sending the executable code to any node in the blockchain system so that other nodes in the blockchain system acquire the executable code from the node through a consensus mechanism.
In a specific implementation, the device may execute an implementation manner provided by each step in fig. 2 through each built-in functional module, and specifically may refer to an implementation manner provided by each step, which is not described herein.
Referring to fig. 9, fig. 9 is another schematic structural diagram of a node updating device of a blockchain system according to an embodiment of the present application. The device provided by the embodiment of the application comprises:
a code obtaining module 91, configured to obtain an executable code corresponding to an update source code, where the update source code corresponds to any programming language, and the executable code is a byte code in a preset format that supports direct operation of each node in the blockchain system;
a node update module 92, configured to update a node in a node running process based on the executable code, and synchronize an update state with other nodes in the blockchain system;
the information processing module 93 is configured to determine a first execution result for the executable code, and determine that node update for the update source code is completed if the first execution result is identical to a second execution result for the executable code for other nodes in the blockchain system.
In some possible embodiments, the information processing module 93 is configured to:
determining a first identifier of the update source code, wherein the first identifier comprises at least one of a service identifier of a service corresponding to the update source code or a function identifier of a corresponding function;
the executable code is stored as historical executable code based on the first identification.
In some possible embodiments, the above information processing module 93 is further configured to:
determining a target identifier corresponding to the first service or the first function in response to a version query request for the first service or the first function, and determining a version update record of the first service or the first function based on at least one history executable code corresponding to the target identifier;
and matching the executable codes with each history executable code, and allowing node updating based on the executable codes if each history executable code does not comprise the executable codes.
In some possible embodiments, the node update module 92 is further configured to:
acquiring the update source code, and performing trusted verification on the executable code based on the update source code;
And if the executable code passes the verification, updating the node in the running process of the node based on the executable code.
In a specific implementation, the device may execute an implementation manner provided by each step in fig. 4 through each built-in functional module, and specifically may refer to an implementation manner provided by each step, which is not described herein.
Referring to fig. 10, fig. 10 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 10, the electronic device 1000 in the present embodiment may include: processor 1001, network interface 1004, and memory 1005, and in addition, the electronic device 1000 may further include: a user interface 1003, and at least one communication bus 1002. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display (Display), a Keyboard (Keyboard), and the optional user interface 1003 may further include a standard wired interface, a wireless interface, among others. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory (NVM), such as at least one disk memory. The memory 1005 may also optionally be at least one storage device located remotely from the processor 1001. As shown in fig. 10, an operating system, a network communication module, a user interface module, and a device control application program may be included in the memory 1005, which is one type of computer-readable storage medium.
In the electronic device 1000 shown in fig. 10, the network interface 1004 may provide a network communication function; while user interface 1003 is primarily used as an interface for providing input to a user; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:
determining an update source code, and compiling the update source code to obtain an executable code corresponding to the update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in a blockchain system to directly run;
transmitting the executable codes to each node in the block chain system, so that each node updates the nodes and synchronizes the update state in the node operation process based on the executable codes;
and determining an update state synchronization result of each node, and determining that each node synchronously updates the update source code based on the update state synchronization result.
In some possible embodiments, the updating the source code includes at least one of:
pre-written initial code for updating each node in the blockchain system;
Library file code of the target application;
and the initial code compiled by any node in the block chain system is used for updating each node in the block chain system.
In some possible embodiments, the processor 1001 is further configured to:
transmitting the executable code to a target node in a blockchain system, so that the target node broadcasts the executable code to other nodes in the blockchain system;
and sending the executable code to any node in the blockchain system so that other nodes in the blockchain system acquire the executable code from the node through a consensus mechanism.
In some possible embodiments, when the processor 1001 is used as a node in a blockchain system, it is configured to:
acquiring an executable code corresponding to an update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in a blockchain system to directly run;
updating nodes in the node operation process based on the executable codes, and updating states synchronously with other nodes in the block chain system;
and determining a first execution result aiming at the executable code, and if the first execution result is consistent with a second execution result aiming at the executable code by other nodes in the blockchain system, determining that node updating aiming at the updating source code is completed.
In some possible embodiments, the processor 1001 is further configured to:
determining a first identifier of the update source code, wherein the first identifier comprises at least one of a service identifier of a service corresponding to the update source code or a function identifier of a corresponding function;
the executable code is stored as historical executable code based on the first identification.
In some possible embodiments, the processor 1001 is further configured to:
determining a target identifier corresponding to the first service or the first function in response to a version query request for the first service or the first function, and determining a version update record of the first service or the first function based on at least one history executable code corresponding to the target identifier;
and matching the executable codes with each history executable code, and allowing node updating based on the executable codes if each history executable code does not comprise the executable codes.
In some possible embodiments, the processor 1001 is configured to:
acquiring the update source code, and performing trusted verification on the executable code based on the update source code;
And if the executable code passes the verification, updating the node in the running process of the node based on the executable code.
It should be appreciated that in some possible embodiments, the processor 1001 may be a central processing unit (central processing unit, CPU), which may also be other general purpose processors, digital signal processors (digital signal processor, DSP), application specific integrated circuits (application specific integrated circuit, ASIC), off-the-shelf programmable gate arrays (field-programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The memory may include read only memory and random access memory and provide instructions and data to the processor. A portion of the memory may also include non-volatile random access memory. For example, the memory may also store information of the device type.
In a specific implementation, the electronic device 1000 may execute, through each functional module built in the electronic device, an implementation manner provided by each step in fig. 2 and/or fig. 4, and specifically, the implementation manner provided by each step may be referred to, which is not described herein again.
The embodiments of the present application further provide a computer readable storage medium, where a computer program is stored and executed by a processor to implement the method provided by each step in fig. 2 and/or fig. 4, and specifically refer to the implementation manner provided by each step, which is not described herein.
The computer readable storage medium may be an apparatus provided in any one of the foregoing embodiments or an internal storage unit of an electronic device, for example, a hard disk or a memory of the electronic device. The computer readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash card (flash card) or the like, which are provided on the electronic device. The computer readable storage medium may also include a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (randomaccess memory, RAM), or the like. Further, the computer-readable storage medium may also include both an internal storage unit and an external storage device of the electronic device. The computer-readable storage medium is used to store the computer program and other programs and data required by the electronic device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.
Embodiments of the present application provide a computer program product comprising a computer program or computer instructions which, when executed by a processor, perform the method provided by the steps of fig. 2 and/or fig. 4 by the voice playing method provided by the embodiments of the present application.
The terms "first," "second," and the like in the claims and specification and drawings of this application are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or electronic device that comprises a list of steps or elements is not limited to the list of steps or elements but may, alternatively, include other steps or elements not listed or inherent to such process, method, article, or electronic device. Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments. The term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The foregoing disclosure is only illustrative of the preferred embodiments of the present application and is not to be construed as limiting the scope of the claims, and therefore, equivalent variations in terms of the claims are intended to be included herein.

Claims (12)

1. A method of node update for a blockchain system, the method comprising:
determining an update source code, compiling the update source code to obtain an executable code corresponding to the update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in a blockchain system to directly run;
Transmitting the executable codes to each node in a blockchain system, so that each node updates the nodes and synchronizes update states in the node operation process based on the executable codes;
and determining an updating state synchronization result of each node, and determining that each node synchronously updates the updating source code based on the updating state synchronization result.
2. The method of claim 1, wherein the updating the source code comprises at least one of:
pre-written initial code for updating each node in the blockchain system;
library file code of the target application;
initial code compiled by any node in a blockchain system for updating each node in the blockchain system.
3. The method of claim 1, wherein the sending the executable code to each node in a blockchain system comprises at least one of:
transmitting the executable code to a target node in a blockchain system to cause the target node to broadcast the executable code to other nodes in the blockchain system;
the executable code is sent to any node in the blockchain system so that other nodes in the blockchain system acquire the executable code from the node through a consensus mechanism.
4. A method of node update for a blockchain system, the method comprising:
acquiring an executable code corresponding to an update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in a blockchain system to directly run;
updating nodes in the node operation process based on the executable codes, and updating states synchronously with other nodes in the blockchain system;
determining a first execution result for the executable code, and if the first execution result is consistent with a second execution result for the executable code by other nodes in the blockchain system, determining that node updating for the updating source code is completed.
5. The method according to claim 4, wherein the method further comprises:
determining a first identifier of the update source code, wherein the first identifier comprises at least one of a service identifier of a service corresponding to the update source code or a function identifier of a corresponding function;
the executable code is stored as historical executable code based on the first identification.
6. The method of claim 5, further comprising at least one of:
determining a target identifier corresponding to the first service or the first function in response to a version query request for the first service or the first function, and determining a version update record of the first service or the first function based on at least one history executable code corresponding to the target identifier;
matching the executable code with each historical executable code, and if each historical executable code does not comprise the executable code, allowing node updating based on the executable code.
7. The method of claim 4, wherein the updating the node during node operation based on the executable code comprises:
acquiring the update source code, and performing trusted verification on the executable code based on the update source code;
and if the executable code passes the verification, updating the node in the running process of the node based on the executable code.
8. A node update apparatus for a blockchain system, the apparatus comprising:
the code determining module is used for determining an update source code, compiling the update source code to obtain an executable code corresponding to the update source code, wherein the update source code corresponds to any programming language, and the executable code is a byte code in a preset format for supporting each node in the blockchain system to directly run;
The code sending module is used for sending the executable codes to all nodes in the blockchain system so that all the nodes update the nodes and synchronize update states in the node operation process based on the executable codes;
and the result determining module is used for determining an updating state synchronization result of each node and determining that each node synchronously updates the updating source code based on the updating state synchronization result.
9. A node update apparatus for a blockchain system, the apparatus comprising:
the code acquisition module is used for acquiring executable codes corresponding to the update source codes, wherein the update source codes correspond to any programming language, and the executable codes are byte codes in a preset format for supporting each node in the blockchain system to directly run;
the node updating module is used for updating the nodes in the node operation process based on the executable codes and synchronously updating states with other nodes in the block chain system;
and the information processing module is used for determining a first execution result aiming at the executable code, and if the first execution result is consistent with a second execution result aiming at the executable code by other nodes in the blockchain system, determining that node updating aiming at the updating source code is completed.
10. An electronic device comprising a processor and a memory, the processor and the memory being interconnected;
the memory is used for storing a computer program;
the processor is configured to perform the method of any of claims 1 to 7 when the computer program is invoked.
11. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program, which is executed by a processor to implement the method of any one of claims 1 to 7.
12. A computer program product, characterized in that it comprises a computer program or computer instructions which, when executed by a processor, implement the method of any one of claims 1 to 7.
CN202210015869.8A 2022-01-07 2022-01-07 Node updating method, device, equipment and storage medium of block chain system Pending CN116450133A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210015869.8A CN116450133A (en) 2022-01-07 2022-01-07 Node updating method, device, equipment and storage medium of block chain system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210015869.8A CN116450133A (en) 2022-01-07 2022-01-07 Node updating method, device, equipment and storage medium of block chain system

Publications (1)

Publication Number Publication Date
CN116450133A true CN116450133A (en) 2023-07-18

Family

ID=87120714

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210015869.8A Pending CN116450133A (en) 2022-01-07 2022-01-07 Node updating method, device, equipment and storage medium of block chain system

Country Status (1)

Country Link
CN (1) CN116450133A (en)

Similar Documents

Publication Publication Date Title
US11438139B2 (en) Blockchain based secure naming and update verification
CN107577427B (en) data migration method, device and storage medium for blockchain system
CN107396360B (en) Block verification method and device
US20190205121A1 (en) Distributed code repository management
CN110912707B (en) Block chain-based digital certificate processing method, device, equipment and storage medium
WO2019223469A1 (en) Block chain network management method, device, medium and electronic device
US11372980B2 (en) Blockchains for software component vulnerability databases
CN107276765B (en) Processing method and device for consensus in block chain
US11663175B2 (en) Deployment of applications conforming to application data sharing and decision service platform schema
CN110597918A (en) Account management method and device and computer readable storage medium
CN111597567B (en) Data processing method, data processing device, node equipment and storage medium
CN112764751A (en) Interface generation method and device, interface request method and device and storage medium
CN112714158A (en) Transaction processing method, relay network, cross-link gateway, system, medium, and device
WO2021007863A1 (en) Integrity auditing for multi-copy storage
CN106990974B (en) APP updating method and device and electronic equipment
JP2023525576A (en) Scope of control of authentication keys for software updates
US11379215B1 (en) Application-update techniques
CN114584326B (en) Block chain data processing method and device, electronic equipment and storage medium
CN116450133A (en) Node updating method, device, equipment and storage medium of block chain system
US11496304B2 (en) Information processing device, information processing method, and storage medium
JP2015125512A (en) Management system, management method by management system, management device, control method for management device, and program
CN110719163B (en) Information processing method, device and storage medium
KR20150137766A (en) System and method for creating stack of virtual machine
CN112364049B (en) Data synchronization script generation method, system, terminal and storage medium
CN112541756B (en) Block chain contract upgrading method and device, computer equipment and readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40088465

Country of ref document: HK