Node updating method and device of blockchain system, equipment and storage medium

Abstract

Embodiments of the present application disclose a node updating method and device of a blockchain system, equipment and a storage medium, which can be applied to the fields of blockchain technology and computer technology. The method comprises the following steps: determining updated source code, compiling the updated source code to obtain executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format which supports direct running of each node in the blockchain system; sending the executable code to each node in the blockchain system, so that each node updates the node and synchronizes the state during node running based on the executable code; determining an update state synchronization result of each node, and determining that each node synchronously updates the updated source code based on the update state synchronization result. By using the embodiments of the present application, the version difference between each node in the blockchain system can be reduced, the node updating efficiency is improved, and the applicability is high.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a node update method, apparatus, device, and storage medium for a blockchain system. Background Technology

[0002] With the continuous development of blockchain technology, the existing blockchain system update scheme mainly involves each node in the blockchain system periodically searching for and downloading the latest updated source code, and then updating the corresponding functions or business based on the updated source code.

[0003] However, under the existing update mechanism, due to network latency and inconsistent times when nodes obtain updated source code, some nodes in the blockchain system often fail to update in a timely manner, resulting in version differences between nodes. Furthermore, after each node completes its update, it often needs to be restarted to run the updated business logic or functions, impacting node update efficiency. Summary of the Invention

[0004] This application provides a node update method, apparatus, device, and storage medium for a blockchain system, which can reduce version differences between nodes in the blockchain system, improve node update efficiency, and has high applicability.

[0005] On one hand, embodiments of this application provide a node update method for a blockchain system, the method comprising:

[0006] The updated source code is determined and compiled to obtain the executable code corresponding to the updated source code. The updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system.

[0007] The executable code is sent to each node in the blockchain system so that each node updates its node status and synchronizes the update based on the executable code during node operation.

[0008] Determine the update status synchronization results of each of the aforementioned nodes, and based on the update status synchronization results, determine that each of the aforementioned nodes will perform synchronized updates for the aforementioned updated source code.

[0009] On the other hand, embodiments of this application provide a node update method for a blockchain system, the method comprising:

[0010] Obtain the executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system;

[0011] Based on the aforementioned executable code, node updates are performed during node operation, and the status is synchronized with other nodes in the aforementioned blockchain system.

[0012] If the first execution result of the executable code is determined, and the first execution result is consistent with the second execution result of other nodes in the blockchain system for the executable code, then the node update for the updated source code is determined to be complete.

[0013] On the other hand, embodiments of this application provide a node update device for a blockchain system, the device comprising:

[0014] The code determination module is used to determine the updated source code, compile the updated source code to obtain the executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system.

[0015] The code sending module is used to send the executable code to each node in the blockchain system, so that each node can update its node status and synchronize its state based on the executable code during node operation.

[0016] The result determination module is used to determine the update status synchronization result of each of the above nodes, and based on the update status synchronization result, determine that each of the above nodes should perform a synchronized update of the above updated source code.

[0017] On the other hand, embodiments of this application provide a node update device for a blockchain system, the device comprising:

[0018] The code acquisition module is used to acquire the executable code corresponding to the updated source code. The updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system.

[0019] The node update module is used to update the node during node operation based on the above executable code, and to synchronize the status with other nodes in the above blockchain system.

[0020] The information processing module is used to determine the first execution result of the executable code. If the first execution result is consistent with the second execution result of other nodes in the blockchain system for the executable code, then the node update for the updated source code is determined to be complete.

[0021] On the other hand, embodiments of this application provide an electronic device, including a processor and a memory, which are interconnected;

[0022] The aforementioned memory is used to store computer programs;

[0023] The processor described above is configured to execute any of the node update methods of the blockchain system provided in the embodiments of this application when the computer program described above is invoked.

[0024] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program that is executed by a processor to implement a node update method for any of the blockchain systems provided in embodiments of this application.

[0025] On the other hand, embodiments of this application provide a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement any of the node update methods of the blockchain system provided in embodiments of this application.

[0026] In this embodiment, by compiling the updated source code into bytecode (executable code) in a preset format that supports direct execution by nodes in the blockchain system, nodes in the blockchain system can directly update themselves based on the executable code, improving node update efficiency. Furthermore, by synchronizing state updates, all nodes in the blockchain system can participate in node updates, thereby ensuring version uniformity and high applicability across all nodes in the blockchain system. Attached Figure Description

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

[0028] Figure 1 This is a schematic diagram illustrating the principle of the node update method for the blockchain system provided in this application embodiment;

[0029] Figure 2 This is a flowchart illustrating a node update method for a blockchain system provided in an embodiment of this application;

[0030] Figure 3 This is a schematic diagram illustrating the source code compilation and application scenarios provided in the embodiments of this application;

[0031] Figure 4 This is another flowchart illustrating the node update method of the blockchain system provided in this application embodiment;

[0032] Figure 5 This is a schematic diagram of a synchronous update status scenario provided in an embodiment of this application;

[0033] Figure 6 This is a schematic diagram of the node structure in the blockchain system provided in the embodiments of this application;

