Block chain network upgrading method and device, electronic equipment and storage medium

Abstract

The invention provides a block chain network upgrading method and device, electronic equipment and a storage medium. The method comprises the steps that a first contract calling request is used for triggering a block output mode of first main node equipment to be switched from an alternate block output mode to a continuous block output mode, and the block output duration of the continuous block output mode is larger than that of the alternate block output mode; sending a second call contract request to the block chain network, wherein the second call contract request is used for triggering the type of the to-be-upgraded slave node device to be switched from the consensus node device to the to-be-upgraded device; sending a third contract calling request to the block chain network, wherein the third contract calling request is used for triggering the to-be-upgraded device to perform version upgrading processing; and sending a fourth contract calling request to the block chain network, wherein the fourth contract calling request is used for triggering to recover the type of the upgraded slave node device to the consensus node device. According to the invention, the upgrading efficiency of the block chain network under the condition that the consensus messages are incompatible can be improved.

Description

Technical Field

[0001] The present application relates to blockchain technology, and in particular to an upgrade method, device, electronic device and storage medium for a blockchain network. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Essentially, blockchain is a decentralized database, a string of data blocks generated by using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity (anti-counterfeiting) of the information and generate the next block. Blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0003] With the development of blockchain technology, the blockchain network needs to be upgraded to meet different application scenarios. During the upgrade process of the blockchain network, if the consensus messages are incompatible and nodes of different versions cannot reach an agreement through the consensus messages, the system will not be able to generate blocks. For a blockchain network where messages between each version are incompatible, the entire blockchain network needs to be shut down for upgrading. On the one hand, the upgrade efficiency is not high, and on the other hand, the shutdown of the blockchain network affects the use of related business systems.

[0004] In the related art, there is no good way to improve the upgrade efficiency of the blockchain network in the case of incompatible consensus messages. Summary of the Invention

[0005] Embodiments of the present application provide an upgrade method, device, electronic device, computer-readable storage medium, and computer program product for a blockchain network, which can improve the upgrade efficiency of the blockchain network in the case of incompatible consensus messages.

[0006] The technical solution of the embodiments of the present application is implemented as follows:

[0007] Embodiments of the present application provide an upgrade method for a blockchain network. The blockchain network includes a plurality of master node devices and a plurality of slave node devices. The method includes:

[0008] Sending a first contract call request to the blockchain network, where the first contract call request is used to trigger the block generation mode of a first master node device to switch from a round-robin block generation mode to a continuous block generation mode, the block generation duration of the continuous block generation mode is greater than the block generation duration of the round-robin block generation mode, and the first master node device is one of the plurality of master node devices;

[0009] In response to receiving the first feedback information, send a second contract invocation request to the blockchain network, where the first feedback information indicates that the first master node device has successfully switched to the continuous block generation mode, and the second contract invocation request is used to trigger the type of the slave node device to be upgraded to switch from a consensus node device to a device to be upgraded;

[0010] In response to receiving the second feedback information, send a third contract invocation request to the blockchain network, where the second feedback information indicates that the type of the slave node device to be upgraded has switched to the device to be upgraded, and the third contract invocation request is used to trigger the device to be upgraded to perform version upgrade processing;

[0011] In response to receiving the third feedback information, send a fourth contract invocation request to the blockchain network, where the third feedback information indicates that the version upgrade processing of the device to be upgraded is completed, and the fourth contract invocation request is used to trigger the type of the upgraded slave node device to be restored to the consensus node device.

[0012] An embodiment of the present application provides an upgrade device for a blockchain network, where the blockchain network includes a plurality of master node devices and a plurality of slave node devices; the device includes:

[0013] A configuration module, configured to send a first contract invocation request to the blockchain network, where the first contract invocation request is used to trigger the block generation mode of the first master node device to switch from the round-robin block generation mode to the continuous block generation mode, and the block generation duration of the continuous block generation mode is greater than the block generation duration of the round-robin block generation mode, and the first master node device is one of the plurality of master node devices;

[0014] The configuration module is further configured to, in response to receiving the first feedback information, send a second contract invocation request to the blockchain network, where the first feedback information indicates that the first master node device has successfully switched to the continuous block generation mode, and the second contract invocation request is used to trigger the type of the slave node device to be upgraded to switch from a consensus node device to a device to be upgraded;

[0015] An upgrade module, configured to, in response to receiving the second feedback information, send a third contract invocation request to the blockchain network, where the second feedback information indicates that the type of the slave node device to be upgraded has switched to the device to be upgraded, and the third contract invocation request is used to trigger the device to be upgraded to perform version upgrade processing;

[0016] The upgrade module is further configured to send a fourth contract call request to the blockchain network in response to receiving third feedback information, where the third feedback information indicates that the version upgrade process of the device to be upgraded is completed, and the fourth contract call request is used to trigger the restoration of the type of the upgraded slave node device to the consensus node device.

[0017] An embodiment of the present application provides an electronic device, which includes:

[0018] A memory for storing computer-executable instructions;

[0019] A processor, when executing the computer-executable instructions stored in the memory, implements the blockchain network upgrade method provided by the embodiment of the present application.

[0020] An embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the blockchain network upgrade method provided by the embodiment of the present application when executed by a processor.

[0021] An embodiment of the present application provides a computer program product, including a computer program or computer-executable instructions, which implement the blockchain network upgrade method provided by the embodiment of the present application when executed by a processor.

[0022] The embodiment of the present application has the following beneficial effects:

[0023] Before performing the upgrade process for the slave node device, a contract call instruction is sent to configure the block production mode of the master node device in the blockchain network, and when the configuration is successful, the version upgrade process of the slave node device is executed, so that the block production duration of the master node device is delayed, which can reserve time to execute the version upgrade process of the slave node device, and can upgrade the node device when the consensus messages are incompatible, ensuring that the blockchain network will not fail to reach a consensus due to incompatible consensus messages, and improving the smoothness of the upgrade process. During the upgrade process, compared with the solution of shutting down the entire blockchain network in the related art, it is not necessary to shut down most of the node devices, improving the efficiency of the upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a schematic structural diagram of the blockchain network provided by the embodiment of the present application;

[0025] Figure 2A is an optional schematic diagram of the block structure provided by the embodiment of the present application

[0026] Figure 2B is a schematic functional architecture diagram of the blockchain network 200 provided by the embodiment of the present application;

[0027] Figure 2C It is a schematic diagram of an application scenario of the blockchain network upgrade method provided by an embodiment of this application;

[0028] Figure 2D It is a schematic diagram of the structure of an electronic device provided by an embodiment of this application;

[0029] Figures 3A to 3B It is a schematic flowchart of the blockchain network upgrade method provided by an embodiment of this application;

[0030] Figure 4 It is an interaction schematic diagram of the blockchain network upgrade method provided by an embodiment of this application;

[0031] Figure 5 It is a schematic diagram of the structure of a node upgrade server provided by an embodiment of this application;

[0032] Figures 6A to 6E It is an interaction schematic diagram of the blockchain network upgrade method provided by an embodiment of this application. Detailed implementation manners

[0033] In order to make the objectives, technical solutions, and advantages of this application clearer, the following will further describe this application in detail with reference to the accompanying drawings. The described embodiments should not be regarded as limitations of this application. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0034] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments. However, it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0035] In the following description, the terms "first / second / third" involved are only used to distinguish similar objects and do not represent a specific order for the objects. It can be understood that "first / second / third" can be interchanged with a specific order or sequence when allowed, so that the embodiments of this application described here can be implemented in an order other than that illustrated or described here.

[0036] It should be noted that the relevant data collection and processing in this application (for example: data collection for node devices) should strictly comply with the requirements of relevant national laws and regulations during actual application, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing behaviors within the scope of authorization of laws and regulations and the personal information subject.

[0037] In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the function of the module or unit.

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0039] Before further elaborating on the embodiments of this application, the nouns and terms involved in the embodiments of this application are described. The nouns and terms involved in the embodiments of this application are subject to the following explanations.

[0040] 1) Blockchain network: A system formed by connecting multiple nodes through network communication; the blockchain network can also include clients. The specific content of the messages in the blockchain network varies according to the actual business scenario. For example, the messages can be message records, instructions for the state machines of the nodes to execute, etc.

