WO2023065788A1 - 升级区块链系统的方法、装置及终端设备 - Google Patents

升级区块链系统的方法、装置及终端设备 Download PDF

Info

Publication number
WO2023065788A1
WO2023065788A1 PCT/CN2022/111761 CN2022111761W WO2023065788A1 WO 2023065788 A1 WO2023065788 A1 WO 2023065788A1 CN 2022111761 W CN2022111761 W CN 2022111761W WO 2023065788 A1 WO2023065788 A1 WO 2023065788A1
Authority
WO
WIPO (PCT)
Prior art keywords
version number
version
target
upgrade
blockchain system
Prior art date
Application number
PCT/CN2022/111761
Other languages
English (en)
French (fr)
Inventor
匡立中
邱炜伟
马晓敏
黄方蕾
Original Assignee
杭州趣链科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 杭州趣链科技有限公司 filed Critical 杭州趣链科技有限公司
Priority to EP22789829.3A priority Critical patent/EP4195033A4/en
Publication of WO2023065788A1 publication Critical patent/WO2023065788A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • This application relates to the field of computer application technology, in particular to a method, device and terminal equipment for upgrading a blockchain system.
  • the blockchain system can be composed of multiple participant nodes. When there are defects or new functions in the blockchain system, it can be repaired or updated through system upgrades.
  • One of the purposes of the embodiments of the present application is to provide a method, device and terminal equipment for upgrading a blockchain system.
  • a method for upgrading the blockchain system which may include:
  • the participant node in the blockchain system updates the initial binary program to the target binary program, determine the first target support version number of the blockchain system; calculate the area according to the first target support version number The first target upgrade version number shared by all the participating party nodes in the block chain system; when the voting result of the system upgrade proposal transaction by the participating party node is passed, the initial running version of the block chain system currently running The system version of the number is upgraded to the system version of the first target upgrade version number;
  • the upgrade proposal transaction is initiated by a chain-level administrator account
  • the system version of the first target support version number is the system version compatible with the target binary program
  • the first target support version number includes the An initial running version number and the first target upgrade version number
  • the first target upgrade version number is higher than the initial running version number
  • the participant node is a node participating in the consensus mechanism in the block chain system.
  • a device for upgrading the blockchain system may include:
  • a processing unit configured to determine the first target supported version number of the blockchain system after the participant node in the blockchain system updates the initial binary program to the target binary program;
  • a calculation unit configured to calculate the first target upgrade version number of the blockchain system according to the first target support version number
  • An upgrade unit configured to upgrade the system version of the initial running version number currently running by the blockchain system to the first target upgrade version number when the voting result of the participant node on the system upgrade proposal transaction is passed the system version of
  • the upgrade proposal transaction is initiated by a chain-level administrator account
  • the system version of the first target support version number is the system version compatible with the target binary program
  • the first target support version number includes the An initial running version number and the first target upgrade version number
  • the first target upgrade version number is higher than the initial running version number
  • the participant node is a node participating in the consensus mechanism in the block chain system.
  • a terminal device including a memory, a processor, and a computer program stored in the memory and operable on the processor, when the processor executes the computer program, the computer program described in the first aspect is implemented. described method.
  • a computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in the first aspect is implemented.
  • a computer program product is provided.
  • the terminal device is made to execute the method described in the first aspect above.
  • the beneficial effect of the method for upgrading the blockchain system is that: through this application, after the participant nodes in the blockchain system update the initial binary program to the target binary program, the blockchain system is determined to The first target support version number; according to the first target support version number, calculate the first target upgrade version number shared by the participant nodes in the blockchain system; make a system upgrade proposal at the participant node When the voting result of the transaction is passed, the system version of the initial running version number currently running of the blockchain system is upgraded to the system version of the first target upgrade version number; through this application, the target binary of the participant node update The program can be compatible with the initial running version of the blockchain system.
  • the blockchain system Before the blockchain system is upgraded, it runs with the initial version, which can ensure the consensus mechanism and availability of the blockchain system before the upgrade, and update the binary program in advance. After determining the first goal After the version is upgraded, the system version is updated directly, which improves the upgrade efficiency of the blockchain system; thereby solving the problem that it is easy to fail to reach a consensus or the entire blockchain system is unavailable during the upgrade of the blockchain system, and improves the blockchain system.
  • the upgrade efficiency of the chain system it has strong ease of use and practicality.
  • FIG. 1 is a schematic diagram of a system architecture of an application scenario provided by an embodiment of the present application
  • Fig. 2 is a schematic flow diagram of a block chain upgrade method provided by an embodiment of the present application
  • FIG. 3 is a schematic diagram of upgrade process nodes provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of upgrade process nodes provided by another embodiment of the present application.
  • Fig. 5 is a schematic structural diagram of a block chain upgrade device provided by an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • the term “if” may be construed, depending on the context, as “when” or “once” or “in response to determining” or “in response to detecting “.
  • the phrase “if determined” or “if [the described condition or event] is detected” may be construed, depending on the context, to mean “once determined” or “in response to the determination” or “once detected [the described condition or event] ]” or “in response to detection of [described condition or event]”.
  • references to "one embodiment” or “some embodiments” or the like in the specification of the present application means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application.
  • appearances of the phrases “in one embodiment,” “in some embodiments,” “in other embodiments,” “in other embodiments,” etc. in various places in this specification are not necessarily All refer to the same embodiment, but mean “one or more but not all embodiments” unless specifically stated otherwise.
  • the terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”, unless specifically stated otherwise.
  • the consortium blockchain is a distributed ledger that is jointly calculated by multiple companies or institutions. Each participant has deployed at least one blockchain node to synchronize the full amount of blockchain data and participate in the calculation and consensus of the ledger. This includes: A system of multiple parties can become a blockchain system.
  • the methods for upgrading the alliance blockchain system include offline system upgrades and online system upgrades.
  • the offline system upgrade requires multiple participants to coordinate an upgrade cycle that everyone can accept.
  • all application services in the blockchain system are stopped, and all binary programs of all participants are completed.
  • Replacement, and the restarted blockchain system is running normally to confirm the success of the upgrade.
  • the cost of offline communication is relatively high, and it is difficult to negotiate a consistent upgrade cycle, and all participants need to keep in touch during the binary program replacement process, and the binary program replacement is completed on all participant nodes After that, you can check whether the local node can run normally; at the same time, during the upgrade process, there may be different binary program versions, so that the entire blockchain system may not be able to provide blockchain services normally.
  • the online system upgrade requires the blockchain system to obtain the system upgrade proposal transaction proposed by the user, and execute the system upgrade proposal transaction after each participant node votes on the system upgrade proposal transaction.
  • the participant node needs to automatically obtain the binary file and upgrade script required for the upgrade from a remote location through a network request, and compare the hash value of the binary file with other participant nodes.
  • the upgrade of the block chain system Due to the environmental differences and complexity of each participant node, the online system upgrade may have the risk of network request binary file failure; and the upgrade script is responsible for stopping the running process of the old binary program of the node and starting the running process of the new binary program of the node, so that There may be cases where the upgrade script of some nodes is successfully executed, and some execution fails. When the number of node errors exceeds the number of Byzantine nodes that the blockchain system can support, the blockchain system will be unavailable. state.
  • the method for upgrading the blockchain system in the embodiment of this application can realize the compatibility of multiple system versions of the participating nodes. Through online version management and version negotiation, the cost of offline communication is reduced, and the upgrade of the blockchain system is improved. The efficiency; at the same time, it ensures that the blockchain system can also generate new blocks during the upgrade process, and continue to provide services for upper-layer applications.
  • FIG. 1 is a schematic diagram of a system architecture of an application scenario provided by an embodiment of the present application.
  • the blockchain system is a distributed ledger, which is a network cluster composed of multiple participant nodes.
  • the blockchain system includes participant nodes 1 to 7, and each participant node can include node-level Version modules (such as communication network modules) and chain-level version modules (such as consensus algorithm modules, execution engine modules, virtual machine modules, and cryptography modules, etc.).
  • node-level Version modules such as communication network modules
  • chain-level version modules such as consensus algorithm modules, execution engine modules, virtual machine modules, and cryptography modules, etc.
  • the time for each participant node to upgrade the binary program may not be equal, so it is necessary to ensure the data compatibility, protocol compatibility, and communication compatibility of each participant in the blockchain system.
  • the blockchain system is a system composed of a communication network module, a consensus algorithm module, an execution engine module, a virtual module, and a cryptography module, the system versions corresponding to each module of the blockchain system are divided into node-level versions and chain Level version, manage the system version corresponding to each module, and realize the compatibility of each module during the upgrade process of the blockchain system.
  • the node-level version refers to the system version corresponding to the module whose communication interaction between the participating nodes in the blockchain system is not constrained by the consensus mechanism.
  • the corresponding version number does not need to be recorded in the ledger of the blockchain.
  • the two nodes negotiate the maximum version number shared by the module, and run according to the logic defined by the maximum version number.
  • the chain-level version refers to the system version corresponding to the module whose communication interaction between the participating nodes is subject to the consensus mechanism.
  • the corresponding version number needs to be recorded on the ledger of the blockchain. Version number, each participant node runs with the logic defined by the maximum version number.
  • the consensus mechanism constraints include consensus quorum constraints.
  • the consensus Quorum constraint is Practical Byzantine Fault Tolerant (Practical Byzantine Fault In Tolerance, PBFT) consortium chain consensus algorithm, when a node broadcasts a consensus message, it needs to receive a reply from a quorum of Quorum nodes before continuing to execute.
  • PBFT Practical Byzantine Fault Tolerant
  • the embodiment of the present application provides a method for upgrading the blockchain system, which can realize the compatibility of various modules in the upgrading process of the blockchain system and improve the upgrading efficiency of the blockchain system.
  • the following describes the specific process of implementing the method through the embodiments of the present application.
  • FIG. 2 is a schematic flowchart of a blockchain upgrade method provided by an embodiment of the present application. As shown in Figure 2, the method includes the following steps:
  • Step S201 after the participant node in the blockchain system updates the initial binary program to the target binary program, determine the first target supported version number of the blockchain system.
  • the execution subject of the method may be a terminal device corresponding to a participant node in the blockchain system, and the terminal device may be a computing device such as a desktop computer, a notebook, a palmtop computer, or a cloud server.
  • the binary program is a program file of data or program instructions written in multi-line characters, and is a program file used to support the operation of the blockchain system.
  • each participant node needs to replace and upgrade the binary program offline. Since the upgrade of the binary program requires the participating nodes to stop running online, in order to ensure that the blockchain system is not affected during the upgrade process and conforms to the number of Byzantine nodes that can be accommodated by the consensus mechanism of the blockchain system, the line of each participant node The next upgrade needs to be done in rounds.
  • the terminal device corresponding to the participant node in the blockchain system can receive the upgrade command input by the user, and the terminal device executes the upgrade command to convert the initial binary program in the blockchain system to Upgrading replaces the target binary.
  • the participant nodes in the blockchain system update the initial binary program to the target binary program, including:
  • the preset number of the participant nodes in the blockchain system stop running online in rounds and perform data backup; the preset number of the participant nodes offline replace the initial binary program with the target binary program.
  • the preset number is less than or equal to the number of fault-tolerant participant nodes of the consensus mechanism of the blockchain system; or, the preset number is less than or equal to the number described in the partition network in the blockchain system The number of participant nodes that the consensus mechanism is fault-tolerant.
  • the participating nodes of the blockchain system are nodes 1 to 7.
  • Redundant Byzantine Fault Tolerance Redundant Byzantine Fault Tolerance
  • the corresponding supported system version of the node before stopping the online operation is the system version compatible with the initial binary program, for example, before the first round of upgrade, the corresponding supported versions of nodes 1 to 7 are version V1.0; offline
  • the supported system version after the upgrade is the version compatible with the target binary program.
  • the supported versions of Node 1 and Node 2 include V1.0 and V2.0.
  • the first seven nodes in the blockchain consensus network only support the v1.0 protocol, and the blockchain system is also running v1.0, so the system version needs to be upgraded to v2.0, then By stopping two nodes in each round, the binary program is upgraded offline, and through four rounds of upgrades, all nodes in the entire blockchain consensus network complete the upgrade and replacement of the binary program.
  • the first round of binary program upgrades is carried out by Node 1 and Node 2.
  • Node 1 and Node 2 support v1.0 and v2.0 versions, because the system version of the entire system is still v1 .0, so Node 1 and Node 2 are also running v1.0.
  • the second round of binary program upgrade is performed by Node 3 and Node 4.
  • Node 3 and Node 4 support v1.0 and v2.0 versions. Since the entire system is still running v1.0, Node 3 and Node 4 Node 4 is also running v1.0.
  • the third round of upgrades and the fourth round of upgrades are the same.
  • the binary program when the blockchain system includes multiple partitioned networks, the binary program can also be upgraded and replaced according to the partitioned networks.
  • each partition network is an independent application chain
  • partition network 1 is composed of node 1
  • node 2 is composed of It consists of node 4, node 5, node 6 and node 7; among them, node 4 is in two partitioned networks.
  • the system versions of the partitioned network 1 and the partitioned network 2 are both v1.0, and then the partitioned network 1 needs to be upgraded to the v2.0 version.
  • the nodes in the partition network 1 upgrade and replace the offline binary program.
  • partition network 1 the entire upgrade process of partition network 1 is almost insensitive to partition network 2, and only node 4 has a short-term shutdown and restart. It will not affect the business operation of partition network 2.
  • partition 1 runs the v2.0 version of the protocol
  • partition 2 runs the v1.0 version of the protocol.
  • Node 4 supports both v1.0 and v2.0, running v2.0 in partition 1 and running v1.0 in partition 2.
  • the node before upgrading and replacing the binary program, the node also performs data backup, which includes the backup of the system version and the backup of other transaction execution result data. After replacing the binary program, the node changes the corresponding configuration, such as reconfiguring system parameters, etc.
  • the version number belonging to the chain-level version in the blockchain system can be recorded in the genesis block to initialize the genesis chain before the upgrade of the blockchain system; wherein, it is recorded in the genesis block
  • the version number of includes a list of chain-level version numbers supported by the genesis node (version numbers of all supported versions) and a running chain-level version number (version number of the running version). In order to facilitate the query or reference of the version in the subsequent upgrade process.
  • the chain-level version number in the blockchain system is recorded in the genesis block, and the initial running version and initial support version of the system are recorded in the ledger of the blockchain system.
  • the node completes the offline upgrade of the binary program. After startup, the supported version compatible with the target binary program is re-recorded in the ledger.
  • the seven nodes have completed the upgrade and replacement of the binary program, and the blockchain system is still running with the initial version recorded in the ledger (such as version v1.0). This ensures the compatibility of each module of the blockchain system during the upgrade process and satisfies the consensus mechanism of the blockchain system. Even if there are binary programs compatible with different system versions in the blockchain system, the blockchain consensus network can still Consensus services are provided normally.
  • the upgraded target binary program of each node in the blockchain system is the same, and the system version supported by each node is the same.
  • the first target support version number is a set of version numbers of supported versions corresponding to each participant node in the blockchain system, or a version number of supported versions corresponding to the entire blockchain system.
  • the first target supported version number of the blockchain system includes V1.0 and V2.0.
  • the determining the first target support version number of the blockchain system includes:
  • the participant node obtains the chain-up request initiated by the chain-level administrator account for the supported version number; according to the chain-up request, each of the participant nodes in the blockchain system generates a Support the transaction of the version number, and broadcast the transaction to other participant nodes in the blockchain system; all the participant nodes will The supported version number in the transaction is stored in the ledger to obtain the first target supported version number of the blockchain system.
  • the chain-level administrator account can be an account set up on an authorized participant node in the blockchain system, or an account set up on an authorized genesis block, or a higher-level account set up by The account set in the authorized block; through this account, an uplink request can be initiated to the participant nodes in the blockchain system.
  • the uplink request may include parameters for supported versions of each node.
  • each participant node in the blockchain system constructs a transaction containing its own supported version based on its own node account, and broadcasts it to nodes in the entire blockchain system.
  • the participant node that receives the transaction caches the transaction in the transaction pool, and the master node in the participant node can read from the transaction pool
  • the transactions in the transaction pool are taken out from the transaction pool, and one or more transactions are packaged into blocks, and broadcast to other participating nodes.
  • the participating nodes agree on the block.
  • each participating node executes the transaction in the block.
  • the ledger status is modified, and the supported version number in the transaction is stored in the ledger.
  • each participant node in the blockchain system can be the initiator of the transaction or the receiver of the transaction.
  • the participant node executes the transaction
  • the supported version in the received transaction is stored in the ledger.
  • the first target supported version number corresponding to the blockchain system can be determined. For example, as shown in FIG. 3 , before upgrading, according to the transactions executed by the participating nodes, it can be determined that the first target supported version numbers of the blockchain system include V1.0 and V2.0.
  • the method further includes:
  • the participant node identifies the authority of the participant node that broadcasts the transaction; if the participant node that broadcasts the transaction is node, the participant node stores the supported version numbers in all the transactions into the ledger.
  • each participant node in the blockchain system when receiving the transaction, it is also necessary to check the authority of the initiator of the transaction. If the initiator of the transaction is the blockchain system consensus A member of the network, proceed to execute the transaction. Otherwise, the transaction receiver node returns a prompt that the execution of the transaction failed, and does not modify the ledger.
  • Step S202 calculate the first target upgrade version number shared by the participant nodes in the blockchain system.
  • the upgraded version number of the first target corresponding to the blockchain system can be determined based on the supported version number of the first target.
  • a binary program can be compatible with multiple system versions.
  • the compatible system versions of binary program A are V1.0 and V1.1; after some new features have been added through development, and the system version is V1.2, binary program B is compatible.
  • the system versions are V1.0, V1.1 and V1.2. That is, when the participant nodes in the blockchain system are in binary program A, the supported system versions include version V1.0 and version V1.1; when binary program A is upgraded and replaced with binary program B, the blockchain system
  • the system versions supported by the participant nodes include V1.0, V1.1 and V1.2, that is, it can be determined that the first target supported version includes V1.0, V1.1 and V1.2. According to the first target support version, the first target upgrade version number shared by all participant nodes, such as version V1.2, can be calculated.
  • the method further includes:
  • first target upgrade version number is higher than the initial running version number, then replace the initial upgrade version number recorded in the account book with the first target upgrade version number; if the first target upgrade version number is not high For the initial running version number, the initial upgrade version number recorded in the ledger is retained.
  • the initial running version number before the system upgrade is recorded in the ledger of the blockchain system or the participant node; the blockchain system may have undergone multiple system upgrades, and the last system upgrade may also be recorded in the ledger
  • the version number of the system version running after the system upgrade is also the initial upgrade version number; then, in the next upgrade, if the first target upgrade version number is higher than the initial running version number (that is, the initial upgrade version number), and replace the original initial upgrade version number with the recalculated first target upgrade version number.
  • Step S203 when the voting result of the participant node on the system upgrade proposal transaction is passed, upgrade the system version of the initial running version number currently running in the blockchain system to the system version number of the first target upgrade version number Version.
  • the upgrade proposal transaction is initiated by an authorized chain-level administrator account
  • the system version of the first target support version number is the system version compatible with the target binary program
  • the first target support version number includes the initial The running version number and the first target upgrade version number
  • the first target upgrade version number is higher than the initial running version number
  • the participating node is a node participating in the consensus mechanism in the block chain system.
  • the method further includes:
  • the chain-level administrator initiates a system upgrade proposal transaction to the blockchain system, and after the participating nodes of the blockchain system pass the vote, the system upgrade proposal transaction is executed.
  • the system upgrade proposal transaction is executed.
  • the first target upgrade version in the current ledger is a non-null value, and this value is greater than the system version currently running in the blockchain system (corresponding to the initial running version number)
  • reset the current running initial running version number The system version of is the system version of the first target upgrade version number, and the system upgrade is completed. Otherwise, the system upgrade proposal transaction execution fails, and the system does not perform the upgrade operation.
  • a binary program can be compatible with multiple system versions.
  • the system versions supported by binary program A are V1.0 and V1.1. It is assumed that the current blockchain system is running version V1.1 after startup. Afterwards, some new features were added through development.
  • the system version is V1.2
  • the system versions supported by binary program B are V1.0, V1.1 and V1.2. After startup, the system still runs on v1.1. Then, after the system upgrade proposal transaction is approved by voting, the system version of the blockchain system is upgraded to v1.2.
  • each node executes a system upgrade proposal transaction online, and resets the operating version of the system to V2.0.
  • the method before upgrading the system version of the initial running version number currently running by the blockchain system to the system version of the first target upgrade version number, the method further includes:
  • re-determining the second target support version number of the blockchain system after adding a new node includes:
  • the new node obtains the chain-up request initiated by the chain-level administrator account for the supported version number; according to the chain-up request, the new node generates a transaction containing the supported version corresponding to itself, and sends a transaction to the zone Other participant nodes in the block chain system broadcast the transaction; during the execution of the transaction, store the supported version number in the transaction, update the supported version number in the ledger, and obtain the second The target supports version numbers.
  • the new node information is recorded in the block In the built-in contract of the chain system.
  • the upgradeable version (the first target upgrade version) of the blockchain system may change and needs to be recalculated.
  • the blockchain system clears the first target upgrade version number of the current ledger.
  • the new node receives the uplink request for the supported version sent by the authorized chain-level administrator account, and the node account corresponding to the new node constructs a transaction with its own supported version number and broadcasts it to the entire network, updating the first target in the ledger
  • the supported version number is obtained from the updated supported version number of the second target, and the upgraded version number of the second target is calculated according to the supported version number of the second target. In this way, it can be ensured that during the upgrade process of the blockchain system, when new block nodes join the blockchain system, it can continue to provide services for upper-layer applications.
  • the participant node includes a chain-level version module; after the system version of the initial running version number currently running by the blockchain system is upgraded to the system version of the first target upgrade version number, the Methods also include:
  • the participant nodes in the blockchain system change the operating logic of each chain-level version module according to the upgraded system version.
  • each participant node in the blockchain system resets the running version (target upgrade version) of the system, it notifies the version number of the running version to each chain-level version of the protocol or module for logical change.
  • the method further includes :
  • the participant node registers the version number list of the system version supported by the node-level version module with the network module; when receiving a network connection establishment request through the network module, initiates the establishment of the network through the network module
  • the participant node of the connection request performs identity verification; after the identity verification is passed, calculate the maximum version number shared by the node-level modules in each of the participant nodes that carry out the network connection through the network module;
  • the node-level version module in the participant node of the network connection sends a notification, and the notification is used to instruct the node-level module in the participant node of the network connection to communicate based on the maximum version number.
  • the network module may be a module in the participant node that receives the network connection request.
  • each node-level protocol or module in the upper layer of the blockchain system registers the version number list of the system version supported by the protocol or module with the network module; the network module receives a network connection and completes the process of initiating the network connection After the identity verification of the participating node, enter the protocol version negotiation; through the protocol version negotiation, calculate the maximum version number shared by the node-level protocols or modules of the two nodes; the network module will return the negotiation results to the upper layer of each node-level protocol or Module; the upper layer node-level protocol or module records the result of the protocol version negotiation of the network module, and the subsequent communication between the two participants' nodes will run according to the logic defined by the system version with the largest version number in common.
  • the above-mentioned network module may be a module of two participant nodes that communicate with each other, and the execution subject of the above-mentioned process may be a participant node that receives a network connection in the blockchain system.
  • each network connection is independent of each other, and local nodes may use different node-level versions for communication with different nodes.
  • the first target supported version number of the blockchain system is determined; according to the first target supported version No., calculate the first target upgrade version number shared by the participant nodes in the blockchain system; when the voting result of the participant node on the system upgrade proposal transaction is passed, the current The system version of the initial running version number of the operation is upgraded to the system version of the first target upgrade version number; the offline communication cost is reduced, and the system upgrade efficiency is improved; during the binary upgrade process, as long as the number of downtime nodes does not exceed the system The number of Byzantine nodes that can be tolerated, even if there are nodes with different binary versions, the blockchain system can still provide consensus services normally; making the system upgrade process generally controllable.
  • Fig. 5 shows a structural block diagram of the block chain upgrade device provided by the embodiment of the present application. part.
  • the device includes:
  • the processing unit 51 is configured to determine the first target supported version number of the blockchain system after the participant node in the blockchain system updates the initial binary program to the target binary program;
  • a calculation unit 52 configured to calculate the first target upgrade version number of the blockchain system according to the first target support version number
  • the upgrade unit 53 is configured to upgrade the system version of the initial running version number currently running by the blockchain system to the first target upgrade version when the voting result of the participant node on the system upgrade proposal transaction is passed The system version of the number;
  • the upgrade proposal transaction is initiated by a chain-level administrator account
  • the system version of the first target support version number is the system version compatible with the target binary program
  • the first target support version number includes the An initial running version number and the first target upgrade version number
  • the first target upgrade version number is higher than the initial running version number
  • the participant node is a node participating in the consensus mechanism in the block chain system.
  • the first target supported version number of the blockchain system is determined; according to the first target supported version No., calculate the first target upgrade version number shared by the participant nodes in the blockchain system; when the voting result of the participant node on the system upgrade proposal transaction is passed, the current The system version of the initial running version number of the operation is upgraded to the system version of the first target upgrade version number; the offline communication cost is reduced, and the system upgrade efficiency is improved; during the binary upgrade process, as long as the number of downtime nodes does not exceed the system The number of Byzantine nodes that can be tolerated, even if there are nodes with different binary versions, the blockchain system can still provide consensus services normally; it solves the problem that it is easy to fail to reach a consensus or the entire blockchain system is unavailable during the upgrade of the blockchain system , making the system upgrade process generally controllable.
  • the embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in each of the foregoing method embodiments can be realized.
  • An embodiment of the present application provides a computer program product.
  • the computer program product When the computer program product is run on a mobile terminal, the mobile terminal can implement the steps in the foregoing method embodiments when executed.
  • FIG. 6 is a schematic structural diagram of a terminal device 6 provided by an embodiment of the present application.
  • the terminal device 6 of this embodiment includes: at least one processor 60 (only one is shown in FIG. 6), a processor, a memory 61, and a A computer program 62 running on the processor 60, when the processor 60 executes the computer program 62, the steps in the above-mentioned embodiments are realized.
  • the terminal device 6 may be computing devices such as desktop computers, notebooks, palmtop computers, and cloud servers.
  • the terminal device 6 may include, but not limited to, a processor 60 and a memory 61 .
  • FIG. 6 is only an example of the terminal device 6, and does not constitute a limitation to the terminal device 6. It may include more or less components than those shown in the figure, or combine certain components, or different components. , for example, may also include input and output devices, network access devices, and so on.
  • the so-called processor 60 can be a central processing unit (Central Processing Unit, CPU), and the processor 60 can also be other general processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • a general-purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like.
  • the storage 61 may be an internal storage unit of the terminal device 6 in some embodiments, such as a hard disk or memory of the terminal device 6 .
  • the memory 61 may also be an external storage device of the terminal device 6 in other embodiments, such as a plug-in hard disk equipped on the terminal device 6, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, flash memory card (Flash Card), etc. Further, the memory 61 may also include both an internal storage unit of the terminal device 6 and an external storage device.
  • the memory 61 is used to store operating system, application program, boot loader (BootLoader), data and other programs, such as the program code of the computer program.
  • the memory 61 can also be used to temporarily store data that has been output or will be output.
  • the integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the procedures in the methods of the above embodiments in the present application can be completed by instructing related hardware through computer programs, and the computer programs can be stored in a computer-readable storage medium.
  • the computer program When executed by a processor, the steps in the above-mentioned various method embodiments can be realized.
  • the computer program includes computer program code, and the computer program code may be in the form of source code, object code, executable file or some intermediate form.
  • the computer-readable medium may at least include: any entity or device capable of carrying computer program codes to a photographing device/terminal device, a recording medium, a computer memory, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), electrical carrier signals, telecommunication signals, and software distribution media.
  • ROM read-only memory
  • RAM random access memory
  • electrical carrier signals telecommunication signals
  • software distribution media Such as U disk, mobile hard disk, magnetic disk or optical disk, etc.
  • computer readable media may not be electrical carrier signals and telecommunication signals under legislation and patent practice.
  • the disclosed device/network device and method may be implemented in other ways.
  • the device/network device embodiments described above are only illustrative.
  • the division of the modules or units is only a logical function division.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请适用于计算机应用技术领域，提供了一种升级区块链系统的方法、装置及终端设备，该方法包括：在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；根据所述第一目标支持版本号，计算所述区块链系统中所述参与方节点共有的第一目标升级版本号；在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本。通过本申请可以解决区块链系统升级过程中容易出现区块链系统无法达成共识或整个区块链系统不可用的问题，可以提高区块链系统的升级效率。