[0034] Figure 7 This is a schematic diagram illustrating a scenario of node updating based on a wasm file, as provided in an embodiment of this application.

[0035] Figure 8 This is a schematic diagram of the structure of a node update device for a blockchain system provided in an embodiment of this application;

[0036] Figure 9 This is another schematic diagram of the node update device of the blockchain system provided in the embodiments of this application;

[0037] Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] See Figure 1 , Figure 1 This is a schematic diagram illustrating the principle of the node update method for a blockchain system provided in this application embodiment. For example... Figure 1 As shown, before upgrading each node of the blockchain system, the updated source code can be determined and compiled into executable code, that is, the updated source code can be compiled into bytecode in a preset format that supports direct execution by each node in the blockchain system.

[0040] Furthermore, the executable code corresponding to the updated source code is sent to each node in the blockchain system, enabling each node to update its node based on the received executable code during node operation. For example, the executable code is sent to blockchain system 10, allowing nodes 101, 102, 103, and 104 in blockchain system 10 to update their nodes based on the executable code during node operation. Simultaneously, each node in the blockchain system synchronizes its update status with each other during node updates. For example, nodes 101, 102, 103, and 104 can synchronize their status updates during the update process to achieve the goal of synchronizing updates across all nodes as much as possible. Based on this, the update status synchronization results of each node can be obtained, and based on the update status synchronization results, it can be determined that each node is synchronously updating the updated source code.

[0041] The blockchain system 101 in this embodiment can also be called a data sharing system, that is, a system used for data sharing between nodes. For example, the data sharing system may include multiple nodes such as node 101, node 102, node 103, and node 104. Each node can be a computing device connected to the blockchain system, such as a server or user terminal. The nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the data sharing system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer. Each node can receive relevant information during normal operation and maintain the shared data within the data sharing system based on the received information.

[0042] In this application embodiment, the server within the blockchain system (data sharing system) can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The terminal can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, in-vehicle terminal, smart TV, etc., but is not limited to these.

[0043] See Figure 2 , Figure 2 This is a flowchart illustrating a node update method for a blockchain system provided in this application. Figure 2 As shown, the node update method for a blockchain system provided in this application embodiment can be applied to related devices, servers, etc. that have a communication connection with the blockchain system, and can also be applied to related nodes in the blockchain system. Specifically, it includes the following steps:

[0044] Step S21: Determine the updated source code, compile the updated source code, and obtain the executable code corresponding to the updated source code.

[0045] In some feasible implementations, the updated source code is the initial code used to update each node in the blockchain system, that is, the initial code used to update the business or functions of each node in the blockchain system, or the initial code used to update the system of each node in the blockchain system.

[0046] For example, the updated source code mentioned above could be the source code corresponding to new functions developed for each node in the blockchain system, or it could be the source code used to fix defects (bugs) related to a certain business function of each node in the blockchain system. The specific requirements can be determined based on the actual application scenario, and there are no restrictions here.

[0047] Updating the source code can correspond to any programming language; that is, the updated source code can be code written in any programming language. The specific details can be determined based on the actual application scenario requirements, and there are no restrictions here.

[0048] In some feasible implementations, the updated source code can be pre-written initial code for updating the nodes in the blockchain system, such as deployment code or upgrade code written by developers for a new feature. When determining which source code to update, the initial code written by developers for updating the nodes in the blockchain system can be obtained.

[0049] Optionally, the updated source code can be the library code of the target application. The target application can be any application run by any node in the blockchain system. For the target application, its various functions can be divided into relatively independent library code files; when executing a specific function, the corresponding library code file needs to be called.

[0050] Therefore, the updated source code can be any library file code of the target application, and the corresponding program function of that library file code is the newly launched program function. Alternatively, the updated source code can be the initial code developed by the Software Development Kit (SDK), which can be determined based on the actual application scenario requirements, and is not restricted here.

[0051] When determining which source code to update, the target program function in the target application can be identified. This target program function represents a function that is not yet online on any node in the blockchain system. The updated source code is then obtained by calling the corresponding library file code for this target program function.

[0052] Optionally, the update source code can be initial code compiled by any node in the blockchain system for updating other nodes in the blockchain system. That is, any node in the blockchain system can publish the update source code, and cause other nodes in the blockchain system to update their nodes based on the executable code corresponding to the update source code sent by that node.

[0053] In some feasible implementations, after the updated source code is determined, the updated source code can be compiled to obtain the executable code corresponding to the updated source code.

[0054] Specifically, the executable code corresponding to the updated source code is bytecode in a preset format that supports direct execution by nodes in the blockchain system. For updated source code corresponding to any programming language, it can be compiled into bytecode in the preset format by a compiler, thereby enabling nodes in the blockchain system to directly execute the bytecode.

[0055] In other words, for any updated source code corresponding to a programming language, the updated source code can be translated into executable code with multiple instructions, similar to assembly language.

[0056] The preset format mentioned above can be WebAssembly or other formats, depending on the specific application requirements, and is not limited here. When the preset format is WebAssembly, the updated source code can be compiled using the corresponding compiler to obtain a wasm file, which is essentially a string of binary bytecode.