[0041] 2) Node: A term in a computer network, referring to a connection point or intersection point in the network. It is a device or data structure in a network used to transmit, receive, or forward data streams in the network. A node can be a physical device, such as a computer, a network switch, or a router, or a virtual device, such as a virtual machine or a cloud server.

[0042] 3) Consensus: In a blockchain network, nodes verify the correctness of the messages sent by other nodes. If the verification is successful, they send an acknowledgment to the node that sent the message and persistently store the message for supporting subsequent message queries. The mechanisms for achieving consensus include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof-of-Stake (DpoS), Proof of Elapsed Time (PoET), etc.

[0043] 4) Master Node: A role of consensus nodes in the blockchain. Consensus nodes are the key to maintaining data consistency across the entire blockchain network. The main function of the master node is to package transactions and construct blocks during a round of consensus and broadcast the blocks to other slave nodes. The master node plays a crucial role in a round of consensus. If the master node behaves maliciously, crashes, packages invalid transactions, or has errors in the block structure, no consensus will be reached on any block in this round of consensus.

[0044] 5) Slave Node: A role of consensus nodes in the blockchain. Its main function is to verify the validity of the block and execute the transactions after receiving the block proposed by the master node. When the block is verified as invalid or the transaction execution results are inconsistent, the slave node will not vote for or against the block. When the block is verified as valid and the transaction execution results are consistent, the slave node will vote for the block.

[0045] 6) Node State Detection Smart Contract (NSC): A system contract deployed in the blockchain network. The internal logic of the node state detection smart contract is to return the running state of the node and the identity information of the node. The identity information of the node includes the node identifier (ID), the running time of the node, the consensus state information of the node, whether the current node is a consensus node, whether the current node is a master node or a slave node, etc.

[0046] 7) Consensus State Information: Information generated by the node device to represent the current consensus state of the node device. The consensus state information includes the following parameters: proposal hash code (hash), the current consensus stage of the node device, the consensus height (block height), and the vote set composed of the votes received by the node device.

[0047] 8) Configuration Management Smart Contract (CMC): A system contract deployed in the blockchain network. The internal logic of the configuration management smart contract is to modify the chain configuration, specifically including: modifying the number of consecutive blocks produced by the master node, changing a synchronization node to a consensus node, changing a consensus node to a synchronization node, etc. The functions in the configuration management smart contract are crucial when consensus messages are incompatible.

[0048] 9) Node Upgrade Smart Contract (NUC): A system contract in the blockchain, whose role is to adjust the version number in the blockchain. For example, adjusting the node device from version v1 to version v2. After the adjustment, the blockchain network will run different code logics according to different versions.

[0049] 10) Node upgrade: That is, the update of node devices, including the following types: ordinary service suspension upgrade, non-service suspension upgrade, non-service suspension message compatibility upgrade, non-service suspension message incompatibility upgrade, etc.

[0050] 11) Remote Procedure Call Protocol (RPC) service: It is a modern open-source high-performance remote procedure call framework that can run in any environment. It can efficiently connect services within and across data centers, support load balancing, real-time detection, health checks, and authentication. It is also applicable to the last mile of distributed computing, connecting devices, mobile applications, and browsers to backend services.

[0051] 12) Mirroring: It is a form of file storage and a type of redundancy. A complete identical copy of the data on one disk exists on another disk, which is called mirroring.

[0052] In related technologies, the blockchain network adapts to different application scenarios by upgrading node devices. For blockchain networks where messages are compatible, users often need to manually upgrade each node one by one. The upgrade process is cumbersome and troublesome, which is not conducive to operation. Manual execution makes the upgrade process more uncertain and prone to upgrade errors. For blockchain networks where messages are not compatible between each version, the entire blockchain network is shut down during the upgrade process. In this way, the use of the user's business system will be affected. In related technologies, the upgrade efficiency of the blockchain network is not high.

[0053] The embodiments of the present application provide a method for upgrading a blockchain network, an apparatus for upgrading a blockchain network, an electronic device, a computer-readable storage medium, and a computer program product, which can improve the upgrade efficiency of the blockchain network in the case of incompatible consensus messages.

[0054] See Figure 1 , Figure 1 is a schematic structural diagram of the blockchain network provided by the embodiments of the present application. The blockchain network 200 is formed by multiple nodes 210 (any form of computing device connected to the network, such as a server, a user terminal) and a client 300. A peer-to-peer network is formed among the nodes 210. The peer-to-peer network protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP).

[0055] See Figure 1 shows the functions of each node 210 in the blockchain network, and the functions involved include:

[0056] 1) Routing, which is a basic function of the node and is used to support communication between nodes.

[0057] In addition to the routing function, the node may also have the following functions:

[0058] 2) An application, which is used to be deployed in the blockchain, implement specific services according to actual business requirements, record messages related to the implemented functions, carry a digital signature in the messages to indicate the source, and send the messages to other nodes in the blockchain network. When other nodes verify the source and integrity of the messages successfully, the messages are added to the temporary block.

[0059] For example, the services implemented by the application include:

[0060] 2.1) A shared ledger, which is used to provide functions such as storage, query, and modification of messages (carrying data), send messages of operations on the messages to other nodes in the blockchain network. After other nodes verify the effectiveness, as a response to acknowledging the effectiveness of the messages, the messages are stored in the temporary block, and confirmation can also be sent to the node that initiates the operation.

[0061] 2.2) A smart contract, which is a computerized protocol that can execute the terms of a certain contract. It is implemented through code deployed on the shared ledger and used to execute under certain conditions. According to actual business requirements, the code is used to complete automated message processing. For example, query the logistics status of the goods purchased by the buyer, and transfer the buyer's payment to the merchant's account after the buyer signs for the goods.

[0062] 3) The blockchain includes a series of blocks (Blocks) that are sequentially connected in the order of generation. Once a new block is added to the blockchain, it will not be removed again. The block records the messages submitted by the nodes in the blockchain network.

[0063] See Figure 2A , Figure 2A which is an optional schematic diagram of the block structure provided by the embodiment of the present application. Each block includes the hash value of the message record stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through the hash values to form the blockchain. In addition, the block may also include information such as the timestamp when the block is generated.

[0064] The following describes the exemplary functional architecture of the blockchain network provided by the embodiment of the present application. See Figure 2B , Figure 2B which is a schematic diagram of the functional architecture of the blockchain network 200 provided by the embodiment of the present application, including an application layer 201, a consensus layer 202, a network layer 203, a data layer 204, and a resource layer 205. The following will be described separately.

[0065] The resource layer 205 encapsulates the computing resources, storage resources, and communication resources of each node 210 in the blockchain network 200, such as the computing resources, storage resources, and communication resources in computers, servers / clusters, and clouds, abstracts them, and provides a unified interface to the data layer 204 to shield the differences in the underlying hardware implementing the resource layer 205.

[0066] The computing resources include various forms of processors, such as central processing units (CPUs), application-specific integrated circuits (ASICs), application-specific integrated circuits, and various forms of processors of field-programmable gate arrays (FPGAs).

[0067] The storage resources include various types of storage media such as various volatile memories and non-volatile memories. The communication resources include various links for communication between the nodes 210 of the blockchain network, between the blockchain network 200 and business entities.

[0068] The data layer 204 encapsulates various data structures for implementing the ledger, including the blockchain implemented as files in the file system, the key-value type state database, and the proof of existence.

[0069] The network layer 203 encapsulates the functions of the peer-to-peer network protocol, data propagation mechanism, data verification mechanism, access authentication mechanism, and business entity identity management.

[0070] Among them, the peer-to-peer network protocol realizes the communication between the nodes 210 in the blockchain network 200, the data propagation mechanism ensures the propagation of messages in the blockchain network 200, and the data verification mechanism is used to realize the reliability of the data transmitted between the nodes 210 based on cryptographic methods (such as digital certificates, digital signatures, public / private key pairs); the access authentication mechanism is used to authenticate the identity of the business entity joining the blockchain network 200 according to the actual business scenario and grant the business entity the permission to access the blockchain network 200 when the authentication is passed; the business entity identity management is used to store the identities of the business entities allowed to access the blockchain network 200 and their permissions (such as the types of messages that can be initiated).