Description

升级区块链系统的方法、装置及终端设备
本申请要求于2021年10月19日在中国专利局提交的、申请号为202111214650.2、发明名称为“升级区块链系统的方法、装置及终端设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机应用技术领域，具体涉及一种升级区块链系统的方法、装置及终端设备。
 背景技术
区块链系统作为一个分布式账本，可以由多个参与方节点组成。当区块链系统存在缺陷或新增功能时，可以通过系统升级的方式进行修复或更新。
然而，目前在区块链系统升级过程中，由于参与方节点的升级时间难以统一，使得区块链系统中可能同时存在不同运行版本的节点；由于升级时间不一致或版本差异，容易出现区块链系统无法达成共识或整个区块链系统不可用等情况，导致区块链系统升级效率较低。
 技术问题
本申请实施例的目的之一在于：提供一种升级区块链系统的方法、装置及终端设备。
 技术解决方案
本申请实施例采用的技术方案是：
第一方面，提供了一种升级区块链系统的方法，该方法可以包括：
在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；根据所述第一目标支持版本号，计算所述区块链系统中所有所述参与方节点共有的第一目标升级版本号；在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；
其中，所述升级提案交易为链级管理员账户发起的，所述第一目标支持版本号的系统版本为所述目标二进制程序所兼容的系统版本，所述第一目标支持版本号包括所述初始运行版本号和所述第一目标升级版本号，所述第一目标升级版本号高于所述初始运行版本号，所述参与方节点为所述区块链系统中参与共识机制的节点。
第二方面，提供了一种升级区块链系统的装置，该装置可以包括：
处理单元，用于在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；
计算单元，用于根据所述第一目标支持版本号，计算所述区块链系统的第一目标升级版本号；
升级单元，用于在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；
其中，所述升级提案交易为链级管理员账户发起的，所述第一目标支持版本号的系统版本为所述目标二进制程序所兼容的系统版本，所述第一目标支持版本号包括所述初始运行版本号和所述第一目标升级版本号，所述第一目标升级版本号高于所述初始运行版本号，所述参与方节点为所述区块链系统中参与共识机制的节点。
第三方面，提供一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现第一方面所述的方法。
第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的方法。
第五方面，提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面所述的方法。
 有益效果