[0057] The executable code obtained by compiling the updated source code in a preset format can also be called a runtime library file or runtime library code, etc., and no restriction is made here.

[0058] See Figure 3 , Figure 3 This is a schematic diagram illustrating the scenario of source code compilation and application provided in the embodiments of this application. For example... Figure 3 As shown, the source code corresponding to a certain function or business can be compiled using the WebAssembly compiler to obtain a wasm file composed of binary bytecode. Furthermore, for different users, they can directly run the wasm file based on the runtime (the environment in which the wasm file is run) corresponding to the wasm file, without needing to recompile the source code or wasm file.

[0059] Step S22: Send the executable code to each node in the blockchain system so that each node can update its node status and synchronize its state during the node's operation based on the executable code.

[0060] In some feasible implementations, when sending executable code to nodes in a blockchain system, the executable code can be sent to a target node in the blockchain system, so that the target node broadcasts the executable code to other nodes in the blockchain system. This allows each node in the blockchain system to update its node status synchronously during node operation.

[0061] The target node mentioned above can be any node in the blockchain system, or it can be the central node or routing node in the blockchain system, etc. The specific target node can be determined based on the actual application scenario requirements, and there are no restrictions here.

[0062] Each node in a blockchain system has a corresponding node identifier. Furthermore, each node can store the node identifiers of other nodes in the blockchain system. This allows for the broadcasting of generated blocks or other information to other nodes based on their identifiers. For example, executable code can be broadcast to other nodes in the blockchain via a target node. Each node can maintain a node identifier list as shown in the table below, storing the node name and its corresponding identifier. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. The table below uses IP addresses as an example.

[0063] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N xx.xx.xx.xx

[0064] Optionally, to ensure information exchange within the blockchain system, each node in the blockchain system can be connected to other nodes, allowing for information transmission between them. Therefore, after the executable code corresponding to the updated source code is sent to any node in the blockchain system, other nodes can obtain the executable code through a consensus mechanism (consensus algorithm) and store it as data in the shared data, ensuring that all nodes in the blockchain system receive the executable code corresponding to the updated source code.

[0065] In some feasible implementations, when the executable code corresponding to the updated source code is sent to each node in the blockchain system, the executable code can be hashed to obtain a first digest of the executable code, and then the first digest can be encrypted based on the private key of the code publisher of the updated source code to obtain a digital signature of the executable code, thereby obtaining a digital signature of the executable code corresponding to the updated source code.

[0066] Furthermore, when sending the executable code corresponding to the updated source code to each node in the blockchain system, the digital signature of the executable code can be sent at the same time. This allows each node in the blockchain system to determine whether the executable code has been tampered with during transmission based on the digital signature after receiving the executable code and its digital signature. If the executable code has not been tampered with, the node can then update its nodes based on the executable code.

[0067] In this context, the publisher of the updated source code is the source of the updated source code. For example, if the updated source code is pre-written initial code used to update each node in the blockchain system, the publisher of the updated source code is the corresponding developer. If the updated source code is library file code of the target application, the publisher of the updated source code can be the corresponding target application. If the updated source code is initial code compiled by any node in the blockchain system for updating each node in the blockchain system, the publisher of the updated source code can be that node.

[0068] It should be noted that the above descriptions of the code publisher for updating source code are merely examples. The specific publisher can be determined based on the actual application scenario requirements. For example, the code publisher for updating source code can also be a pre-defined administrator, etc., without any restrictions.

[0069] Step S23: Determine the update status synchronization result of each node. Based on the update status synchronization result, determine that each node should perform synchronous updates for the updated source code.

[0070] In some feasible implementations, after the updated source code is sent to each node in the blockchain system, the update status synchronization result of each node can be determined, so as to further confirm that each node has synchronized the update of the source code based on the update status synchronization result of each node.

[0071] In determining the synchronization result of the update status of each node, the update status of each node can be obtained from any node in the blockchain system. That is, the node can obtain the update status of other nodes and generate and send the update status synchronization result based on the update status of each node. Alternatively, the update status of each node in the blockchain system can be obtained directly, and the synchronization result of the update status of each node can be determined based on the update status of each node in the blockchain system.

[0072] For example, when sending executable code to a node in a blockchain system, the executable code is also sent to a target node in the blockchain system, so that the target node broadcasts the executable code to other nodes in the blockchain system. At the same time, the target node can obtain the update status of each node and generate an update status synchronization result, thereby obtaining the update status synchronization result of each node in the blockchain system from the target node.

[0073] In some feasible implementations, after confirming that each node has synchronously updated the source code, the execution results of each node in the blockchain system for the executable code can be further obtained, so as to determine that each node in the blockchain system has completed the node update based on the execution results of each node in the blockchain system.

[0074] Similarly, when obtaining the execution results of each node for the executable code, the execution results of each node for the executable code can be obtained from any node in the blockchain system. That is, the node can 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 can be obtained directly from each node in the blockchain system, without any restrictions.