[0071] The consensus layer 202 encapsulates the mechanism for the nodes 210 in the blockchain network 200 to reach consensus on the blocks (i.e., the consensus mechanism), and the functions of message management and ledger management.

[0072] The consensus mechanism includes consensus algorithms such as POS, POW, and DPOS, and supports the pluggability of the consensus algorithms.

[0073] Message management is used to verify the digital signature carried in the message received by node 210, verify the identity information of the business entity, and determine whether it has the permission to send messages based on the identity information (reading relevant information from the business entity identity management); for business entities authorized to access the blockchain network 200, they all have digital certificates issued by the certification center. The business entity uses the private key in its own digital certificate to sign the submitted message, thereby declaring its legal identity.

[0074] Ledger management: used to maintain the blockchain and the state database. For the blocks that reach consensus, append them to the end of the blockchain; execute the messages in the blocks that reach consensus. When the message includes an update operation, update the key-value pairs in the state database. When the message includes a query operation, query the key-value pairs in the state database and return the query result to the business entity. Support various dimensions of query operations on the state database, including: querying blocks according to the block sequence number (such as the hash value of the message); querying blocks according to the block hash value; querying blocks according to the message sequence number; querying messages according to the message sequence number; querying the account data of the business entity according to the account (sequence number) of the business entity; querying the blockchain in the channel according to the channel name.

[0075] The application layer 201 encapsulates various services that the blockchain network can implement, including message traceability, evidence storage, and verification, etc.

[0076] In some embodiments, the node device can be a server. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The electronic device can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto. The terminal device and the server can be directly or indirectly connected through wired or wireless communication methods, which are not limited in the embodiments of the present invention.

[0077] The following describes the exemplary applications of the electronic device provided in the embodiments of the present application. The electronic device provided in the embodiments of the present application can be implemented as a terminal device, such as various types of user terminals such as a laptop computer, a tablet computer, a desktop computer, a set-top box, a smart TV, a mobile device (for example, a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, a portable gaming device), a vehicle-mounted terminal, a virtual reality (VR, Virtual Reality) device, an augmented reality (AR, Augmented Reality) device, etc., or can also be implemented as a server. The following will describe the exemplary applications when the electronic device is implemented as a terminal device or a server.

[0078] Reference Figure 2C , Figure 2C is a schematic diagram of an application scenario of the blockchain network upgrade method provided by the embodiments of the present application; Figure 2C involves a blockchain network 200 (simplified compared to Figure 1 ), and a server 400. The server 400 is connected to the blockchain network 200 through a network. The blockchain network 200 includes multiple node devices, such as: node device 1, node device 2... node device N, where N is a positive integer.

[0079] The server 400 is a server independent of the blockchain network 200 and can run an upgrade service for managing the version upgrade of the blockchain network. The server 400 sends a first call contract request to the blockchain network to cause the primary node device in the blockchain network 200 to switch to the continuous block generation mode. After the primary node device is successfully configured to the continuous block generation mode, the blockchain network 200 sends a first feedback message to the server 400 to enable the server 400 to determine the node devices to be upgraded and determine that the primary node device is successfully configured to the continuous block generation mode.

[0080] The server 400 sends a second call contract request to trigger the node type of the slave node device to be upgraded to switch from a consensus node to a node to be upgraded, and perform version upgrade processing on the node to be upgraded. After the version upgrade processing of the slave node device, its type is restored to a consensus node. The blockchain network 200 sends the upgrade process and the feedback message after the upgrade is completed to the server 400. The server 400 is independent of the blockchain network 200. During the upgrade process of the blockchain network 200, there is no need to perform a shutdown process on the entire blockchain network 200.

[0081] The embodiments of the present application can be implemented through database technology. A database, in short, can be regarded as a place for storing electronic files in an electronic filing cabinet. Users can perform operations such as adding, querying, updating, and deleting data in the files. The so-called "database" is a data set stored together in a certain way, shared by multiple users, having the smallest possible redundancy, and independent of application programs.

[0082] A database management system (DBMS) is a computer software system designed to manage databases and generally has basic functions such as storage, retrieval, security, backup, etc. Database management systems can be classified according to the database models they support, such as relational, XML (Extensible Markup Language); or according to the types of computers they support, such as server clusters, mobile phones; or according to the query languages they use, such as Structured Query Language (SQL), XQuery; or according to the key performance metrics, such as maximum scale, highest running speed; or other classification methods. Regardless of the classification method used, some DBMSs can span categories. For example, they can support multiple query languages simultaneously.

[0083] Embodiments of this application can also be implemented through cloud technology. Cloud technology is the general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool and be used on demand, being flexible and convenient. Cloud computing technology will become an important support. The back-end services of technical network systems require a large amount of computing and storage resources, such as video websites, picture websites, and more portal websites. With the highly developed application of the Internet industry and the promotion of demands such as search services, social networks, mobile commerce, and open collaboration, in the future, each item may have its own hash code identification mark and needs to be transmitted to the back-end system for logical processing. Data at different levels will be processed separately, and various types of industry data require a powerful system back-end support, which can only be achieved through cloud computing.

[0084] In some embodiments, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms. The electronic device can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto. The terminal device and the server can be directly or indirectly connected through wired or wireless communication methods, and there is no limitation in the embodiments of this application.

[0085] See Figure 2D , Figure 2D is a schematic structural diagram of the electronic device provided by the embodiments of this application. The electronic device can be the server 400. Figure 2DThe server 400 shown includes: at least one processor 410, a memory 450, and at least one network interface 420. Each component in the server 400 is coupled together through a bus system 440. It can be understood that the bus system 440 is used to implement the connection and communication between these components. In addition to the data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clear illustration, in Figure 2D all kinds of buses are labeled as the bus system 440.

[0086] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0087] The memory 450 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disc drives, etc. The memory 450 optionally includes one or more storage devices that are physically located far from the processor 410.

[0088] The memory 450 includes volatile memory or non-volatile memory, and can also include both volatile and non-volatile memory. The non-volatile memory can be a read-only memory (ROM, Read Only Memory), and the volatile memory can be a random access memory (RAM, Random Access Memory). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0089] In some embodiments, the memory 450 is capable of storing data to support various operations. Examples of such data include programs, modules, and data structures, or subsets or supersets thereof, which are illustrated below.

[0090] An operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0091] A network communication module 452, for reaching other electronic devices via one or more (wired or wireless) network interfaces 420. Exemplary network interfaces 420 include: Bluetooth, Wi-Fi (Wireless Fidelity), and USB (Universal Serial Bus), etc.;

[0092] In some embodiments, the apparatus provided by the embodiments of the present application may be implemented in software. Figure 2D Fig. Figure 2D shows an upgrade apparatus 455 of a blockchain network stored in a memory 450, which may be software in the form of a program and a plug-in, etc., including the following software modules: a detection module 4551, a configuration module 4552, and an upgrade module 4553. These modules are logical, so they can be combined arbitrarily or further split according to the functions implemented. In Figure 2D For the convenience of expression, all the above modules are shown at once, but it should not be considered that the upgrade apparatus 455 of the blockchain network excludes the implementation that may only include the configuration module 4552 and the upgrade module 4553. The functions of each module will be described below.

[0093] The upgrade method of the blockchain network provided by the embodiments of the present application will be described in combination with the exemplary applications and implementations of the terminal device provided by the embodiments of the present application.

[0094] Next, the upgrade method of the blockchain network provided by the embodiments of the present application will be described. As before, the electronic device for implementing the upgrade method of the blockchain network of the embodiments of the present application may be the above-mentioned server. Therefore, the execution subject of each step will not be repeated hereinafter.

[0095] Refer to Figure 3A Figure 3A Fig. Figure 3A is a schematic flowchart of the upgrade method of the blockchain network provided by the embodiments of the present application, which will be described in combination with the steps shown in Figure 3A Fig. Figure 3A .

[0096] In step 301, a first contract call request is sent to the blockchain network.

[0097] Here, the first contract call request is used to trigger the block production mode of the primary node device to switch from the round-robin block production mode to the continuous block production mode, and the block production duration of the continuous block production mode is greater than the block production duration of the round-robin block production mode.