本申请实施例提供的升级区块链系统的方法的有益效果在于：通过本申请，在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；根据所述第一目标支持版本号，计算所述区块链系统中所述参与方节点共有的第一目标升级版本号；在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；通过本申请，参与方节点更新的目标二进制程序可以兼容区块链系统的初始运行版本，区块链系统升级之前以初始版本运行，可以保证区块链系统在升级之前共识机制及可用性，将二进制程序提前更新完成，在确定出第一目标升级版本后，直接进行系统版本的更新，提高了区块链系统升级效率；从而解决了升级区块链系统过程中容易出现无法达成共识或整个区块链系统不可用的问题，提高了区块链系统的升级效率；具有较强的易用性与实用性。
 附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或示范性技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1是本申请一实施例提供的应用场景的系统架构示意图；
图2是本申请一实施例提供的区块链升级方法的流程示意图；
图3是本申请一实施例提供的升级过程节点示意图；
图4是本申请另一实施例提供的升级过程节点示意图；
图5是本申请一实施例提供的区块链升级装置的结构示意图；
图6是本申请实施例提供的终端设备的结构示意图。
 本发明的实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。
应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
联盟区块链是由多家企业或机构共同参与计算的分布式账本，参与方都至少部署了一个区块链节点，用于同步全量区块链数据，以及参与账本的计算和共识，该包括多个参与方的系统可以成为区块链系统。
当区块链系统存在缺陷时，针对修复后不存在无法兼容问题的简单缺陷，可以通过开发人员增加新的节点二进制包（修复后的二进制程序），区块链系统中的参与方可以自行选择时间进行二进制包的替换即可完成修复，无需进行整个区块链系统的升级。
然而，当区块链系统出现交易执行逻辑变更、协议变更、功能新增等情况时，则需要进行整个区块链系统的升级。
联盟区块链系统升级过程中，由于参与方较多，并且存在一定的地理隔离或机构隔离，多个参与方节点难以线下协调出一直的系统升级时间，各方升级时间错开，将导致区块链系统里同时存在历史版本的节点和更新版本的节点，由于版本的差异，可能存在版本差异的节点对同一个区块的执行结果不同，进而也无法达成共识等严重情况；并且在所有参与方节点均完成二进制升级之前，整个区块链系统可能处于不可用状态，从而无法保证升级过程中持续为上层应用提供共识记账服务。
目前，针对联盟区块链系统升级的方法包括线下系统升级和线上系统升级。
其中，线下系统升级需要多个参与方协调出一个大家都可以接受的升级周期，在该升级周期内，停止区块链系统中所有应用服务，待所有参与方系欸但的二进制程序都完成替换，并且重启后的区块链系统正常运行才确认升级成功。该线下升级方式，线下沟通成本较大，很难协商出一致的升级周期，并且在进行二进制程序的替换过程中各个参与方需要保持联系，且在所有参与方节点都完成二进制程序的替换后，才可以查看本地节点是否可以正常运行；同时在升级过程中，可能存在不同的二进制程序版本，从而使得整个区块链系统可能无法正常提供区块链服务。
而线上系统升级则需要区块链系统获取用户提出的系统升级提案交易，在各个参与方节点对该系统升级提案交易的投票通过后，执行该系统升级提案交易。在执行过程中，参与方节点需要通过网络请求从远程自动获取升级需要的二进制文件和升级脚本，并与其他参与方节点对比二进制文件的哈希值，哈希值一致才执行升级脚本，进行区块链系统的升级。该线上系统升级由于各个参与方节点的环境差异及复杂性，可能存在网络请求二进制文件失败的风险；而且升级脚本负责停止节点旧二进制程序的运行进程，启动节点新二进制程序的运行进程，使得可能存在有的节点的升级脚本执行成功，有的执行失败的情况，在节点出现错误的数量超过区块链系统所能支持的拜占庭节点的个数时，区块链系统将会处于不可用的状态。
本申请实施例中的升级区块链系统的方法，可以实现参与方节点多个系统版本的兼容性，通过线上版本管理和版本协商，减少了线下沟通成本，提高了区块链系统升级的效率；同时保证了区块链系统在升级过程中，还可以生成新的区块，持续为上层应用提供服务。
请参见图1，图1是本申请一实施例提供的应用场景的系统架构示意图。区块链系统是一个分布式账本，是由多个参与方节点组成的网络集群，如图1所示，该区块链系统包括参与方节点1至7，每个参与方节点可以包括节点级版本的模块（例如通信网络模块）和链级版本的模块（例如共识算法模块、执行引擎模块、虚拟机模块以及密码学模块等）。
在一些实施例中，各个参与方节点进行二进制程序升级的时间可以均不相等，因此需要保证区块链系统中的各个参与方的数据兼容性、协议兼容性以及通信兼容性等。由于区块链系统为包括通信网络模块、共识算法模块、执行引擎模块、虚拟模块以及密码学模块等组成的系统，通过将区块链系统的各个模块对应的系统版本划分为节点级版本和链级版本，对各个模块对应的系统版本进行管理，实现区块链系统升级过程中各个模块的兼容性。
其中，节点级版本是指区块链系统中参与方节点之间通信交互不受共识机制约束的模块对应的系统版本，相应的版本号不需要记录到区块链的账本上，仅需通信的两个节点协商出该模块共有的最大版本号，以该最大版本号所定义的逻辑运行。链级版本是指参与方节点之间通信交互受共识机制约束的模块对应的系统版本，相应的版本号需要记录到区块链的账本上，基于所有参与方节点通过共识机制协商出共有的最大版本号，各个参与方节点以该最大版本号定义的逻辑运行。
示例性的，共识机制约束包括共识法定数量Quorum约束。该共识Quorum约束为在类实用拜占庭容错（Practical Byzantine Fault Tolerance，PBFT）联盟链共识算法里，当节点广播一个共识消息后，需要收到法定数量Quorum个节点的回复才能继续往下执行的机制。
需要说明的是，一般链级版本的模块或协议，会影响参与方节点的交易执行逻辑、交易执行结果等，因此本申请在区块链系统升级过程中，针对区块链系统中链级版本的模块进行管理，实现各模块对应的系统版本的兼容性。
基于上述情况，本申请实施例提供了一种升级区块链系统的方法，可以实现区块链系统升级过程中各模块的兼容性，提高区块链系统的升级效率。下面通过本申请实施例介绍该方法实现的具体过程。
请参见图2，图2是本申请一实施例提供的区块链升级方法的流程示意图。如图2所示，该方法包括以下步骤：
步骤S201，在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号。
在一些实施例中，该方法的执行主体可以是区块链系统中的参与方节点对应的终端设备，该终端设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。
在一些实施例中，二进制程序为多行字符编写的数据或程序指令的程序文件，为用于支撑区块链系统运行的程序文件。区块链系统在进行线上升级之前，各个参与方节点需要进行二进制程序的线下替换升级。由于二进制程序的升级需要参与方节点停止线上运行，为保证区块链系统升级过程中不受影响，且符合区块链系统的共识机制可容的拜占庭节点的数量，各个参与方节点的线下升级需要按轮次进行。
应理解，区块链系统在升级过程中，区块链系统中的参与方节点对应的终端设备可以接收用户输入的升级指令，终端设备执行该升级指令，将区块链系统中的初始二进制程序升级替换为目标二进制程序。
在一些实施例中，所述区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序，包括：
所述区块链系统中预设数量的所述参与方节点按轮次停止线上运行，并进行数据备份；预设数量的所述参与方节点线下将所述初始二进制程序替换为所述目标二进制程序。
其中，所述预设数量小于或等于所述区块链系统的所述共识机制容错的参与方节点数量；或者，所述预设数量小于或等于所述区块链系统中分区网络中所述共识机制容错的参与方节点数量。
第一种情况，如图3所示，该区块链系统的参与方节点为节点1至节点7。在该由七个节点组成的区块链共识网络里，根据冗余拜占庭容错（Redundant Byzantine Fault Tolerance，RBFT）共识算法的公式可知系统可容拜占庭节点数量f=2，即同一时刻最多只能存在两个节点停机，超过该数量，区块链系统将无法进行共识。因此需要按轮次对该区块链共识网络里的节点进行二进制程序的更新。
示例性的，节点在停止线上运行之前对应支持的系统版本为初始二进制程序所兼容的系统版本，例如在第一轮升级之前节点1至节点7对应的支持版本为V1.0版本；线下升级后对应支持的系统版本为目标二进制程序所兼容的版本，例如在第一轮升级后节点1和节点2所对应的支持版本包括V1.0版本和V2.0版本。
如图3所示，该区块链共识网络里的最初七个节点都只支持v1.0协议，区块链系统运行的也是v1.0版本，需要将系统版本升级为v2.0版本，则通过每个轮次停止两个节点，线下升级二进制程序，通过四轮次的升级，使整个区块链共识网络里的所有节点完成对二进制程序的升级替换。
如图3所示，第一轮二进制程序升级由节点1和节点2进行，升级完成后，节点1和节点2支持v1.0版本和v2.0版本，由于整个系统运行的系统版本依旧是v1.0版本，因此节点1和节点2运行的也是v1.0版本。第二轮二进制程序升级由节点3和节点4进行，升级完成后，节点3和节点4支持v1.0版本和v2.0版本，由于整个系统运行的依旧是v1.0版本，因此节点3和节点4运行的也是v1.0版本。第三轮升级、第四轮升级同理。
第二种情况，如图4所示，当区块链系统包括多个分区网络时，还可以按分区网络进行二进制程序的升级替换。
如图4所示，在多分区网络的区块链系统里，每一个分区网络都是一条独立的应用链，分区网络1由节点1、节点2、节点3和节点4组成，分区网络2由节点4、节点5、节点6和节点7组成；其中，节点4处于两个分区网络。
示例性的，最初分区网络1与分区网络2运行的系统版本均为v1.0版本，之后分区网络1要升级到v2.0版本。首先，分区网络1的节点进行线下二进制程序的升级替换，成功启动后，重新初始化分区网络1里节点的链上的支持版本，之后通过系统升级提案将系统版本升级到v2.0版本。
其中，分区网络1的整个升级过程对于分区网络2来说几乎无感知，只有节点4发生了短暂的停机重启，在共识算法的可容拜占庭数量f的区块链网络里，节点4的短暂停机不会对分区网络2的业务运行造成影响。最后，两个分区运行的链级版本不一样，分区1运行的是v2.0版本的协议，分区2运行的是v1.0版本的协议。节点4同时支持v1.0和v2.0版本，在分区1中运行v2.0版本，在分区2中运行v1.0版本。
应理解，针对第二种情况，存在多个分区网络的区块链系统，在分区网络1的系统版本升级过程中，进行线下二进制程序的替换时，可以是按第一种情况中的节点按轮次进行二进制程序的线下升级替换，经过多个轮次分区网络中的所有节点完成线下二进制程序的升级。
另外，在进行二进制程序的升级替换之前，节点还进行数据备份，该数据备份包括对系统版本的备份以及其他交易执行结果数据等的备份。在替换二进制程序之后，该节点更改相应的配置，例如重新配置系统参数等。
示例性的，区块链系统中属于链级版本的版本号可以记录在创世genesis区块中，对区块链系统升级之前的创世链进行初始化；其中，记录在创世genesis区块中的版本号包括该创世节点支持的链级版本号列表（所有支持版本的版本号）和正在运行使用的链级版本号（运行版本的版本号）。以便于后续升级过程中对版本进行查询或参考。
可理解的，在进行创世链初始化时，将区块链系统中链级版本号记录在创世区块中的同时，区块链系统的账本中记录系统的初始运行版本和初始支持版本，在区块链系统中节点完成二进制程序的线下升级，启动后，账本中重新记录目标二进制程序所兼容的支持版本。
需要说明的是，七个节点完成二进制程序的升级替换，区块链系统启动运行的依旧是账本里记录的初始运行版本（如v1.0版本）。从而保证了区块链系统在升级过程中各个模块的兼容性，满足区块链系统的共识机制，区块链系统中即使存在可兼容不同系统版本的二进制程序，该区块链共识网络仍可以正常提供共识服务。
另外，一般情况下区块链系统中的各个节点升级后的目标二进制程序相同，每个节点所支持的系统版本一致。但也可能存在替换了不同的目标二进制程序，使得节点之间所兼容的系统版本可能不同，具体还可以根据实际应用需要进行设定。如果存在替换错误的情况，后续还可以进行纠错处理；从而在整体的升级过程中，均减少了线下沟通的成本。
示例性的，第一目标支持版本号为区块链系统中各个参与方节点对应的支持版本的版本号的集合，或者整个区块链系统对应的支持版本的版本号。例如图3中的最初七个节点升级后都只支持V1.0版本和V2.0版本，则区块链系统对应的该第一目标支持版本号包括V1.0和V2.0。
在一些实施例中，所述确定所述区块链系统的第一目标支持版本号，包括：
所述参与方节点获取所述链级管理员账户针对支持版本号发起的上链请求；根据所述上链请求，所述区块链系统中的每个所述参与方节点生成包含自身所述支持版本号的交易，并向所述区块链系统中的其他参与方节点广播所述交易；所有所述参与方节点在执行接收到的包含所述支持版本号的所述交易过程中，将所述交易中的所述支持版本号存储到账本中，得到所述区块链系统的所述第一目标支持版本号。
在一些实施例中，链级管理员账户可以为区块链系统中被授权的一个参与方节点上设置的账户，还可以是被授权的创世区块上设置账户，或者级别更高且被授权的区块中设置的账户；通过该账户可以向区块链系统中的参与方节点发起上链请求。该上链请求中可以包括针对各个节点的支持版本的参量。区块链系统中的各个参与方节点在接收到该上链请求后，基于自身的节点账户构造一项包含自己支持版本的交易，并向整个区块链系统中的节点进行广播。
示例性的，在区块链系统中的参与方节点生成交易并向其他参与方节点广播后，接收到交易的参与方节点将交易缓存在交易池，参与方节点中的主节点可以从交易池中取出交易池中的交易，并将一个或多个交易打包成区块后，向其他参与方节点广播，参与方节点对该区块进行共识，在该区块的通过区块链系统中各参与方节点的共识机制后，各参与方节点执行该区块里的交易，在执行交易的过程中，修改账本状态，将交易中的支持版本号存储到账本中。
应理解，该区块链系统中的每个参与方节点作为执行主体，可以为该交易的发起方，也可以为该交易的接收方。
示例性的，当参与方节点执行该交易时，将接收到的交易中的支持版本存储到账本中。待参与方节点完成该交易后，即可确定该区块链系统对应的第一目标支持版本号。例如图3所示，在进行升级之前，根据参与方节点执行的交易，可以确定该区块链系统对应的第一目标支持版本号包括V1.0和V2.0。
在一些实施例中，所述向所述区块链系统中的其他参与方节点广播所述交易之后，所述方法还包括：
在执行所述交易过程中，所述参与方节点对广播所述交易的参与方节点的权限进行识别；若广播所述交易的参与方节点为所述区块链系统中参与所述共识机制的节点，所述参与方节点将所有所述交易中的所述支持版本号存储到账本中。
示例性的，在区块链系统中的各个参与方节点执行交易过程中，接收到交易时，还需要对该交易的发起方进行权限检查，若该交易的发起方为该区块链系统共识网络中的一员，则继续执行该交易。否则，该交易接收方节点返回该笔交易执行失败的提示，并不对账本进行修改。
步骤S202，根据所述第一目标支持版本号，计算所述区块链系统中所述参与方节点共有的第一目标升级版本号。
在一些实施例中，在区块链系统确定所支持的第一目标支持版本号后，可以基于该第一目标支持版本号，确定出区块链系统对应的第一目标升级版本号。
例如，一个二进制程序可以兼容多个系统版本，比如二进制程序A兼容的系统版本为 V1.0和V1.1；之后经过开发增加了一些新特性，系统版本为V1.2，则二进制程序B兼容的系统版本为 V1.0、V1.1和V1.2。即区块链系统中的参与方节点在二进制程序A时，所支持的系统版本包括V1.0版本和V1.1版本；在将二进制程序A升级替换成二进制程序B时，该区块链系统中参与方节点所支持的系统版本包括V1.0版本、V1.1版本和V1.2版本，即可以确定第一目标支持版本包括V1.0版本、V1.1版本和V1.2版本。根据该第一目标支持版本，可以计算出各个参与方节点共有的第一目标升级版本号，例如V1.2版本。
在一些实施例中，在所述根据所述第一目标支持版本号，计算所述区块链系统的第一目标升级版本号之后，所述方法还包括：
若所述第一目标升级版本号高于所述初始运行版本号，则将账本中记录的初始升级版本号替换为所述第一目标升级版本号；若所述第一目标升级版本号不高于所述初始运行版本号，则保留账本中记录的初始升级版本号。
在一些实施例中，区块链系统或参与方节点的账本中记录有系统升级之前的初始运行版本号；区块链系统可能经过多次系统升级，则在账本中还可能记录上次系统升级时的初始升级版本号，相应的，系统升级后所运行的系统版本的版本号也是该初始升级版本号；那么，在下一次升级时，若所述第一目标升级版本号高于所述初始运行版本号（也即初始升级版本号），将重新计算出的第一目标升级版本号替换原来的初始升级版本号。
步骤S203，在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本。
在一些实施例中，该升级提案交易为被授权的链级管理员账户发起的，该第一目标支持版本号的系统版本为目标二进制程序所兼容的系统版本，第一目标支持版本号包括初始运行版本号和第一目标升级版本号，第一目标升级版本号高于初始运行版本号，参与方节点为所述区块链系统中参与共识机制的节点。
在一些实施例中，在所述参与方节点对系统升级提案交易的投票结果为通过之后，所述方法还包括：
在执行所述系统升级提案交易过程中，若所述参与方节点的账本中所述第一目标升级版本号对应的有效值非空且所述第一目标升级版本号高于所述初始运行版本号，则将所述初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本。
在一些实施例中，链级管理员向区块链系统发起一笔系统升级提案交易，该区块链系统的参与方节点投票通过后，执行该系统升级提案交易。在执行过程中，如果当前账本里第一目标升级版本为非空值，并且该值大于区块链系统当前运行的系统版本（对应初始运行版本号），则重置当前运行的初始运行版本号的系统版本为第一目标升级版本号的系统版本，完成系统升级。否则，该系统升级提案交易执行失败，系统不执行升级操作。
示例性的，一个二进制程序可以兼容多个系统版本，比如二进制程序A支持的系统版本为 V1.0和V1.1，假设启动后当前区块链系统运行的是V1.1版本。之后经过开发增加了一些新特性，系统版本为V1.2，则二进制程序B支持的系统版本为 V1.0、V1.1和V1.2，启动后，系统运行的还是 v1.1。然后系统升级提案交易的经过投票同意后，区块链系统的系统版本升级到 v1.2。
如图3所示，在第四轮升级后，各个节点线上执行系统升级提案交易，将系统的运行版本重置为V2.0版本。
在一些实施例中，在所述将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本之前，所述方法还包括：
若所述区块链系统中加入新节点，则清空所述区块链系统的账本中记录的所述第一目标升级版本号；重新确定加入新节点后的区块链系统的第二目标支持版本号；根据所述第二目标支持版本号，计算所述区块链系统的第二目标升级版本号，并将所述第二目标升级版本号记录在账本中；相应的，在所述参与方节点对链级管理员账户重新发起的系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第二目标升级版本号的系统版本。
在一些实施例中，重新确定加入新节点后的区块链系统的第二目标支持版本号，包括：
所述新节点获取所述链级管理员账户针对支持版本号发起的上链请求；根据所述上链请求，所述新节点生成包含自身对应的所述支持版本的交易，并向所述区块链系统中的其他参与方节点广播所述交易；在执行所述交易的过程中，将所述交易中的所述支持版本号进行存储，更新账本中的支持版本号，得到所述第二目标支持版本号。
在一些实施例中，如果有新节点请求加入该区块链系统的共识网络，在该区块链系统中的其他旧节点投票同意该新节点加入后，该新节点信息被记录到该区块链系统的内置合约中。
示例性的，由于新节点的加入，该区块链系统的可升级版本（第一目标升级版本）可能发生变化，需要重新计算。区块链系统清空当前账本的中第一目标升级版本号。新节点接收被授权的链级管理员账户发送的针对支持版本的上链请求，新节点对应的节点账户构造一笔携带自己的支持版本号的交易广播到全网，更新账本里的第一目标支持版本号，得到更新后的第二目标支持版本号，根据第二目标支持版本号计算得到第二目标升级版本号。从而可以保证区块链系统升级过程中，在有新的区块节点加入区块链系统时，可以持续为上层应用提供服务。
在一些实施例中，参与方节点包括链级版本模块；在将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本之后，所述方法还包括：
所述区块链系统中的所述参与方节点根据升级后的系统版本变更各个链级版本模块的运行逻辑。
示例性的，该区块链系统中的各个参与方节点重置完系统的运行版本（目标升级版本）以后，将该运行版本的版本号通知给各个链级版本的协议或模块，进行逻辑的变更。
在一些实施例中，针对区块链系统中的节点级版本的模块或协议的管理过程，在各个参与方节点的上层的节点级协议或模块相互通信时，若存在版本差异，该方法还包括：
所述参与方节点向网络模块注册所述节点级版本模块所支持的系统版本的版本号列表；在通过所述网络模块接收到建立网络连接请求时，通过所述网络模块对发起所述建立网络连接请求的参与方节点进行身份验证；在身份验证通过后，通过网络模块计算出进行网络连接的各个所述参与方节点中的节点级模块所共有的最大版本号；通过所述网络模块向进行网络连接的所述参与方节点中的所述节点级版本模块发送通知，所述通知用于指示进行网络连接的所述参与方节点中的节点级模块基于所述最大版本号进行通信。
其中，网络模块可以为接收到网络连接请求的参与方节点中的模块。
示例性的，区块链系统中上层的各个节点级协议或模块向网络模块注册该协议或模块所支持的系统版本的版本号列表；网络模块接收到一项网络连接，完成发起该网络连接的参与方节点的身份验证后，进入协议版本协商；通过协议版本协商分别计算出这两个节点的节点级协议或模块共有的最大版本号；网络模块将协商结果返回给上层的各个节点级协议或模块；上层的节点级协议或模块记录网络模块协议版本协商的结果，后续该两个参与方节点通信均以该共有的最大版本号的系统版本定义的逻辑运行。
其中，上述的网络模块可以为相互通信的两个参与方节点的中的模块，上述流程的执行主体可以是区块链系统中接收网络连接的参与方节点。
另外，针对可能与多个节点建立了网络连接的本地节点，由于网络通信不受共识Quorum约束，每条网络连接都相互独立，本地节点可能与不同节点的通信使用不同的节点级版本。
通过本申请实施例，在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；根据所述第一目标支持版本号，计算所述区块链系统中所述参与方节点共有的第一目标升级版本号；在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；减少了线下沟通成本，提高了系统升级效率；二进制升级过程中，只要停机的节点数量不超过系统所能容忍的拜占庭节点数量，即使存在不同二进制版本的节点，区块链系统依旧可以正常提供共识服务；使系统升级过程总体可控。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
对应于上文实施例所述的区块链升级方法，图5示出了本申请实施例提供的区块链升级装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。
参照图5，该装置包括：
处理单元51，用于在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；
计算单元52，用于根据所述第一目标支持版本号，计算所述区块链系统的第一目标升级版本号；
升级单元53，用于在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；
其中，所述升级提案交易为链级管理员账户发起的，所述第一目标支持版本号的系统版本为所述目标二进制程序所兼容的系统版本，所述第一目标支持版本号包括所述初始运行版本号和所述第一目标升级版本号，所述第一目标升级版本号高于所述初始运行版本号，所述参与方节点为所述区块链系统中参与共识机制的节点。
通过本申请实施例，在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；根据所述第一目标支持版本号，计算所述区块链系统中所述参与方节点共有的第一目标升级版本号；在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；减少了线下沟通成本，提高了系统升级效率；二进制升级过程中，只要停机的节点数量不超过系统所能容忍的拜占庭节点数量，即使存在不同二进制版本的节点，区块链系统依旧可以正常提供共识服务；解决了升级区块链系统过程中容易出现无法达成共识或整个区块链系统不可用的问题，使系统升级过程总体可控。
需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。
本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。
图6为本申请一实施例提供的终端设备6的结构示意图。如图6所示，该实施例的终端设备6包括：至少一个处理器60（图6中仅示出一个）处理器、存储器61以及存储在所述存储器61中并可在所述至少一个处理器60上运行的计算机程序62，所述处理器60执行所述计算机程序62时实现上述实施例中的步骤。
所述终端设备6可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该终端设备6可包括，但不仅限于，处理器60、存储器61。本领域技术人员可以理解，图6仅仅是终端设备6的举例，并不构成对终端设备6的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。
所称处理器60可以是中央处理单元(Central Processing Unit，CPU)，该处理器60还可以是其他通用处理器、数字信号处理器 (Digital Signal Processor，DSP)、专用集成电路 (Application Specific Integrated Circuit，ASIC)、现成可编程门阵列 (Field-Programmable Gate Array，FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器61在一些实施例中可以是所述终端设备6的内部存储单元，例如终端设备6的硬盘或内存。所述存储器61在另一些实施例中也可以是所述终端设备6的外部存储设备，例如所述终端设备6上配备的插接式硬盘，智能存储卡（Smart Media Card, SMC），安全数字（Secure Digital, SD）卡，闪存卡（Flash Card）等。进一步地，所述存储器61还可以既包括所述终端设备6的内部存储单元也包括外部存储设备。所述存储器61用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器61还可以用于暂时地存储已经输出或者将要输出的数据。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中，应该理解到，所揭露的装置/网络设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/网络设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (13)

  1. 一种升级区块链系统的方法，其特征在于，所述方法包括：
    在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；
    根据所述第一目标支持版本号，计算所述区块链系统中所述参与方节点共有的第一目标升级版本号；
    在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；
    其中，所述升级提案交易为链级管理员账户发起的，所述第一目标支持版本号的系统版本为所述目标二进制程序所兼容的系统版本，所述第一目标支持版本号包括所述初始运行版本号和所述第一目标升级版本号，所述第一目标升级版本号高于所述初始运行版本号，所述参与方节点为所述区块链系统中参与共识机制的节点。
  2. 如权利要求1所述的方法，其特征在于，所述区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序，包括：
    所述区块链系统中预设数量的所述参与方节点按轮次停止线上运行，并进行数据备份；
    预设数量的所述参与方节点线下将所述初始二进制程序替换为所述目标二进制程序；
    其中，所述预设数量小于或等于所述区块链系统的所述共识机制容错的参与方节点数量；或者，所述预设数量小于或等于所述区块链系统中分区网络中所述共识机制容错的参与方节点数量。
  3. 如权利要求1所述的方法，其特征在于，所述确定所述区块链系统的第一目标支持版本号，包括：
    所述参与方节点获取所述链级管理员账户针对支持版本号发起的上链请求；
    根据所述上链请求，所述区块链系统中的每个所述参与方节点生成包含自身所述支持版本号的交易，并向所述区块链系统中的其他参与方节点广播所述交易；
    所有所述参与方节点在执行接收到的包含所述支持版本号的所述交易的过程中，将所述交易中的所述支持版本号存储到账本中，得到所述区块链系统的所述第一目标支持版本号。
  4. 如权利要求3所述的方法，其特征在于，所述向所述区块链系统中的其他参与方节点广播所述交易之后，所述方法还包括：
    在执行所述交易过程中，所述参与方节点对广播所述交易的参与方节点的权限进行识别；
    若广播所述交易的参与方节点为所述区块链系统中参与所述共识机制的节点，所述参与方节点将所有所述交易中的所述支持版本号存储到账本中。
  5. 如权利要求1所述的方法，其特征在于，在所述参与方节点对系统升级提案交易的投票结果为通过之后，所述方法还包括：
    在执行所述系统升级提案交易过程中，若所述参与方节点的账本中所述第一目标升级版本号对应的有效值非空且所述第一目标升级版本号高于所述初始运行版本号，则将所述初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本。
  6. 如权利要求1所述的方法，其特征在于，在所述根据所述第一目标支持版本号，计算所述区块链系统的第一目标升级版本号之后，所述方法还包括：
    若所述第一目标升级版本号高于所述初始运行版本号，则将账本中记录的初始升级版本号替换为所述第一目标升级版本号；
    若所述第一目标升级版本号不高于所述初始运行版本号，则保留账本中记录的初始升级版本号。
  7. 如权利要求1所述的方法，其特征在于，在所述将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本之前，所述方法还包括：
    若所述区块链系统中加入新节点，则清空所述区块链系统的账本中记录的所述第一目标升级版本号；
    重新确定加入新节点后的区块链系统的第二目标支持版本号；
    根据所述第二目标支持版本号，计算所述区块链系统的第二目标升级版本号，并将所述第二目标升级版本号记录在账本中；
    相应的，在所述参与方节点对链级管理员账户重新发起的系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第二目标升级版本号的系统版本。
  8. 如权利要求7所述的方法，其特征在于，重新确定加入新节点后的区块链系统的第二目标支持版本号，包括：
    所述新节点获取所述链级管理员账户针对支持版本号发起的上链请求；
    根据所述上链请求，所述新节点生成包含自身对应的所述支持版本的交易，并向所述区块链系统中的其他参与方节点广播所述交易；
    在执行所述交易的过程中，将所述交易中的所述支持版本号进行存储，更新账本中的支持版本号，得到所述第二目标支持版本号。
  9. 如权利要求1至8任一项所述的方法，其特征在于，所述参与方节点包括链级版本模块；
    在将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本之后，所述方法还包括：
    所述区块链系统中的所述参与方节点根据升级后的系统版本变更各个所述链级版本模块的运行逻辑。
  10. 如权利要求1至8任一项所述的方法，其特征在于，所述参与方节点包括节点级版本模块，所述方法还包括：
    所述参与方节点向网络模块注册所述节点级版本模块所支持的系统版本的版本号列表；
    在通过所述网络模块接收到建立网络连接请求时，通过所述网络模块对发起所述建立网络连接请求的参与方节点进行身份验证；
    在身份验证通过后，通过网络模块计算出进行网络连接的各个所述参与方节点中的所述节点级版本模块所共有的最大版本号；
    通过所述网络模块向进行网络连接的所述参与方节点中的节点级模块发送通知，所述通知用于指示进行网络连接的所述参与方节点中的节点级模块基于所述最大版本号进行通信。
  11. 一种升级区块链系统的装置，其特征在于，所述装置包括：
    处理单元，用于在区块链系统中的参与方节点将初始二进制程序更新为目标二进制程序后，确定所述区块链系统的第一目标支持版本号；
    计算单元，用于根据所述第一目标支持版本号，计算所述区块链系统的第一目标升级版本号；
    升级单元，用于在所述参与方节点对系统升级提案交易的投票结果为通过时，将所述区块链系统当前运行的初始运行版本号的系统版本升级为所述第一目标升级版本号的系统版本；
    其中，所述升级提案交易为链级管理员账户发起的，所述第一目标支持版本号的系统版本为所述目标二进制程序所兼容的系统版本，所述第一目标支持版本号包括所述初始运行版本号和所述第一目标升级版本号，所述第一目标升级版本号高于所述初始运行版本号，所述参与方节点为所述区块链系统中参与共识机制的节点。
  12. 一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至10任一项所述的方法。
  13. 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至10任一项所述的方法。
PCT/CN2022/111761 2021-10-19 2022-08-11 升级区块链系统的方法、装置及终端设备 WO2023065788A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22789829.3A EP4195033A4 (en) 2021-10-19 2022-08-11 METHOD AND APPARATUS FOR UPGRADING BLOCKCHAIN SYSTEM, AND TERMINAL DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111214650.2 2021-10-19
CN202111214650.2A CN113641391B (zh) 2021-10-19 2021-10-19 升级区块链系统的方法、装置及终端设备

Publications (1)

Publication Number Publication Date
WO2023065788A1 true WO2023065788A1 (zh) 2023-04-27

Family

ID=78427330

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/111761 WO2023065788A1 (zh) 2021-10-19 2022-08-11 升级区块链系统的方法、装置及终端设备

Country Status (3)

Country Link
EP (1) EP4195033A4 (zh)
CN (1) CN113641391B (zh)
WO (1) WO2023065788A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113641391B (zh) * 2021-10-19 2022-02-18 杭州趣链科技有限公司 升级区块链系统的方法、装置及终端设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050267951A1 (en) * 2004-05-17 2005-12-01 Oracle International Corporation Rolling upgrade of distributed software with automatic completion
CN110798331A (zh) * 2018-08-02 2020-02-14 华为技术有限公司 一种设备升级方法和装置
CN112052021A (zh) * 2020-08-12 2020-12-08 中钞信用卡产业发展有限公司杭州区块链技术研究院 联盟区块链升级的方法、装置、设备及存储介质
CN112162768A (zh) * 2020-10-14 2021-01-01 支付宝(杭州)信息技术有限公司 一种区块链升级方法和系统
CN112650514A (zh) * 2020-12-28 2021-04-13 杭州趣链科技有限公司 联盟链的补丁更新方法、装置、设备及存储介质
CN113641391A (zh) * 2021-10-19 2021-11-12 杭州趣链科技有限公司 升级区块链系统的方法、装置及终端设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112256305B (zh) * 2020-11-04 2022-05-10 暗链科技(深圳)有限公司 一种区块链软件更新方法及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050267951A1 (en) * 2004-05-17 2005-12-01 Oracle International Corporation Rolling upgrade of distributed software with automatic completion
CN110798331A (zh) * 2018-08-02 2020-02-14 华为技术有限公司 一种设备升级方法和装置
CN112052021A (zh) * 2020-08-12 2020-12-08 中钞信用卡产业发展有限公司杭州区块链技术研究院 联盟区块链升级的方法、装置、设备及存储介质
CN112162768A (zh) * 2020-10-14 2021-01-01 支付宝(杭州)信息技术有限公司 一种区块链升级方法和系统
CN112650514A (zh) * 2020-12-28 2021-04-13 杭州趣链科技有限公司 联盟链的补丁更新方法、装置、设备及存储介质
CN113641391A (zh) * 2021-10-19 2021-11-12 杭州趣链科技有限公司 升级区块链系统的方法、装置及终端设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4195033A4

Also Published As

Publication number Publication date
CN113641391A (zh) 2021-11-12
CN113641391B (zh) 2022-02-18
EP4195033A4 (en) 2024-04-24
EP4195033A1 (en) 2023-06-14

Similar Documents

Publication Publication Date Title
CN111183625B (zh) 用于在区块链网络中删除节点的系统和方法
CN111480157B (zh) 用于在区块链网络中添加节点的系统和方法
US10764142B2 (en) Clustered application management with a blockchain
US10754955B2 (en) Authenticating a boot path update
US20200134613A1 (en) Method and Apparatus for Running Smart Contract
US10884879B2 (en) Method and system for computing a quorum for two node non-shared storage converged architecture
EP4083786A1 (en) Cloud operating system management method and apparatus, server, management system, and medium
KR101159322B1 (ko) 오동작 허용 분산 컴퓨팅 시스템에서의 레플리카 세트의효율적인 변경
US20100318610A1 (en) Method and system for a weak membership tie-break
JP2020518887A (ja) 合意システムのダウンタイムの回復
US20070299955A1 (en) Data replication in a distributed system
US10127124B1 (en) Performing fencing operations in multi-node distributed storage systems
WO2018120174A1 (zh) 故障恢复的方法、设备和系统
WO2020232859A1 (zh) 分布式存储系统、数据写入方法、装置和存储介质
JP2020522725A (ja) 合意システムのダウンタイムの回復
CN108932249B (zh) 一种管理文件系统的方法及装置
WO2019184775A1 (zh) 管理数据的存储方法、设备及存储介质
WO2023065788A1 (zh) 升级区块链系统的方法、装置及终端设备
US20200045139A1 (en) Remote procedure call using quorum state store
CN111338857A (zh) 一种拜占庭容错共识协议
US7103639B2 (en) Method and apparatus for processing unit synchronization for scalable parallel processing
CN111813606A (zh) 一种双节点虚拟机容错的方法、系统、设备及介质
CN111090537A (zh) 集群启动方法、装置、电子设备及可读存储介质
CN103780433B (zh) 自愈式虚拟资源配置管理数据架构
CN115698955A (zh) 事务镜像的容错

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 17921515

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2022789829

Country of ref document: EP

Effective date: 20221026

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22789829

Country of ref document: EP

Kind code of ref document: A1