[0075] For example, when sending executable code to a node in a blockchain system, the executable code is also sent to a target node in the blockchain system, so that the target node broadcasts the executable code to other nodes in the blockchain system. At the same time, the target node can obtain the execution results of each node on the executable code, thereby obtaining the execution results of each node on the blockchain system on the executable code from the target node.

[0076] See Figure 4 , Figure 4 This is another flowchart illustrating the node update method of the blockchain system provided in this application embodiment. For example... Figure 4 As shown in the embodiments of this application, the node update method for a blockchain system can be applied to any node in the blockchain system, and may specifically include the following steps:

[0077] Step S41: Obtain the executable code corresponding to the updated source code.

[0078] The updated source code is the initial code used to update each node in the blockchain system, that is, the initial code used to update the business or functions of each node in the blockchain system, or the initial code used to update the system of each node in the blockchain system.

[0079] Updating the source code can correspond to any programming language; that is, the updated source code can be code written in any programming language. The specific details can be determined based on the actual application scenario requirements, and there are no restrictions here.

[0080] The updated source code can be pre-written initial code for updating each node in the blockchain system, library file code of the target application, or initial code compiled by any node in the blockchain system for updating each node in the blockchain system; there are no restrictions on this.

[0081] The aforementioned preset format can be WebAssembly or other formats, without restriction. When the preset format is WebAssembly, the updated source code can be compiled into a wasm file using the corresponding compiler. This wasm file is essentially a string of binary bytecode. In other words, the executable code corresponding to the updated source code can be a wasm file.

[0082] In some feasible implementations, the target node in the blockchain system can obtain the executable code corresponding to the updated source code and broadcast the executable code to other nodes. That is, other nodes in the blockchain besides the target node can directly receive the executable code broadcast by the target node.

[0083] Optionally, if any node in the blockchain system receives the executable code corresponding to the updated source code, other nodes in the blockchain system, excluding that node, can obtain the executable code corresponding to the updated source code from that node through a consensus mechanism based on the trust connection between the nodes.

[0084] In some feasible implementations, when the executable code corresponding to the updated source code is obtained, the digital signature corresponding to the executable code can be obtained at the same time, so as to determine whether the executable code has been tampered with during transmission based on the digital signature of the executable code.

[0085] Specifically, after receiving the executable code and its digital signature, a hash calculation can be performed on the executable code to obtain a second digest of the executable code. Simultaneously, the digital signature of the executable code is decrypted using the public key of the code publisher to obtain the second digest of the executable code.

[0086] Furthermore, the first digest and the second digest of the executable code are compared. If they match, it is determined that the executable code has not been tampered with during transmission, and node updates are then performed based on the executable code. If they do not match, it is determined that the executable code has been tampered with during transmission. In this case, the executable code can be discarded and a prompt message sent to retrieve it again.

[0087] For example, suppose the digital signature of the executable code corresponding to the updated source code is "0010101". The digital signature "0010101" can be decrypted using the code publisher's public key to obtain the first digest of the executable code (let's say "1000100"). Simultaneously, a hash calculation can be performed on the received executable code to obtain its second digest. If the second digest of the executable code is "1000100", it can be determined that the executable code has not been tampered with during transmission; otherwise, it can be determined that the executable code has been tampered with during transmission.

[0088] Step S42: Update the node during its operation based on the executable code, and synchronize the status with other nodes in the blockchain system.

[0089] In some feasible implementations, when updating based on executable code, since the executable code corresponding to the updated source code is bytecode in a preset format, such as binary bytecode, any node in the blockchain system can directly run the executable code to update the node during node operation, thereby avoiding the need to recompile the executable code and restart the node, thus improving the node update efficiency.

[0090] During the node update process, the status can be updated synchronously with other nodes in the blockchain system to ensure that all nodes in the blockchain are updated based on executable code.

[0091] Specifically, the aforementioned update status can refer to a node receiving the executable code corresponding to the updated source code. After receiving the updated source code, the status can be synchronized with other nodes in the blockchain system to ensure that all nodes have received the executable code. Then, after confirming that all nodes in the blockchain system have received the executable code, node updates are performed during node operation based on the executable code.

[0092] Optionally, the aforementioned update status can be based on node updates completed using executable code. Based on this, after a node update is completed using executable code, the status can be synchronized with other nodes in the blockchain system to ensure that all nodes in the blockchain system have completed their updates.

[0093] In the process of synchronizing and updating the status, nodes in the blockchain system that have not yet updated their status based on the executable code can update their status in a timely manner during the node's operation based on the executable code, thereby further ensuring that all nodes in the blockchain system will update their status based on the received executable code.

[0094] See Figure 5 , Figure 5 This is a schematic diagram illustrating a scenario of synchronized state updates provided in an embodiment of this application. Assume the blockchain system includes nodes A, B, C, D, and E. Node A receives the executable code corresponding to the updated source code and sends the executable code to the other nodes in the blockchain system. Furthermore, node A updates its node based on the executable code during its operation, synchronizing its state with nodes B, C, D, and E. During the process of synchronizing state updates with nodes B, C, D, and E, nodes B, C, D, and E can also update their nodes based on the executable code.