[0098] Exemplarily, in blockchain technology, the server sending a request to the blockchain network means that the server initiates a transaction to the blockchain network. A two-way node transaction means that in the blockchain network, a node can be both a transaction sender (sending node) and a transaction receiver (receiving node). The first contract call request is used to request a first smart contract, and the contract is a logical program inside the blockchain network.

[0099] The first smart contract may be a configuration management system contract (CMC). The logical functions of the configuration management system contract include: modifying the number of consecutive blocks produced by the primary node device, changing the node type of the primary node device or the secondary node device. The request information carried by the first contract call request is used to call the configuration management system contract of the blockchain network to execute the process of changing the continuous block production mode of the primary node device.

[0100] Exemplarily, in the round-robin block generation mode, the master node device performs block generation processing in turn. In the continuous block generation mode, the duration for a single master node device to continuously perform block generation processing is longer than that in the round-robin block generation mode.

[0101] In some embodiments, the continuous block generation mode includes: the first master node device continuously performs block generation processing. When the number of blocks continuously generated by the first master node device reaches a pre-configured number, the second master node device performs block generation processing. The second master node device is one of the multiple master node devices and is different from the first master node device.

[0102] For example: Assume that in the round-robin block generation mode, the maximum number of continuously generated blocks for each master node device during each block generation processing is N, and in the continuous block generation mode, the maximum number of continuously generated blocks (pre-configured number) for each master node device during each block generation processing is M, and the order of magnitude of M is greater than N. For example: M is 1000 and N is 100.

[0103] In some embodiments, the continuous block generation mode includes: the first master node device continuously performs block generation processing. When the duration for the first master node device to perform block generation processing reaches a pre-configured duration, the second master node device performs block generation processing. The second master node device is one of the multiple master node devices and is different from the first master node device.

[0104] For example: Assume that in the round-robin block generation mode, the maximum number of continuously generated blocks for each master node device during each block generation processing is N, and the maximum consumed duration is Y. In the continuous block generation mode, the maximum duration (pre-configured duration) for each master node device during each block generation processing is X, and the order of magnitude of X is greater than Y.

[0105] In the embodiments of the present application, before upgrading the nodes in the blockchain network, the block generation mode of the master node is configured, and the block generation duration of the master node is extended to provide sufficient time for the slave node devices to be upgraded, so that the slave node devices can be upgraded under the condition of consensus incompatibility, improving the smoothness of the blockchain network upgrade, and enabling the blockchain network to complete the upgrade without stopping the service.

[0106] In some embodiments, refer to Figure 3B , Figure 3B is a schematic flowchart of the method for upgrading the blockchain network provided by the embodiments of the present application. Before step 301 in Figure 3A , by executing Figure 3B steps 305 and 307 in, the node devices in the blockchain network and the information of the node devices are determined, which is specifically described below.

[0107] In step 305, a fifth contract call request is sent to the blockchain network.

[0108] Here, the fifth call contract request is used to obtain the identity information and consensus status information of each node device in the blockchain network. The identity information includes: the node device identifier and the node device type, and the consensus status information at least includes the consensus height.

[0109] Exemplarily, through the fifth call contract request, the fifth smart contract is called. The fifth smart contract can be the node status detection system contract (NSC) of the blockchain network. The logical functions of the node status detection system contract include: obtaining the running status and identity information of each node in the blockchain network, including the node identifier (ID), the node running time, and the consensus status of the node, and detecting the status of each consensus node.

[0110] In step 306, in response to receiving the identity information and the consensus status information, the slave node device to be upgraded is determined according to the identity information and the consensus status information.

[0111] Exemplarily, according to the identity information, it can be distinguished whether the node device is a master node device or a slave node device. According to the consensus status information, the slave node device to be upgraded can be judged.

[0112] In some embodiments, step 306 can be implemented in the following manner: determining multiple surviving slave node devices among the multiple node devices according to the identity information; determining the surviving slave node devices with the same consensus height among the multiple surviving slave node devices; comparing the version numbers of each surviving slave node device with the same consensus height to obtain a comparison result; in response to the comparison result corresponding to the surviving slave node device being that the version number is less than the latest version number, taking the surviving slave node device as the slave node device to be upgraded.

[0113] Exemplarily, the server sequentially performs the following processes: judging whether each node is alive, obtaining the consensus height of each surviving node, and judging whether each node with the same consensus height has reached the current version. If the node device is not a surviving node device, there is no need to execute the subsequent judgment process, reducing the computing resources required to determine the slave node device to be upgraded.

[0114] In step 307, a first master node device is determined from among the multiple master node devices.

[0115] Continue to refer to Figure 3A , in step 302, in response to receiving the first feedback information, a second call contract request is sent to the blockchain network.

[0116] Here, the first feedback information indicates that the first master node device has successfully switched to the continuous block production mode, and the second call contract request is used to trigger the type of the slave node device to be upgraded to switch from the consensus node device to the device to be upgraded.

[0117] Exemplarily, the second call contract request is used to request a second smart contract, which can be a node management smart contract (NMC). The logical functions of the node management smart contract include: performing configuration operations on individual node devices. For example: modifying the attribute value of the type of the slave node device to the device to be upgraded.

[0118] Exemplarily, if the server does not receive the first feedback information fed back by the blockchain network, the current processing is stopped until the first feedback information is received. If the information fed back by the blockchain network indicates a failure in the switch, the upgrade process is ended.

[0119] In step 303, in response to receiving the second feedback information, a third call contract request is sent to the blockchain network.

[0120] Here, the second feedback information indicates that the type of the slave node device to be upgraded has been switched to the device to be upgraded, and the third call contract request is used to trigger the device to be upgraded to perform version upgrade processing.

[0121] Exemplarily, the third call contract request is used to request a third smart contract, which can be a node upgrade smart contract (NUC). The logical functions of the node actual contract include: adjusting the version number in the blockchain. The node upgrade can be performed on the programs, data, and network protocols of the node device.

[0122] In some embodiments, before the device to be upgraded performs version upgrade processing, upgrade data corresponding to the latest version number is sent to the device to be upgraded; the third call contract request is used to trigger the device to be upgraded to perform version upgrade processing in the following manner: replacing the image data of the device to be upgraded based on the upgrade data; controlling the device to be upgraded to stop running, and controlling the stopped device to be upgraded to perform a restart operation; in response to the completion of the restart of the device to be upgraded, replacing the version number of the device to be upgraded with the latest version number.

[0123] Exemplarily, before the device to be upgraded performs version upgrade processing, the server sends the upgrade data of the latest version required for the upgrade to the blockchain network. Completing the replacement of data and restarting indicates that the device to be upgraded has been upgraded, and the version number is updated to indicate that the device to be upgraded has been upgraded. During the upgrade processing of the device to be upgraded, other slave node devices continue to perform consensus processing.

[0124] In some embodiments, the number of devices to be upgraded that perform version upgrade processing simultaneously is at least one. When the device to be upgraded performs version upgrade processing, the consensus function of the slave node device of the consensus node device type remains in the running state.

[0125] For example, if the server does not receive the second feedback information fed back by the blockchain network, the current process is stopped until the second feedback information is received. If the information fed back by the blockchain network indicates a failure in the switch, the upgrade process is ended.

[0126] In the embodiments of the present application, in the case where the consensus of the blockchain is incompatible and the blockchain network does not shut down, at least some of the slave node devices in the blockchain network are supported to perform upgrade processing, and the consensus processing of other node devices that do not participate in the upgrade processing is not affected, improving the smoothness of the blockchain network upgrade and avoiding the lag of business services provided by the blockchain network due to downtime.

[0127] In step 304, in response to receiving the third feedback information, a fourth contract call request is sent to the blockchain network.

[0128] Here, the third feedback information indicates that the version upgrade processing of the device to be upgraded is completed, and the fourth contract call request is used to trigger the restoration of the type of the upgraded slave node device to a consensus node device.

[0129] For example, the fourth contract call request is used to request a fourth smart contract, and the fourth smart contract may be a node management smart contract (NMC). The logical functions of the node management smart contract include: performing configuration operations on individual node devices. For example: modifying the attribute value of the type of the slave node device to a consensus node device.

[0130] For example, the numbers such as "first", "second", etc. in the first smart contract, the second smart contract, the third smart contract, and the fourth smart contract are only used to distinguish the specific functions of the contracts called in different situations. In fact, the contracts called may be of the same type of contract. For example: The second smart contract and the fourth smart contract refer to different functions of the same type of contract (node management smart contract).

[0131] For example, if the server does not receive the third feedback information fed back by the blockchain network, the current process is stopped until the third feedback information is received. If the information fed back by the blockchain network indicates a failure in the upgrade, the upgrade process is ended.

[0132] In some embodiments, after restoring the type of the upgraded slave node device to a consensus node device, in response to receiving the fourth feedback information fed back by the blockchain network, a second contract call request is sent to the blockchain network, where the fourth feedback information indicates that the type of the upgraded slave node device has been restored to a consensus node device; in response to receiving the fifth feedback information, the second contract call request sent to the blockchain network is stopped, where the fifth feedback information indicates that all the slave node devices have been upgraded.

[0133] For example, when the type of the upgraded slave node device has been restored to the consensus node device, by sending a second contract call request, the blockchain network performs an upgrade process on the remaining un-upgraded node devices in a loop until all devices in the blockchain network are upgraded.

[0134] For example, if the server does not receive the fourth feedback information fed back by the blockchain network, the current process is stopped until the fourth feedback information is received. If the information fed back by the blockchain network indicates that the type of the slave node device has not been restored to the consensus node, the fourth contract call request is re-sent to restore the type of the slave node device. If all slave node devices in the blockchain network have been upgraded, the entire upgrade process ends.

[0135] In some embodiments, in response to receiving the fifth feedback information, a sixth contract call request is sent to the blockchain network, where the sixth contract call request is used to trigger the block generation mode of the first primary node device in the blockchain network to be restored to the round-robin block generation mode.

[0136] For example, the sixth contract call request is used to call the configuration management system contract, and by modifying the chain configuration, the continuous block generation quantity of the primary node is changed to switch the block generation mode of the primary node device. After the upgrade is completed, the block generation mode is restored to the round-robin block generation mode to restore the efficiency of the blockchain network in generating blocks.

[0137] In some embodiments, in response to receiving the third feedback information fed back by the blockchain network, a seventh contract call request is sent to the blockchain network, where the seventh contract call request is used to trigger the upgraded slave node device to clean up the redundant data of the previous version.

[0138] For example, the seventh contract call request is used to call the node management smart contract. The logical functions of the node management smart contract include: cleaning up the data of the previous version that is not required by the slave node device in the current version. After the node upgrade is completed, the data of the historical version is cleaned up to relieve the memory space pressure of the node device and improve the consensus processing efficiency.

[0139] In some embodiments, in response to receiving the third feedback information, a fifth contract call request is sent to the blockchain network, where the fifth contract call request is used to obtain the identity information and consensus status information of each node device in the blockchain network. In response to receiving the identity information and consensus status information, the working status of the upgraded slave node device is determined according to the identity information and consensus status information; in response to the working status of the upgraded slave node device being a fault status, an eighth contract call request is sent to the blockchain network, where the eighth contract call request is used to trigger the upgraded slave node device to restart.

[0140] Exemplarily, the function of the fifth call contract request has been described above and will not be elaborated here.

[0141] In the actual application process, after the slave node device is upgraded, if there is a fault in the data of the upgraded version, the upgraded slave node device may become a dead node. A dead node refers to a node device in a fault state, such as a crash, network connection interruption, etc. By sending a call contract request to the blockchain network, the call node management smart contract is triggered to restart the upgraded slave node device so that the dead node resumes operation. If the restarted slave node device is still in a fault state, the call node management smart contract controls the upgraded slave node device to be restored to the previous version and upgraded again to avoid faults.

[0142] Reference Figure 4 , Figure 4 is an interaction schematic diagram of the blockchain network upgrade method provided by the embodiments of the present application. Figure 4 Involve Figure 2C the blockchain network 200 and the server 400 in

[0143] The server 400 executes step S401 to send a first call contract request to the blockchain network 200.

[0144] The blockchain network 200 executes step S402 to receive the first call contract request and execute the first smart contract so that the block production mode of the master node device switches from the round-robin block production mode to the continuous block production mode.

[0145] Exemplarily, the first smart contract can be a configuration management system contract (CMC), and the logical function of the configuration management system contract includes: modifying the continuous block production number of the master node device.

[0146] The blockchain network 200 executes step S403 to send a first feedback message to the server 400.

[0147] The server 400 executes step S404. In response to receiving the first feedback message, the server sends a second call contract request to the blockchain network.

[0148] The blockchain network 200 executes step S405 to receive the second call contract request and execute the second smart contract so that the type of the slave node device to be upgraded switches from the consensus node device to the device to be upgraded.

[0149] Exemplarily, the second smart contract can be a node management smart contract (NMC), and the logical function of the node management smart contract includes: modifying the attribute value of the type of the slave node device to the device to be upgraded.

[0150] The blockchain network 200 executes step S406 to send a second feedback message to the server 400.

[0151] The server 400 executes step S407, and in response to receiving the second feedback information, sends a third contract call request to the blockchain network.

[0152] The blockchain network 200 executes step S408, receives the third contract call request, and executes the third smart contract to perform a version upgrade process on the device to be upgraded.

[0153] Exemplarily, the third smart contract may be a node upgrade smart contract (NUC), and the logical functions of the node actual contract include: adjusting the version number in the blockchain.

[0154] The blockchain network 200 executes step S409 and sends third feedback information to the server 400.

[0155] The server 400 executes step S410, and in response to receiving the third feedback information, sends a fourth contract call request to the blockchain network.

[0156] The blockchain network 200 executes step S411, receives the fourth contract call request, and executes the fourth smart contract to restore the type of the upgraded slave node device to a consensus node device.

[0157] Exemplarily, the fourth smart contract may be a node management smart contract (NMC), and the logical functions of the node management smart contract include: modifying the attribute value of the type of the slave node device to a consensus node device.

[0158] Figure 4 The principles of steps S401 to S411 can be referred to Figure 3A Steps 301 to 304 in

[0159] In the embodiments of the present application, before performing the upgrade process for the slave node device, a contract call instruction is sent to configure the block generation mode of the master node device in the blockchain network, and in the case of successful configuration, the version upgrade process of the slave node device is executed, so that the block generation duration of the master node device is delayed, which can reserve time to execute the version upgrade process of the slave node device, and can upgrade the node device when the consensus messages are incompatible, ensuring that the blockchain network will not fail to reach a consensus due to incompatible consensus messages, and improving the smoothness of the upgrade process. During the upgrade process, compared with the solution of shutting down the entire blockchain network in the related art, it is not necessary to shut down most of the node devices, improving the efficiency of the upgrade process.

[0160] Next, an exemplary application of the blockchain network upgrade method in the embodiments of the present application in an actual application scenario will be described.

[0161] In related technologies, blockchain technology has been widely applied and implemented in financial securities, evidence retention, traceability of agricultural products, and cross-departmental communication among relevant departments. With the large-scale application of blockchain, the existing blockchain technology can no longer fully meet the current new requirements, and there is a need to upgrade the blockchain.

[0162] For application parties, there is a strong need to upgrade the blockchain network, and it is required that the service can be continuously provided during the upgrade process without interruption, and the upgrade process can continuously provide services to users without affecting the online business and user experience of users. When upgrading, it is divided into minor version upgrades and major version upgrades. During minor version upgrades, there is usually no problem of message incompatibility between different minor versions. When the messages between each minor version are compatible, it is relatively simple to achieve non-stop service upgrades, and only the slave nodes need to be upgraded sequentially. When performing major version upgrades, there are often problems of message incompatibility between major versions, and the incompatibility of consensus messages is the biggest problem faced during the upgrade of blockchain nodes. Because consensus is the core process of blockchain, if the consensus messages are incompatible, nodes of different versions cannot reach an agreement through consensus messages, which will cause the system to be unable to generate blocks.

[0163] Currently, some blockchain networks can achieve compatibility of information between each version, while some blockchain networks cannot achieve compatibility of messages between each version. For blockchain networks where messages are compatible, users often need to manually upgrade each node sequentially, and the upgrade process is cumbersome and inconvenient for operation. Manual execution increases the uncertainty of the upgrade process and is prone to upgrade errors. For blockchain networks where messages are not compatible between each version, the entire blockchain network needs to be shut down. After the node devices in the blockchain network are replaced with the overall mirror image, they are restarted for upgrade. During the upgrade shutdown process, services cannot be provided, which will affect the use of the user's business system. When performing a major version upgrade, if there is an incompatibility of consensus messages, users need to stop all consensus nodes before upgrading the nodes, and at this time, the system will not be able to continue to provide services externally.