[0095] When synchronizing and updating the state with other nodes in the blockchain system, the Raft algorithm, Power Fault Tolerance (PFT) algorithm, and other consensus algorithms can be used. The specific method can be determined based on the actual application scenario requirements and is not restricted here.

[0096] Among them, updating nodes based on executable code can be to add new functions to nodes or to fix defects related to a certain business function. The specifics can be determined based on the actual application scenario requirements, and there are no restrictions here.

[0097] In some feasible implementations, before updating the node during node operation based on the executable code, the updated source code can be obtained, and a trust verification can be performed based on the updated source code and the executable code. If the executable code passes the verification, the node update can then be performed based on the executable code.

[0098] Specifically, the updated source code can be compiled using the same compilation method. The compilation result is then matched with the executable code. If the corresponding instructions are the same, the executable code is considered to have passed verification. It is important to note that since updating nodes based on the compilation results of the updated source code requires a node restart to complete the update, after confirming that the executable code has passed verification, a node update must be performed based on the executable code.

[0099] Optionally, the updated source code can be sent to a smart contract, which can then compile the updated source code using any compilation method and determine the execution result of the compiled code. Simultaneously, the smart contract can pre-execute the executable code and compare the corresponding executable results. If they match, the executable code is deemed to have passed verification.

[0100] Step S43: Determine the first execution result for the executable code. If the first execution result is consistent with the second execution result of other nodes in the blockchain system for the executable code, then the node update for updating the source code is completed.

[0101] In some feasible implementations, after updating the node based on the executable code during node operation, the execution result of the executable code can be determined (hereinafter referred to as the first execution result for ease of description). The first execution result can be the update result of updating the node based on the executable code, or it can be the execution result of executing the executable code again after the node update is completed.

[0102] Furthermore, the first execution result can be compared with the execution results of other nodes in the blockchain system for the executable code (hereinafter referred to as the second execution result for ease of description). If the first execution result is consistent with the second execution result corresponding to other nodes, it is determined that the node update based on the executable code has been successfully performed, that is, the node update for the updated source code has been completed.

[0103] Optionally, second execution results from other nodes in the blockchain system can be obtained, and the target execution result can be determined from them. The target execution result is the execution result with the highest number of execution results. The first execution result is then matched with the target execution result. If they match, it is determined that the node update based on the executable code has been successfully performed, that is, the node update for the updated source code is determined to be complete.

[0104] Optionally, the first execution result of the executable code can be sent to a smart contract for the smart contract to determine whether the first execution result is erroneous. If the first execution result is accurate, it is determined that the node update based on the executable code has been successfully performed, that is, the node update based on the updated source code is considered complete.

[0105] In some feasible implementations, after different update states of other nodes in each blockchain system, the update state synchronization result of each node can be determined and sent to the code publisher (such as related devices or servers that have communication connections with the blockchain system), so that the code publisher can further confirm that each node has synchronized the update of the source code based on the update state synchronization result of each node.

[0106] Specifically, the update status of each node can be obtained from other nodes in the blockchain system. Based on the update status of other nodes and its own update status, an update status synchronization result is generated and sent to the code publisher so that the code publisher can further confirm that each node has synchronized the update of the source code based on the update status synchronization result of each node.

[0107] In some feasible implementations, after determining that the node update for the updated source code has been completed, the first execution result can be sent to the code publisher so that the code publisher can determine that each node in the blockchain system has completed the node update based on the execution results corresponding to each node in the blockchain system.

[0108] Optionally, the second execution results of other nodes in the blockchain system for the executable code can be obtained first, and then the first and second execution results can be sent together to the code publisher so that the code publisher can determine that each node in the blockchain system has completed the node update based on the execution results corresponding to each node in the blockchain system.

[0109] In some feasible implementations, after completing the node update for the updated source code, a first identifier of the updated source code can be determined, and the executable code can be stored as historical executable code based on the first identifier.

[0110] The first identifier may include the business identifier of the business corresponding to the updated source code or the function identifier of the corresponding function, or it may be the program identifier of a certain application, etc. The specific identifier can be determined based on the actual application scenario requirements, and there are no restrictions here.

[0111] In other words, for any node in a blockchain system, after updating the node based on executable code, the corresponding executable code can be stored. For example, executable codes corresponding to the same function or the same business can be stored in the order of update, thereby recording the update process corresponding to any function or business.

[0112] In this blockchain system, any node can store historical executable code in a database or cloud storage space corresponding to that node, without any restrictions. Furthermore, when storing historical executable code, the corresponding updated source code identifier can be stored along with the identifier of the corresponding business or function.

[0113] Therefore, since each node in a blockchain system stores its corresponding historical executable code after completing any node update, when updating a node based on the executable code corresponding to the updated source code, this executable code can be matched with each historical executable code. If each historical executable code includes the executable code corresponding to the updated source code, it means that an update to the updated source code has already been performed (e.g., the functionality corresponding to the updated source code is already available), and the node update will not be performed based on the executable code corresponding to the updated source code. If each historical executable code does not include the executable code corresponding to the updated source code, it means that no update to the updated source code has been performed, and in this case, the node update can be performed based on the executable code corresponding to the updated source code.