[0164] To solve the above problems, the upgrade method of the blockchain network provided in the embodiments of the present application creates a modular upgrade service. This upgrade service can upgrade nodes when consensus messages are incompatible, ensuring that the blockchain network can still reach a consensus without being unable to do so due to incompatible consensus messages. It can achieve non-stop service upgrades, and the upgrade process does not require all blockchain nodes to be stopped. Such an upgrade process will ensure the security and system robustness during the upgrade process, and at the same time, it can continuously provide services externally.

[0165] The upgrade method of the blockchain network provided in the embodiments of the present application can be implemented through a server. Refer to Figure 5 , Figure 5 which is a schematic structural diagram of the node upgrade server provided in the embodiments of the present application.Figure 5 The node upgrade server 500 is Figure 2D an implementation of the server 400 in

[0166] The node upgrade server 500 is a separate server, which can be a cloud server or a physical server. The node upgrade server 500 includes: a service management module 510, a chain request management module 520, and a basic component module 530.

[0167] The service management module 510 includes a Remote Procedure Call Protocol (RPC) module 512 and a Hypertext Transfer Protocol (HTTP) service module 511, which are used to send upgrade service operation requests to blockchain nodes and process the responses of blockchain nodes. The Remote Procedure Call Protocol service module can be an open-source high-performance Remote Procedure Call (GRPC).

[0168] The chain request management module 520: is used to operate on the key steps during the node upgrade process. The chain request management module 520 includes a node status detection component 521, a chain configuration management component 522, a consensus node joining component 523, a consensus node exiting component 524, and a consensus node upgrade component 525.

[0169] The node status detection component 521 is used to obtain the running status of the node and the identity information of the node. The identity information includes: node identifier (ID), node running time, and the consensus status of the node. The consensus status specifically includes information such as the current latest block height, the currently consensus block height (consensus height), whether the current node is a consensus node, and if it is a consensus node, whether the node is the primary node, etc. The block height is the number of blocks linked to the main chain, that is, the number of blocks connected to the blockchain.

[0170] The chain configuration management component 522 is used to initiate a chain configuration type transaction to modify the chain configuration of the blockchain network, and can modify the number of consecutive blocks produced by the primary node.

[0171] The consensus node joining component 523 is used to initiate a chain configuration type transaction to modify the chain configuration of the blockchain network, and can change a synchronization node to a consensus node.

[0172] The consensus node upgrade component 524 is used to adjust the version number in the blockchain. For example: adjust the version of a certain node device from v1 to v2. After the adjustment, the blockchain network will run different code logics according to different versions.

[0173] The consensus node exit component 525 is used to initiate a chain configuration type transaction to modify the chain configuration of the blockchain network, and can change the consensus node to a synchronization node.

[0174] The basic module 530 includes general class modules such as a network component 531, a storage component 532, a log component 533, and other tool components 534, etc., to provide basic services for the verification nodes. The other tool component 534 is used to refer to other tool components that can be applied to the server and are not exemplified in the embodiments of the present application.

[0175] In the embodiments of the present application, only need to stop a certain node in turn through a specific mechanism for upgrading, and other nodes can still continue to provide services externally. The modular upgrade service has high generality and can implement a non-stop upgrade service for different types of blockchains. As long as the blockchain network can provide basic system contracts, various forms of upgrades can be realized.

[0176] Figures 6A to 6E It is an interaction schematic diagram of the blockchain network upgrade method provided by the embodiments of the present application. Figures 6A to 6E In steps 601 to 605 in [figure reference], there is a sequence according to the serial number size, and step 601 is executed first. Figures 6A to 6E The node upgrade server 500 in [figure reference] is Figure 5 The node upgrade server 500 in [figure reference], compared with Figure 5 has been simplified. The node upgrade server 500 can be implemented as Figure 5 the version in [figure reference] or Figures 6A to 6E a simplified version of [figure reference]. Taking the blockchain network 200 that includes at least four nodes such as node 1 to node 4 as an example for illustration.

[0177] Refer to Figure 6A , in step 601, call the node status detection smart contract to detect the node status.

[0178] Exemplarily, the node upgrade server 500 sends a transaction to the blockchain network 200 (the fifth call contract request above). A two-way node transaction means that in the blockchain network, a node can be both the sender (sending node) and the receiver (receiving node) of a transaction. Sending a transaction in the blockchain network is also sending information.

[0179] Step 601 can be implemented in the following way: The node upgrade server 500 sends a request to the blockchain network 200 to call the node status detection system contract (NSC), so that the blockchain network 200 returns the node status of each node device. The node status includes the running status of the node device and the identity information of the node. The identity information includes the node identifier (ID), the node running time, and the node consensus status.

[0180] The status of each consensus node can be detected in the following ways: determine whether each node is in a live state. Secondly, obtain the consensus height of each node, and determine whether the consensus heights among the nodes are consistent, and whether each consensus node has reached the current latest version. The live state means that the node device has no faults and is in a working state. By executing step 601, the node upgrade server 500 obtains the corresponding information in the blockchain network and performs the next processing based on these messages.

[0181] Reference Figure 6B , in step 602, call the configuration management smart contract to set the primary node to continuously produce blocks.

[0182] Exemplarily, the node upgrade server 500 sends a transaction (the first call contract request above) to the blockchain network 200 to call the configuration management system contract (CMC) so that the blockchain network 200 modifies the chain configuration. The logical functions of the configuration management system contract (CMC) include: modifying the number of consecutive blocks produced by the primary node. For example: changing the regular rotating block production mode of each primary node to a mode where a certain node continuously produces 1000 blocks, and extending the block production time when each node is the primary node, so as to provide sufficient time for operating the slave nodes. When the response result feedback by the blockchain network is that the modification is successful, continue to proceed backward; if it fails, stop the upgrade process.

[0183] Exemplarily, in the rotating block production mode, the node devices in the blockchain network that can be the primary node take turns and sequentially perform block production processing. For example: after each primary node device produces 100 blocks, other primary node devices continue to produce blocks. In the rotating block production mode, the block production duration or the number of consecutive blocks produced by a single primary node device is less than that in the continuous block production mode.

[0184] Reference Figure 6C , in step 603, call the node management smart contract to demote the slave node to be upgraded to a synchronization node.

[0185] Exemplarily, the synchronization node is also the node to be upgraded above. The node upgrade server 500 sends a transaction (the second call contract request above) to the blockchain network 200 to call the node management (NMC) contract to perform configuration operations on individual nodes. Figure 6C Taking it as an example, change the types of node 1 and node 2 among the slave nodes in the blockchain network from consensus nodes to synchronization nodes. The remaining two consensus nodes whose types are not changed continue to participate in consensus block production. The two synchronization nodes can also synchronize the latest blocks in real time. The blockchain network 200 feeds back the node change result to the node upgrade server 500. If the node change result is not received, the node upgrade server 500 stops executing the next processing.

[0186] Exemplarily, before configuring the type of the node, the node upgrade server 500 obtains the status information of each node by calling the node status detection smart contract to determine which node is the primary node and which nodes are the secondary nodes.

[0187] Reference Figure 6D , in step 604, call the node upgrade smart contract to upgrade the node version.

[0188] Exemplarily, the node upgrade server 500 sends a transaction (the third contract call request above) to the blockchain network 200 to call the node upgrade smart contract (NUC) to upgrade the version numbers of the two synchronous nodes to a new version. Before the upgrade, the node upgrade server 500 replaces the images of the two synchronous nodes and restarts the two synchronous nodes. After the synchronous nodes are restarted, the upgrade process is executed. The node upgrade can be an upgrade process of the node's program, data, or protocol.

[0189] Exemplarily, the blockchain network 200 feeds back the node change result of the completed node upgrade to the node upgrade server 500. If the node upgrade server 500 does not receive the node change result of the completed node upgrade, it stops executing the next step of the process.