[0114] Simultaneously, in response to a version query request for any service (hereinafter referred to as the first service) or any function (hereinafter referred to as the first function), the system can determine the target identifier corresponding to the first service or the first function, and identify at least one historical executable code corresponding to the target identifier from the historical executable code. Then, based on the identified at least one historical executable code, the system can determine the version update record corresponding to the first function or the first service, enabling effective querying of update records for specific services or features.

[0115] See Figure 6 , Figure 6 This is a schematic diagram of the node structure in the blockchain system provided in this application embodiment. For example... Figure 6 As shown, for any node in a blockchain system, the node includes a network interface module used to implement interactive and communication functions such as data reading and writing, querying, and data synchronization. For example, the query interface returns version update incentives for corresponding business or functions, the update interface receives executable code corresponding to updated source code, and the upload interface sends relevant data to other nodes.

[0116] Among them, the code submitter can send executable code to the nodes in the blockchain system through the network interface module via Remote Procedure Call (RPC).

[0117] This node also includes a consensus module, which can be used to synchronize the updated status with other nodes in the blockchain system and to reach consensus with new blocks during the block generation process.

[0118] This node also includes business and functional modules, which can be used to implement corresponding business logic or functions and process corresponding business data or functional data.

[0119] This node may also include a code management module, which is used to store the historical executable code corresponding to each business and function. For example, the historical executable code V1, V2 and V3 corresponding to business A can be sorted according to the update order to facilitate the query of the version update record of business A.

[0120] This node also includes a database, which enables data storage, such as storing historical executable code.

[0121] In this application's embodiments, the processes such as data matching and information querying can be implemented using cloud computing technology. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. Cloud computing is a product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.

[0122] The following is combined with Figure 7 The node update method of the blockchain system provided in the embodiments of this application will be further described. Figure 7This is a schematic diagram illustrating a scenario of node updates based on Wasm files, as provided in an embodiment of this application. Figure 7 As shown, the code publisher provides updated source code for business A, and uses the WebAssembly compiler to compile the updated source code into a wasm file (executable code) of binary bytecode, and sends it to each node in the blockchain system.

[0123] In the blockchain system, between receiving the wasm file, each node's code management module only stores the executable code V1 and V2 corresponding to business A, meaning that each node has only updated business A twice.

[0124] Furthermore, for nodes in the blockchain system, each node can update itself and synchronize its state during operation based on the wasm file. For any given node, the execution result of the wasm file can be matched with the execution results of the corresponding wasm file of other nodes to complete the result verification and thus determine that the update of business A has been successfully completed.

[0125] At this point, the code management module of each node in the blockchain system stores the new business code V3 corresponding to business A, which is the wasm file corresponding to this node update, in order to store the update record for business A.

[0126] In this embodiment, by compiling the updated source code into bytecode (executable code) in a preset format that allows nodes in the blockchain system to run directly, nodes can directly execute the executable code to update themselves without the need for file replacement or other operations. This eliminates the need for cumbersome update steps such as node restarts, improving node update efficiency. Furthermore, by synchronizing their status updates, all nodes in the blockchain system can participate in the update process, ensuring version uniformity across all nodes and preventing compatibility issues, service anomalies, or even outages caused by outdated versions. This approach offers high applicability.

[0127] See Figure 8 , Figure 8 This is a schematic diagram of a node update device for a blockchain system provided in an embodiment of this application. The device provided in this embodiment includes:

[0128] The code determination module 81 is used to determine the updated source code, compile the updated source code to obtain the executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system.

[0129] The code sending module 82 is used to send the executable code to each node in the blockchain system, so that each node can update its node status and synchronize its status during the node operation based on the executable code.

[0130] The result determination module 83 is used to determine the update status synchronization result of each of the above nodes, and based on the update status synchronization result, determine that each of the above nodes will perform synchronous updates for the above updated source code.

[0131] In some feasible implementations, the aforementioned updated source code includes at least one of the following:

[0132] Pre-written initial code for updating the nodes in the blockchain system;

[0133] The target application's library file code;

[0134] The initial code compiled by any node in the blockchain system to update the nodes in the aforementioned blockchain system.

[0135] In some feasible implementations, the code sending module 82 described above is used for:

[0136] The executable code is sent to the target node in the blockchain system, so that the target node broadcasts the executable code to other nodes in the blockchain system.

[0137] The executable code is sent to any node in the blockchain system so that other nodes in the blockchain system can obtain the executable code from that node through a consensus mechanism.

[0138] In specific implementation, the above-mentioned device can perform the above-described actions through its built-in functional modules. Figure 2 The implementation methods provided for each step are detailed in the above-mentioned implementation methods, and will not be repeated here.

[0139] See Figure 9 , Figure 9 This is another structural schematic diagram of the node update device for the blockchain system provided in this application embodiment. The device provided in this application embodiment includes:

[0140] The code acquisition module 91 is used to acquire the executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system.

[0141] The node update module 92 is used to update the node during node operation based on the above executable code, and to synchronize the status update with other nodes in the above blockchain system.

[0142] The information processing module 93 is used to determine the first execution result of the executable code. If the first execution result is consistent with the second execution result of other nodes in the blockchain system for the executable code, then the node update for the updated source code is determined to be completed.

[0143] In some feasible implementations, the information processing module 93 described above is used for:

[0144] Determine the first identifier of the aforementioned updated source code, wherein the first identifier includes at least one of the business identifier of the business corresponding to the aforementioned updated source code or the function identifier of the corresponding function;

[0145] Based on the first identifier mentioned above, the executable code is stored as historical executable code.

[0146] In some feasible implementations, the information processing module 93 described above is further used for:

[0147] In response to a version query request for the first service or the first function, a target identifier corresponding to the first service or the first function is determined, and a version update record of the first service or the first function is determined based on at least one historical executable code corresponding to the target identifier.

[0148] The executable code is matched with each historical executable code. If the executable code is not included in any of the historical executable codes, then node updates are allowed based on the executable code.

[0149] In some feasible implementations, the node update module 92 described above is further used for:

[0150] Obtain the updated source code and perform a trusted verification of the executable code based on the updated source code.

[0151] If the above executable code passes verification, the node will be updated during node operation based on the above executable code.

[0152] In specific implementation, the above-mentioned device can perform the above-described actions through its built-in functional modules. Figure 4 The implementation methods provided for each step are detailed in the above-mentioned implementation methods, and will not be repeated here.

[0153] See Figure 10 , Figure 10 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 10As shown, the electronic device 1000 in this embodiment may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the electronic device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1004 may be a high-speed RAM or non-volatile memory (NVM), such as at least one disk storage device. The memory 1005 may optionally be at least one storage device located remotely from the processor 1001. Figure 10 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0154] exist Figure 10 In the illustrated electronic device 1000, the network interface 1004 provides network communication functionality; the user interface 1003 primarily provides an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0155] The updated source code is determined and compiled to obtain the executable code corresponding to the updated source code. The updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system.

[0156] The executable code is sent to each node in the blockchain system so that each node updates its node status and synchronizes the update based on the executable code during node operation.

[0157] Determine the update status synchronization results of each of the aforementioned nodes, and based on the update status synchronization results, determine that each of the aforementioned nodes will perform synchronized updates for the aforementioned updated source code.

[0158] In some feasible implementations, the aforementioned updated source code includes at least one of the following:

[0159] Pre-written initial code for updating the nodes in the blockchain system;

[0160] The target application's library file code;

[0161] The initial code compiled by any node in the blockchain system to update the nodes in the aforementioned blockchain system.

[0162] In some feasible implementations, the processor 1001 is further configured to:

[0163] The executable code is sent to the target node in the blockchain system, so that the target node broadcasts the executable code to other nodes in the blockchain system.

[0164] The executable code is sent to any node in the blockchain system so that other nodes in the blockchain system can obtain the executable code from that node through a consensus mechanism.

[0165] In some feasible implementations, when the processor 1001 acts as a node in a blockchain system, it is used for:

[0166] Obtain the executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system;

[0167] Based on the aforementioned executable code, node updates are performed during node operation, and the status is synchronized with other nodes in the aforementioned blockchain system.

[0168] If the first execution result of the executable code is determined, and the first execution result is consistent with the second execution result of other nodes in the blockchain system for the executable code, then the node update for the updated source code is determined to be complete.

[0169] In some feasible implementations, the processor 1001 is further configured to:

[0170] Determine the first identifier of the aforementioned updated source code, wherein the first identifier includes at least one of the business identifier of the business corresponding to the aforementioned updated source code or the function identifier of the corresponding function;

[0171] Based on the first identifier mentioned above, the executable code is stored as historical executable code.

[0172] In some feasible implementations, the processor 1001 is further configured to:

[0173] In response to a version query request for the first service or the first function, a target identifier corresponding to the first service or the first function is determined, and a version update record of the first service or the first function is determined based on at least one historical executable code corresponding to the target identifier.

[0174] The executable code is matched with each historical executable code. If the executable code is not included in any of the historical executable codes, then node updates are allowed based on the executable code.

[0175] In some feasible implementations, the processor 1001 described above is used for:

[0176] Obtain the updated source code and perform a trusted verification of the executable code based on the updated source code.

[0177] If the above executable code passes verification, the node will be updated during node operation based on the above executable code.

[0178] It should be understood that in some feasible implementations, the processor 1001 described above may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. The memory may include read-only memory and random access memory, and provides 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 device type information.

[0179] In specific implementation, the aforementioned electronic device 1000 can perform the above-described actions through its built-in functional modules. Figure 2 and / or Figure 4 The implementation methods provided for each step are detailed in the above-mentioned implementation methods, and will not be repeated here.