[0190] Reference Figure 6E , in step 605, call the node management smart contract to replace the synchronous nodes with consensus nodes.

[0191] Exemplarily, when nodes 1 and 2 are upgraded, the node upgrade server 500 sends a transaction (the fourth contract call request above) to the blockchain network 200 to call the node management smart contract to replace nodes 3 and 4 with nodes 1 and 2, so that the types of nodes 1 and 2 become consensus nodes, and the types of nodes 3 and 4 become synchronous nodes. The upgrade process is executed cyclically to upgrade synchronous nodes 3 and 4 to a higher version. After nodes 3 and 4 are changed to a higher version, the node upgrade server will initiate a transaction to call the node management smart contract to restore nodes 3 and 4 to consensus nodes. When all 4 nodes are upgraded, each node can be compatible with the consensus messages of the same version and continue to produce blocks.

[0192] Exemplarily, the blockchain network 200 feeds back the node change result of the completed node replacement to the node upgrade server 500. If the node upgrade server 500 does not receive the node change result of the completed node replacement, it stops executing the next step of the process.

[0193] For example, when there are more nodes in the blockchain network 200, the above-described manner of steps 601 to 605 can still be referred to. Each time an upgrade process is performed, at least one node device in the blockchain network is upgraded without affecting the consensus processing of other node devices. When the upgrade process is completed, the block generation mode of the primary node device can be restored to the round-robin block generation mode.

[0194] In the embodiments of the present application, relevant instructions and requests are sent to the blockchain network through a node upgrade server independent of the blockchain network to achieve self-adaptive upgrade of the system. The nodes in the blockchain are probed. When probing a node, if the node is online and running normally, the node is then set to the state of continuous block generation, that is, a certain node continuously acts as the primary node for block proposal. Secondly, a node upgrade request is sequentially sent to the slave nodes, the operation of the node to be upgraded is stopped, the mirror of the node is replaced, the node is restarted, and finally the strategy of continuous block generation is deleted. Each node generates blocks in turn and round-robin, and the version number of each node is upgraded. It is possible to achieve upgrade without service interruption. When a certain node is being upgraded, other nodes can still continue to provide services externally, ensuring the stable operation of the business system that provides services in the blockchain network.

[0195] Next, the implementation of the blockchain network upgrade device 455 provided in the embodiments of the present application as an exemplary structure of software modules will be continued. In some embodiments, such as Figure 2DAs shown, the software module stored in the upgrade device 455 of the blockchain network in the memory 450 may include: a configuration module 4552, configured to send a first contract call request to the blockchain network, where the first contract call request is used to trigger the block generation mode of the first primary node device to switch from the round-robin block generation mode to the continuous block generation mode, and the block generation duration of the continuous block generation mode is greater than the block generation duration of the round-robin block generation mode, and the first primary node device is one of the multiple primary node devices; the configuration module 4552 is further configured to, in response to receiving the first feedback information, send a second contract call request to the blockchain network, where the first feedback information indicates that the first primary node device has successfully switched to the continuous block generation mode, and the second contract call request is used to trigger the type of the slave node device to be upgraded to switch from the consensus node device to the device to be upgraded; an upgrade module 4553, configured to, in response to receiving the second feedback information, send a third contract call request to the blockchain network, where the second feedback information indicates that the type of the slave node device to be upgraded has switched to the device to be upgraded, and the third contract call request is used to trigger the device to be upgraded to perform a version upgrade process; the upgrade module 4553 is further configured to, in response to receiving the third feedback information, send a fourth contract call request to the blockchain network, where the third feedback information indicates that the version upgrade process of the device to be upgraded is completed, and the fourth contract call request is used to trigger the type of the upgraded slave node device to be restored to the consensus node device.

[0196] In some embodiments, a detection module 4551 is configured to, before sending the first contract call request to the blockchain network, send a fifth contract call request to the blockchain network, where the fifth contract call request is used to obtain the identity information and the consensus status information of each node device in the blockchain network, and the identity information includes: a node device identifier and a node device type, and the consensus status information at least includes a consensus height; in response to receiving the identity information and the consensus status information, determine the slave node device to be upgraded according to the identity information and the consensus status information, and determine the first primary node device from the multiple primary node devices.

[0197] In some embodiments, the detection module 4551 is configured to determine multiple surviving slave node devices among the multiple node devices according to the identity information; determine the surviving slave node devices with the same consensus height among the multiple surviving slave node devices; compare the version numbers of each of the surviving slave node devices with the same consensus height to obtain a comparison result; in response to the comparison result corresponding to the surviving slave node device being that the version number is less than the latest version number, use the surviving slave node device as the slave node device to be upgraded.

[0198] In some embodiments, the continuous block generation mode includes: continuously performing block generation processing by the first primary node device; when the number of blocks continuously generated by the first primary node device reaches a pre-configured number, performing block generation processing by a second primary node device, where the second primary node device is one of the multiple primary node devices and is different from the first primary node device.

[0199] In some embodiments, the continuous block generation mode includes: continuously performing block generation processing by the first primary node device; when the duration of the block generation processing performed by the first primary node device reaches a pre-configured duration, performing block generation processing by a second primary node device, where the second primary node device is one of the multiple primary node devices and is different from the first primary node device.

[0200] In some embodiments, the upgrade module 4553 is further configured to, before the device to be upgraded performs version upgrade processing, send upgrade data corresponding to the latest version number to the device to be upgraded; the third call contract request is used to trigger the device to be upgraded to perform version upgrade processing in the following manner, including: replacing the image data of the device to be upgraded based on the upgrade data; controlling the device to be upgraded to stop running, and controlling the stopped device to be upgraded to perform a restart operation; in response to the completion of the restart of the device to be upgraded, replacing the version number of the device to be upgraded with the latest version number.

[0201] In some embodiments, after restoring the type of the upgraded slave node device to the consensus node device, the upgrade module 4553 is further configured to, in response to receiving fourth feedback information, send the second call contract request to the blockchain network, where the fourth feedback information indicates that the type of the upgraded slave node device has been restored to the consensus node device; in response to receiving fifth feedback information, stop sending the second call contract request to the blockchain network, where the fifth feedback information indicates that all the multiple slave node devices have been upgraded.

[0202] In some embodiments, the configuration module 4552 is further configured to, in response to receiving the fifth feedback information, send a sixth call contract request to the blockchain network, where the sixth call contract request is used to trigger the block generation mode of the first primary node device in the blockchain network to be restored to the round-robin block generation mode.

[0203] In some embodiments, the number of devices to be upgraded that perform version upgrade processing simultaneously is at least one. When the devices to be upgraded perform version upgrade processing, the consensus function of the slave node devices of the consensus node device type remains in an operating state.

[0204] In some embodiments, the configuration module 4552 is further configured to, in response to receiving the third feedback information, send a seventh contract call request to the blockchain network, where the seventh contract call request is used to trigger the upgraded slave node device to clean up redundant data of the previous version.

[0205] In some embodiments, the configuration module 4552 is further configured to, in response to receiving the third feedback information, send a fifth contract call request to the blockchain network, where the fifth contract call request is used to obtain the identity information and consensus status information of each node device in the blockchain network; in response to receiving the identity information and the consensus status information, determine the working status of the upgraded slave node device according to the identity information and the consensus status information; in response to the working status of the upgraded slave node device being a fault status, send an eighth contract call request to the blockchain network, where the eighth contract call request is used to trigger the upgraded slave node device to restart.

[0206] An embodiment of the present application provides a computer program product, which includes a computer program or computer executable instructions, and the computer program or computer executable instructions are stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer executable instructions from the computer-readable storage medium, and the processor executes the computer program or computer executable instructions, so that the electronic device executes the upgrade method of the blockchain network in the above embodiments of the present application.

[0207] An embodiment of the present application provides a computer-readable storage medium storing computer executable instructions, where computer executable instructions or a computer program are stored, and when the computer executable instructions or the computer program are executed by a processor, the processor will be caused to execute the upgrade method of the blockchain network provided by the embodiments of the present application. For example, Figure 3A the upgrade method of the blockchain network shown.

[0208] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD-ROM; or it may be various devices including one or any combination of the above memories.

[0209] In some embodiments, the computer executable instructions may be in the form of a program, software, software module, script, or code, and may be written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0210] As an example, the computer-executable instructions may or may not correspond to files in a file system, and may be stored as part of a file that stores other programs or data. For example, they may be stored in one or more scripts in a HyperText Markup Language (HTML) document, stored in a single file dedicated to the program being discussed, or stored in multiple cooperating files (e.g., files that store one or more modules, subroutines, or code portions).

[0211] As an example, the executable instructions may be deployed to execute on one electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed at multiple locations and interconnected by a communication network.

[0212] In summary, before performing the upgrade process for the slave node device through the embodiments of the present application, a call contract instruction is sent to configure the block generation mode of the master node device in the blockchain network. In the case of successful configuration, the version upgrade process of the slave node device is executed, causing the block generation duration of the master node device to be delayed, which can reserve time to execute the version upgrade process of the slave node device. When the consensus messages are incompatible, the node devices can be upgraded, ensuring that the blockchain network can still reach a consensus without being unable to do so due to incompatible consensus messages, improving the smoothness of the upgrade process. During the upgrade process, compared with the related technology of shutting down the entire blockchain network, there is no need to shut down most of the node devices, improving the efficiency of the upgrade process.

[0213] The above description is only for the embodiments of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A method for upgrading a blockchain network, characterized in that, The blockchain network includes multiple master node devices and multiple slave node devices; The method includes: Sending a first contract call request to the blockchain network, where the first contract call request is used to trigger the block generation mode of a first master node device to switch from a round-robin block generation mode to a continuous block generation mode, and the block generation duration of the continuous block generation mode is greater than the block generation duration of the round-robin block generation mode. The first master node device is one of the multiple master node devices; In response to receiving the first feedback information, sending a second contract call request to the blockchain network, where the first feedback information indicates that the first master node device has successfully switched to the continuous block generation mode, and the second contract call request is used to trigger the type of the slave node device to be upgraded to switch from a consensus node device to a device to be upgraded; In response to receiving the second feedback information, sending a third contract call request to the blockchain network, where the second feedback information indicates that the type of the slave node device to be upgraded has switched to the device to be upgraded, and the third contract call request is used to trigger the device to be upgraded to perform version upgrade processing; In response to receiving the third feedback information, sending a fourth contract call request to the blockchain network, where the third feedback information indicates that the version upgrade processing of the device to be upgraded is completed, and the fourth contract call request is used to trigger the type of the upgraded slave node device to be restored to the consensus node device.

2. The method according to claim 1, wherein Before sending the first contract call request to the blockchain network, the method further includes: Sending a fifth contract call request to the blockchain network, where the fifth contract call request is used to obtain the identity information and consensus status information of each node device in the blockchain network; In response to receiving the identity information and the consensus status information, determining the slave node device to be upgraded according to the identity information and the consensus status information, and determining a first master node device from the multiple master node devices.

3. The method according to claim 2, wherein The identity information includes: a node device identifier and a node device type, and the consensus status information at least includes a consensus height; The determining the slave node device to be upgraded according to the identity information and the consensus status information includes: Determining multiple surviving slave node devices among the multiple node devices according to the identity information, where the surviving slave node devices are node devices without faults and in a working state; Determining the surviving slave node devices with the same consensus height among the multiple surviving slave node devices; Comparing the version numbers of each of the surviving slave node devices with the same consensus height to obtain a comparison result; In response to the comparison result corresponding to the surviving slave node device being that the version number is less than the latest version number, taking the surviving slave node device as the slave node device to be upgraded.

4. The method according to claim 1, characterized in that The continuous block generation mode includes: continuously performing block generation processing by the first primary node device. When the number of blocks continuously generated by the first primary node device reaches a pre-configured number, block generation processing is performed by the second primary node device, where the second primary node device is one of the multiple primary node devices and is different from the first primary node device.

5. The method according to claim 1, characterized in that, The continuous block generation mode includes: continuously performing block generation processing by the first primary node device. When the duration of the block generation processing performed by the first primary node device reaches a pre-configured duration, block generation processing is performed by the second primary node device, where the second primary node device is one of the multiple primary node devices and is different from the first primary node device.

6. The method according to claim 1, wherein Before the device to be upgraded undergoes version upgrade processing, the method further includes: Sending upgrade data corresponding to the latest version number to the device to be upgraded; The third call contract request is used to trigger the device to be upgraded to perform version upgrade processing in the following manner, including: replacing the mirror data of the device to be upgraded based on the upgrade data; controlling the device to be upgraded to stop running, and controlling the stopped device to be upgraded to perform a restart operation; in response to the completion of the restart of the device to be upgraded, replacing the version number of the device to be upgraded with the latest version number.

7. The method according to any one of claims 1 to 6, characterized in that, After restoring the type of the upgraded slave node device to the consensus node device, the method further includes: In response to receiving the fourth feedback information, sending the second call contract request to the blockchain network, where the fourth feedback information indicates that the type of the upgraded slave node device has been restored to the consensus node device; In response to receiving the fifth feedback information, stopping sending the second call contract request to the blockchain network, where the fifth feedback information indicates that all the multiple slave node devices have been upgraded.

8. The method according to claim 7, characterized in that, The method further includes: In response to receiving the fifth feedback information, sending a sixth call contract request to the blockchain network, where the sixth call contract request is used to trigger the block generation mode of the first primary node device in the blockchain network to be restored to the round-robin block generation mode.

9. The method according to any one of claims 1 to 6, characterized in that, The number of devices to be upgraded that perform version upgrade processing simultaneously is at least one. When the device to be upgraded performs version upgrade processing, the consensus function of the slave node device of the consensus node device type remains in the running state.

10. The method according to any one of claims 1 to 6, characterized in that The method further includes: In response to receiving the third feedback information, sending a seventh call contract request to the blockchain network, where the seventh call contract request is used to trigger the upgraded slave node device to clean up redundant data of the previous version.

11. The method according to any one of claims 1 to 6, characterized in that, The method further includes: In response to receiving the third feedback information, sending a fifth call contract request to the blockchain network, where the fifth call contract request is used to obtain the identity information and consensus status information of each node device in the blockchain network; In response to receiving the identity information and the consensus status information, determining the working state of the upgraded slave node device according to the identity information and the consensus status information; In response to the working state of the upgraded slave node device being a fault state, send an eighth contract call request to the blockchain network, where the eighth contract call request is used to trigger the restart of the upgraded slave node device.

12. An upgrade device for a blockchain network, characterized in that, The blockchain network includes a plurality of master node devices and a plurality of slave node devices; the device includes: A configuration module, configured to send a first contract call request to the blockchain network, where the first contract call request is used to trigger the block production mode of a first master node device to switch from a round-robin block production mode to a continuous block production mode, and the block production duration of the continuous block production mode is greater than the block production duration of the round-robin block production mode, and the first master node device is one of the plurality of master node devices; The configuration module is further configured to, in response to receiving first feedback information, send a second contract call request to the blockchain network, where the first feedback information indicates that the first master node device has successfully switched to the continuous block production mode, and the second contract call request is used to trigger the type of the slave node device to be upgraded to switch from a consensus node device to a device to be upgraded; An upgrade module, configured to, in response to receiving second feedback information, send a third contract call request to the blockchain network, where the second feedback information indicates that the type of the slave node device to be upgraded has switched to the device to be upgraded, and the third contract call request is used to trigger the device to be upgraded to perform version upgrade processing; The upgrade module is further configured to, in response to receiving third feedback information, send a fourth contract call request to the blockchain network, where the third feedback information indicates that the version upgrade processing of the device to be upgraded is completed, and the fourth contract call request is used to trigger the type of the upgraded slave node device to be restored to the consensus node device.

13. An electronic device, characterized in that, The electronic device includes: A memory, configured to store computer-executable instructions or a computer program; A processor, configured to implement the upgrade method of the blockchain network according to any one of claims 1 to 11 when executing the computer-executable instructions or the computer program stored in the memory.

14. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, The computer-executable instructions or the computer program, when executed by the processor, implement the upgrade method of the blockchain network according to any one of claims 1 to 11.

15. A computer program product, comprising computer-executable instructions or a computer program, characterized in that, The computer-executable instructions or the computer program, when executed by the processor, implement the upgrade method of the blockchain network according to any one of claims 1 to 11.

Images