[0180] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement... Figure 2 and / or Figure 4 The methods provided in each step are detailed in the implementation methods provided in the above steps, and will not be repeated here.

[0181] The aforementioned computer-readable storage medium can be an internal storage unit of the apparatus or electronic device provided in any of the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device. The aforementioned computer-readable storage medium can also include magnetic disks, optical disks, read-only memory (ROM), or random access memory (RAM), etc. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices 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 can also be used to temporarily store data that has been output or will be output.

[0182] This application provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, the voice playback method provided in this application is executed. Figure 2 and / or Figure 4 The methods provided for each step in the process.

[0183] The terms "first," "second," etc., used in the claims, description, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or electronic device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or electronic devices. References to "embodiment" herein mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The presentation of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments. The term "and / or" as used in this application's description and appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0184] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Those skilled in the art can implement the described functions using different methods for each specific application, but such implementations should not be considered beyond the scope of this application.

[0185] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A node update method for a blockchain system, characterized in that, The method includes: The updated source code is determined, and the updated source code is compiled to obtain the executable code corresponding to the updated source code. The updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system. The executable code is a runtime library file or runtime library code. The updated source code and executable code are sent to each node in the blockchain system so that each node compiles the updated source code using the same compilation method. The compilation result is matched with the executable code. If the instructions corresponding to the two are the same, the executable code is determined to be verified. Based on the executable code, the node is updated and its status is updated synchronously during the node's operation. Determine the update status synchronization result of each node, and based on the update status synchronization result, determine that each node will perform a synchronized update for the updated source code.

2. The method according to claim 1, characterized in that, The updated source code includes at least one of the following: Pre-written initial code for updating the nodes in the blockchain system; The target application's library file code; Initial code compiled by any node in a blockchain system to update other nodes in the blockchain system.

3. The method according to claim 1, characterized in that, Sending the executable code to each node in the blockchain system includes at least one of the following: The executable code is sent to a target node in the blockchain system, so that the target node broadcasts 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 can obtain the executable code from that node through a consensus mechanism.

4. A node update method for a blockchain system, characterized in that, The method includes: Obtain updated source code and corresponding executable code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system; The updated source code is compiled using the same compilation method. The compilation result is matched with the executable code. If the instructions corresponding to the two are the same, the executable code is determined to be verified. Based on the executable code, the node is updated during the node's operation, and the status is updated synchronously with other nodes in the blockchain system. A first execution result is determined for the executable code. If the first execution result is consistent with the second execution result of other nodes in the blockchain system for the executable code, then the node update for the updated source code is determined to be complete.

5. The method according to claim 4, characterized in that, The method further includes: Determine a first identifier for the updated source code, wherein the first identifier includes at least one of a business identifier for the service corresponding to the updated source code or a function identifier for the corresponding function. The executable code is stored as historical executable code based on the first identifier.

6. The method according to claim 5, characterized in that, The method further includes at least one of the following: In response to a version query request for a first service or a first function, a target identifier corresponding to the first service or the first function is determined, and a version update record of the first service or the first function is determined based on at least one historical executable code corresponding to the target identifier; the first service is any service supported by the node, and the first function is any function supported by the node. The executable code is matched with each historical executable code. If the executable code is not included in any of the historical executable codes, then node updates are allowed based on the executable code.

7. The method according to claim 4, characterized in that, The node update based on the executable code during node operation includes: Obtain the updated source code, and perform a trusted verification on the executable code based on the updated source code; If the executable code passes verification, the node is updated during node operation based on the executable code.

8. A node update device for a blockchain system, characterized in that, The device includes: The code determination module is used to determine the updated source code, compile the updated source code to obtain the executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system; the executable code is a runtime library file or runtime library code. The code sending module is used to send the updated source code and executable code to each node in the blockchain system, so that each node compiles the updated source code in the same way, matches the compilation result with the executable code, and if the instructions corresponding to the two are the same, it is determined that the executable code has passed the verification. Based on the executable code, the node is updated and its status is updated synchronously during the node operation. The result determination module is used to determine the update status synchronization result of each node, and based on the update status synchronization result, determine that each node should perform a synchronized update for the updated source code.

9. A node update device for a blockchain system, characterized in that, The device includes: The code acquisition module is used to acquire updated source code and the executable code corresponding to the updated source code, wherein the updated source code corresponds to any programming language, and the executable code is bytecode in a preset format that supports direct execution by each node in the blockchain system. The node update module is used to compile the updated source code using the same compilation method, match the compilation result with the executable code, and if the instructions corresponding to the two are the same, it is determined that the executable code has passed the verification. Based on the executable code, the node is updated during the node's operation, and the status is updated synchronously with other nodes in the blockchain system. The information processing module is used to determine a first execution result for the executable code. If the first execution result is consistent with the second execution result of other nodes in the blockchain system for the executable code, then it is determined that the node update for the updated source code is completed.

10. An electronic device, characterized in that, It includes a processor and a memory, which are interconnected; The memory is used to store computer programs; The processor is configured to perform the method as described in any one 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 that 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, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the method described in any one of claims 1 to 7.

Images