WO2018161901A1 - 一种共识方法及装置 - Google Patents

一种共识方法及装置 Download PDF

Info

Publication number
WO2018161901A1
WO2018161901A1 PCT/CN2018/078169 CN2018078169W WO2018161901A1 WO 2018161901 A1 WO2018161901 A1 WO 2018161901A1 CN 2018078169 W CN2018078169 W CN 2018078169W WO 2018161901 A1 WO2018161901 A1 WO 2018161901A1
Authority
WO
WIPO (PCT)
Prior art keywords
view
node
consensus
master node
blockchain
Prior art date
Application number
PCT/CN2018/078169
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
Priority to KR1020197014424A priority Critical patent/KR102140903B1/ko
Priority to CA3043532A priority patent/CA3043532C/en
Priority to BR112019009591-8A priority patent/BR112019009591B1/pt
Priority to RU2019114226A priority patent/RU2733221C1/ru
Priority to PL18764913T priority patent/PL3525102T3/pl
Priority to MX2019005525A priority patent/MX2019005525A/es
Priority to EP18764913.2A priority patent/EP3525102B1/en
Priority to JP2019527429A priority patent/JP6756918B2/ja
Application filed by 阿里巴巴集团控股有限公司, 唐强 filed Critical 阿里巴巴集团控股有限公司
Priority to ES18764913T priority patent/ES2880448T3/es
Priority to AU2018230202A priority patent/AU2018230202B2/en
Publication of WO2018161901A1 publication Critical patent/WO2018161901A1/zh
Priority to ZA2019/02935A priority patent/ZA201902935B/en
Priority to PH12019501053A priority patent/PH12019501053A1/en
Priority to US16/440,782 priority patent/US10684925B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2033—Failover techniques switching over of hardware resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/805—Real-time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875—Monitoring of systems including the internet

Definitions

  • the present application relates to the field of computer technology, and in particular, to a consensus method and apparatus.
  • a blockchain containing multiple nodes can provide corresponding service services for clients.
  • each node in the blockchain will process the service request of the client, and feed back the processing result to the client.
  • the processing results generated by the independently running nodes may be inconsistent, in order to ensure the client.
  • the terminal can receive the correct processing result, so the consensus between the nodes is realized by using the Practical Byzantine Fault Tolerance (PBFT) algorithm (that is, the nodes can jointly recognize the correct processing result).
  • PBFT Practical Byzantine Fault Tolerance
  • the consensus is usually carried out under the view. Specifically, in one view, one node in the blockchain is used as the primary node, and the other nodes are used as backup nodes. . At this time, the primary node receives the service request of the client, broadcasts the service request to all the backup nodes, and the master node initiates a consensus. The consensus node will process the service request and feed back the processing result to the client.
  • the backup node initiates a view switch, and the view switch initiated by the backup node usually needs to be recognized by other nodes in the view. Specifically, the backup node initiates a view switch request to other nodes (including the master node) in the view, that is, initiates a consensus based on the view switch request to other nodes (the consensus still adopts PBFT, and the consensus process based on the service request) The difference is that in the consensus process for the view switch request, each node will suspend the consensus on the service request, so the consensus based on the view switch request is essentially an additional consensus process). After a certain number of nodes reach a consensus, it will be determined that a backup node becomes the new primary node. The new primary node broadcasts a new view message to complete the view switch.
  • the view switching initiated by the backup node requires an additional consensus process, and the additional consensus process increases the amount of system computation.
  • the consensus process of the view switching needs to wait for a certain number of nodes to confirm before agreeing.
  • the new master node broadcasts new view messages to the outside world, and the entire process will take a certain amount of time.
  • the existing view switching mode not only increases the computational complexity of the system, but also increases the processing time of the service request, resulting in low processing efficiency.
  • the embodiment of the present application provides a consensus method and device, which is used to solve the problem that the current view switching mode increases the operation amount of the blockchain and increases the processing time.
  • a consensus method provided by the embodiment of the present application includes:
  • the blockchain master node monitors the triggering of the view switching condition
  • the blockchain master node selects a successor node
  • the blockchain master node switches the current view to the view that the successor node is the blockchain master node according to the successor node, so that the successor blockchain master node initiates a consensus.
  • a consensus device provided by the embodiment of the present application includes:
  • a monitoring module that monitors triggering of view switching conditions
  • a node determining module when the monitoring module detects a triggering view switching condition, selecting a successor node
  • the view switching module switches the current view to the view of the successor node as the blockchain master node according to the successor node, so that the successor blockchain master node initiates a consensus.
  • the embodiment of the present application provides a consensus method and device.
  • the blockchain master node actively monitors the triggering of the view switching condition. If the view switching condition is triggered, the view switching needs to be performed, and further, the blockchain The master node selects one successor node from other blockchain nodes as the blockchain master node in the next view. Based on this, the blockchain master node performs view switching. In the switched view, the successor node acts as a new node. The blockchain master node performs the processing of the service, and at the same time, the view switching is still performed according to the foregoing procedure. Obviously, the above view switching is initiated by the blockchain master node. This way, the blockchain backup node can avoid the view switching consensus. In other words, the phenomenon of additional consensus can be avoided, thereby reducing the area. The amount of extra operations in the blockchain and the processing time.
  • FIG. 1a is an architecture based on a consensus process provided by an embodiment of the present application
  • FIG. 1b is a consensus process provided by an embodiment of the present application.
  • FIG. 2 is a schematic diagram of a consensus process based on a three-phase protocol in any view according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of an execution process of an application example of view switching according to an embodiment of the present disclosure
  • FIG. 4 is a schematic structural diagram of a consensus device according to an embodiment of the present application.
  • a consensus method is provided.
  • a blockchain master node in any view, after a consensus is completed, a view switch is initiated by the blockchain master node, and the blockchain master node is replaced. There is no need for an additional consensus process.
  • the blockchain master node is simply referred to as a master node
  • the blockchain backup node is simply referred to as a backup node.
  • nodes appears below, which should be understood as the nodes participating in the consensus in the blockchain network.
  • the architecture adopted by the consensus method is as shown in FIG. 1a.
  • the blockchain network includes multiple nodes, and multiple clients can perform business interaction with the blockchain.
  • the application type of the blockchain network may be a link chain and/or a private chain, and can provide a service service to a user.
  • the nodes include, but are not limited to, servers, computers, mobile terminals, and the like having computing processing functions.
  • the client may include a browser, an application, and the like, and the client may run in a terminal, a server, or a database, and is not specifically limited herein.
  • FIG. 1b Based on the relationship architecture shown in FIG. 1a, a consensus process provided by the embodiment of the present application is as shown in FIG. 1b, and the process specifically includes the following steps:
  • S101 The master node monitors triggering of the view switching condition.
  • the view switching condition may be considered as a condition for performing view switching, such as: the primary node fails to broadcast a service request, completes a consensus, and the like.
  • the triggering of the view switching condition triggering may be implemented by using a timer set in the primary node, for example, the behavior of the broadcast service request by the primary node is timed by the timer to monitor Whether the behavior of the primary node broadcast service request times out.
  • the timer may be regarded as a timing function or a service running in the master node.
  • the present invention is not limited thereto.
  • the master node needs to perform a view switch. It should be noted that, in any view, there is only one primary node, and the remaining nodes are backup nodes. Therefore, the view switching is also the switching of the primary node. Therefore, in this step, the master node selects the successor node as the next master node (the successor node in the embodiment of the present application is not the same node as the master node in the current view, that is, the master node cannot take itself as a successor. node).
  • the master node switches the current view to a view with the successor node as a master node according to the successor node, so that the successor master node initiates a consensus.
  • the master node performs a view switch.
  • the process of initiating the view switching consensus by the backup node can be regarded as a process of "capturing" the primary node in the view, and the master node performs the view on its own in the embodiment of the present application.
  • the process of switching can be seen as the process of active “Zen”, and the master node performs view switching without starting consensus. Obviously, the additional consensus process is avoided.
  • the newly-received master node is responsible for initiating the consensus in the switched view, and understandably, the new master node also performs the above-mentioned view switching process, and will not be described here.
  • the master node actively monitors the triggering of the view switching condition. If the view switching condition is triggered, the view switching needs to be performed. Then, the master node selects one successor node from other nodes as the next. The master node in a view, based on this, the master node performs view switching. In the switched view, the successor node acts as a new master node to perform service processing, and at the same time, the view switching is still performed according to the foregoing procedure. Obviously, the above view switching is initiated by the master node. In this way, the backup node initiates the view switching consensus. In other words, the phenomenon of additional consensus can be avoided, thereby reducing the extra operations in the blockchain. Quantity and processing time.
  • the client sends a service request to the primary node.
  • the primary node receives the service request, it broadcasts the service request to the backup node in the view to perform a consensus based on the service request.
  • the primary node may be an abnormal node.
  • the backup node After receiving the service request for a long time without broadcasting, the backup node initiates a consensus to switch views. Therefore, in order to avoid the backup view consensus initiated by the backup node due to the master node timeout not being broadcasted, the master node will self-time and actively monitor its own timeout phenomenon.
  • the view switching condition is: the primary node fails to broadcast the service request, and then the view switching condition is triggered, which includes: the primary node receives the service request, and does not initiate the service based on the service after the set duration The consensus of the request.
  • the timing can be implemented by a program or service having a timing function in the master node, such as the aforementioned timer. Specifically, the time can be counted from the moment when the primary node receives the service request.
  • the setting duration can be set to 5s, 10s, etc., and will be determined according to the needs of the actual application, and does not constitute a limitation on the present application.
  • the master node after receiving the service request, broadcasts the service request to each backup node in the current view. In other words, the master node initiates a service request based on the set time. Consensus, accordingly, each node in the view will have a consensus based on the business request and produce a consensus result.
  • the backup node will initiate a consensus of view switching.
  • consensus failure can be seen as a view switching condition.
  • the master node actively performs view switching when the consensus fails, thereby avoiding an additional view switching consensus initiated by the backup node.
  • the master node will continue to initiate a consensus based on other service requests, but the master node may fail during subsequent operations, once the master node fails, The backup node will still initiate a consensus on view switching. Therefore, in order to avoid the occurrence of the situation, in the embodiment of the present application, after the consensus is reached, the master node still performs view switching.
  • the master node performs a view switch after determining the consensus result. That is, the triggering the view switching condition includes: the primary node receiving the service request, initiating a consensus based on the service request, and determining a consensus result.
  • the master node needs to determine that a certain consensus has been reached or the consensus fails.
  • the consensus process based on the service request is essentially a consensus process based on a three-phase protocol, which includes: a pre-prepare, a prepare, and a confirmation phase. Commit), these three phases together form a complete consensus process.
  • each node both the primary node and each backup node
  • the nodes enter the confirmation phase they can be considered as the completion of the consensus process.
  • each node is based on a consensus process of a three-phase protocol.
  • the client initiates a service request to the node labeled 0 (replica 0, that is, the master node), and the master node broadcasts the request to each backup node (replica 1, replica 2, replica 3).
  • Business request starting a three-phase consensus.
  • the service request is processed, and the processing result is fed back to the client.
  • the master node determines the consensus failure.
  • the consensus failure is reflected in the timeout of the consensus process (hereinafter referred to as: consensus timeout, the consensus timeout refers to the consensus time-consuming exceeding the preset consensus duration, wherein the consensus time-consuming can start from the time when the master node initiates the consensus. Calculation). This is because:
  • the primary node is a failed node (a node failure can be considered as a data error in the node to perform consensus, or a consensus logic in the node is erroneous), that is, a service sent by the primary node to each backup node.
  • the request may contain erroneous data (such as the wrong service request sequence number).
  • each backup node will check the service request broadcast by the master node. Once the wrong data is included, the normal backup node will not recognize it. At this time, the master node may repeat the process of sending the service request, causing the consensus to time out.
  • the master node is also a failed node.
  • the master node may send a notification message of the wrong consensus phase to the other backup nodes, that is, the master node "error" is considered to have entered a certain One stage.
  • each backup node will have a consensus on the notification message of the primary node to confirm the authenticity of the notification message of the primary node.
  • the normal backup node still does not recognize the notification message sent by the primary node.
  • the master node may repeatedly send the wrong notification message, causing the consensus to time out.
  • the master node can monitor whether a certain consensus fails by monitoring the overall time-consuming manner of the consensus process. Once the consensus process times out, the master node immediately initiates a view switch operation, thereby avoiding the additional consensus process for the backup node to initiate view switch. That is, in the embodiment of the present application, the process of determining the failure of the consensus by the master node may be: when the master node initiates a consensus based on the service request to each backup node in the view, monitoring the consensus time-consuming When it is detected that the consensus takes longer than the set time, the consensus is determined to fail.
  • the master node determines the consensus.
  • a node if a node enters the confirmation phase, the node can process the service request and feed back the generated processing result to the client. At the same time, because for each node, it needs to be recognized by other nodes in the view to enter a certain stage. Therefore, if a node enters the confirmation phase, it indicates that the node is recognized by other nodes. Based on this, it can be seen that if the master node itself enters the confirmation phase, it indicates that the consensus has been reached. This is because, under the mechanism of PBFT, if a node enters a certain stage, it indicates that the state of the node is in view. The approval of most of the nodes, correspondingly, indicates that the vast majority of nodes are the correct nodes.
  • the process of determining the consensus by the primary node may be: the primary node monitors its own corresponding phase, and when the primary node detects its own entry confirmation phase, and does not exceed the preset consensus duration, then the consensus is determined. . That is, the master node needs to ensure that the time it takes to enter the confirmation phase does not exceed the set duration while confirming its own confirmation phase.
  • the primary node may not send a notification message to other nodes (that is, the primary node may be a failed node), but the primary node is also able to receive the notification message sent by the backup node.
  • the consensus can also be considered complete.
  • a node when a node enters the confirmation phase, it usually sends a notification message to other nodes in the view, and the notification message can be like: ⁇ commit, v, n, D(m)>.
  • the commit indicates that the node has entered the confirmation phase, v indicates the view number, n indicates the sequence number of the service request, and D(m) indicates the signature of the node that sent the notification message to the service request.
  • the master node may count the notification message of the incoming confirmation phase received by the master node. If the number of received notification messages is greater than 2f+1, it indicates that there are enough nodes to reach a consensus with each other. Then, it means to complete the consensus. Where f is the maximum number of faulty nodes that can be tolerated under the PBFT mechanism. At this point, the master node can determine the completion of the consensus.
  • the process of determining the consensus by the master node may also be: the master node monitors the notification message received by the backup node and enters the confirmation phase of the backup node, and when the master node detects that the number of received notification messages exceeds the set data, and does not exceed the preset.
  • the consensus time is determined to complete the consensus.
  • the master node After the consensus is completed, the master node initiates a view switch to replace the master node and enter a new view.
  • each view has a corresponding number, as in the previous example, the v value, which represents the number of the current view.
  • each node in the blockchain also has a corresponding number. If there are R nodes in the blockchain, the number of each node will start from 0 to R-1, as follows: Replica0, replica1, ..., replicaR-1. A node with a different number satisfies a certain relationship with a view number. Specifically, if a replica p represents a node numbered p, the number of the node and the view number satisfy:
  • v is the value from 0 to positive infinity.
  • the identity of the master node is guaranteed to be transmitted to different nodes in an orderly manner. For example, if the primary node of the current view is replica 0 (the corresponding view number is 0), then the primary node in the next view (numbered 1) is replica 1, and so on, until all nodes are traversed.
  • the process of performing view switching includes: the primary node determines its own number, and according to the number of the primary node itself, determines a node whose number is ranked after the primary node number, according to the determination.
  • the node is generated, and a view switching notification message is generated and sent to each backup node to perform view switching, so that the determined node becomes the master node in the next view.
  • S301 The master node p in the view numbered v receives the service request sent by the client, and times.
  • step S302 When the set time is reached, it is determined whether a consensus based on the service request is initiated to each backup node in the view, and if yes, step S303 is performed; otherwise, step S305 is performed.
  • S305 Switch the view v to the view v+1, and determine the node numbered p+1 as the master node of the view v+1.
  • the embodiment of the present application further provides a consensus device.
  • the consensus device includes:
  • the monitoring module 401 monitors triggering of the view switching condition
  • the node determining module 402 is configured to select a successor node when the monitoring module detects a triggering view switching condition
  • the view switching module 403 switches the current view to the view of the successor node as the blockchain master node according to the successor node, so that the successor blockchain master node initiates a consensus.
  • the monitoring module 401 determines that the trigger view switching condition is monitored when the receiving the service request is received and the consensus based on the service request is not initiated after the set time period.
  • the monitoring module 401 determines that the triggering view switching condition is detected when the receiving service request is initiated, the consensus based on the service request is initiated, and the consensus result is determined.
  • the node determining module 402 determines a next view of the current view, and determines a successor node corresponding to the next view;
  • the view switching module 403 switches the current view to the determined next view, where the successor node is the primary node in the switched view.
  • Nodes in any view including nodes in a federated chain and/or private chain.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • the controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor.
  • computer readable program code eg, software or firmware
  • examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, The Microchip PIC18F26K20 and the Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding.
  • Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component.
  • a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • a typical implementation device is a computer.
  • the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
  • the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • the application can be described in the general context of computer-executable instructions executed by a computer, such as a program module.
  • program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types.
  • the present application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communication network.
  • program modules can be located in both local and remote computer storage media including storage devices.

Abstract

一种共识方法及装置，所述方法包括：区块链主节点监测对视图切换条件的触发 (S101)，当监测到触发视图切换条件时，所述区块链主节点选定继任节点 (S102)，所述区块链主节点根据所述继任节点，将当前视图切换为以所述继任节点作为区块链主节点的视图，以使得继任的区块链主节点发起共识 (S103)。利用本共识方法及装置，视图切换均是由区块链主节点所发起，无需额外的共识过程，从而能够减少区块链中额外的运算量以及处理耗时。

Description

一种共识方法及装置 技术领域
本申请涉及计算机技术领域，尤其涉及一种共识方法及装置。
背景技术
目前，区块链技术得到了广泛应用，其去中心化的模式保证了数据不易被篡改，从而提升了安全性。
在实际应用中，包含多个节点(节点可认为是区块链中参与处理业务的设备)的区块链能够为客户端提供相应的业务服务。具体而言，区块链中的各节点将针对客户端的业务请求进行处理，并向客户端反馈处理结果，在此过程中，独立运行的各节点所生成的处理结果有可能不一致，为了保证客户端能够接收到正确的处理结果，故采用基于拜占庭容错算法(Practical Byzantine Fault Tolerance，PBFT)实现各节点之间的共识(即，使得各节点能够共同认可正确的处理结果)。
在运用PBFT的过程中，共识通常在视图(View)下进行，具体而言，在一个视图下，区块链中的某一个节点作为主节点(primary)，其余的节点作为备份节点(backup)。此时，由主节点接收客户端的业务请求，将该业务请求广播给所有备份节点，并由主节点发起共识。达成共识的节点将针对该业务请求进行处理，并向客户端反馈处理结果。
现有技术中，备份节点会发起视图切换，由备份节点所发起的视图切换通常需要得到视图中的其他节点的认可。具体而言，备份节点向该视图下的其他节点(包括主节点)发起视图切换请求，即，向其他节点发起基于视图切换请求的共识(此次共识仍采用PBFT，与基于业务请求的共识过程不同的是，在针对视图切换请求的共识过程中，各节点将暂停对业务请求的共识，故，基于视图切换请求的共识，实质上是一次额外的共识过程)。在一定数量的节点达成共识后，将确定某个备份节点成为新的主节点。新的主节点向外广播新视图 消息，完成视图切换。
然而，上述的机制中，由备份节点发起的视图切换需要额外进行一次共识过程，额外的共识过程会增加系统运算量，而且，视图切换的共识过程需要等待一定数量的节点确认后才能达成一致，最终由新的主节点对外广播新视图消息，整个过程将会耗费一定的时间。显然，现有的视图切换方式不仅会增加系统的运算量，同时也增加对业务请求的处理耗时，导致处理效率较低。
发明内容
本申请实施例提供一种共识方法及装置，用以解决目前的视图切换方式增加区块链的运算量并增加了处理耗时的问题。
本申请实施例提供的一种共识方法，所述方法包括：
区块链主节点监测对视图切换条件的触发；
当监测到触发视图切换条件时，所述区块链主节点选定继任节点；
所述区块链主节点根据所述继任节点，将当前视图切换为以所述继任节点作为区块链主节点的视图，以使得继任的区块链主节点发起共识。
本申请实施例提供的一种共识装置，所述装置包括：
监测模块，监测对视图切换条件的触发；
节点确定模块，当所述监测模块监测到触发视图切换条件时，选定继任节点；
视图切换模块，根据所述继任节点，将当前视图切换为以所述继任节点作为区块链主节点的视图，以使得继任的区块链主节点发起共识。
本申请实施例提供一种共识方法及装置，在任一视图中，区块链主节点会主动监测对视图切换条件的触发，如果触发了视图切换条件，则需要执行视图切换，进而，区块链主节点从其他区块链节点中选定一个继任节点，作为下一视图中的区块链主节点，基于此，区块链主节点进行视图切换，在切换后的视图中，继任节点作为新的区块链主节点以进行业务的处理，同时，仍会按照前 述过程执行视图切换。显然，上述的视图切换均是由区块链主节点所发起，这样的方式避免出现区块链备份节点发起视图切换共识的情况，换言之，也就能够避免出现额外共识的现象，从而能够减少区块链中额外的运算量以及处理耗时。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1a为本申请实施例提供的共识过程所基于的架构；
图1b为本申请实施例提供的共识过程；
图2为本申请实施例提供的在任一视图中基于三阶段协议的共识过程的示意图；
图3为本申请实施例提供的一种视图切换的应用实例的执行过程示意图；
图4为本申请实施例提供的共识装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
正如前述，区块链内各节点之间采用PBFT进行共识的过程中，一旦区块链主节点失效，则区块链备份节点会发起视图切换。区块链备份节点发起的视图切换需要进行额外的共识，也即，需要得到其他区块链节点的认可，才可完成视图切换。显然，额外的共识过程无疑增加了区块链的运算量，同时也增加 了处理耗时。
基于此，本申请实施例中提供一种共识方法，针对任一视图下的区块链主节点，在一次共识结束后，由该区块链主节点发起视图切换，更换区块链主节点，而无需额外的共识过程。为了便于描述，以下将区块链主节点简称为：主节点，将区块链备份节点简称为：备份节点。同时，下文中出现有关“节点”的描述，应理解为区块链网络中参与共识的节点。
需要说明的是，在本申请实施例中，共识方法所采用的架构如图1a所示。从图1a中可见，区块链网络中包含多个节点，多个客户端可与该区块链进行业务交互。其中，所述的区块链网络的应用类型，可以是联盟链和/或私有链，能够向用户提供业务服务。所述的节点，包括但不限于：服务器、计算机、移动终端等具有计算处理功能的设备。所述的客户端，可包括浏览器、应用等，客户端可以运行在诸如终端、服务器、数据库中，这里不作具体限定。
基于图1a中所示的关系架构，本申请实施例提供的一种共识过程，如图1b所示，该过程具体包括以下步骤：
S101：主节点监测对视图切换条件的触发。
在本申请实施例中，所述的视图切换条件，可认为是进行视图切换所满足的条件，诸如：主节点超时未广播业务请求、完成共识等。
作为本申请实施例中的一种可能的方式，可通过在主节点中设置的定时器，实现对视图切换条件触发的监测，如：通过定时器对主节点广播业务请求的行为计时，以监测主节点广播业务请求的行为是否超时。其中，所述的定时器可认为是运行在主节点中的计时功能或服务，当然，这里并不构成对本申请的限定。
S102：当监测到触发视图切换条件时，所述主节点选定继任节点。
如果触发了视图切换条件，则主节点需要执行视图切换。需要说明的是，在任一视图中，有且只有一个主节点，其余节点均为备份节点，所以，视图切换也就是主节点的切换。故在本步骤中，主节点将选定继任节点，作为下一任 主节点(本申请实施例中的继任节点，与当前视图中的主节点不是同一节点，也即，主节点不能将自己作为继任节点)。
S103：主节点根据所述继任节点，将当前视图切换为以所述继任节点作为主节点的视图，以使得继任的主节点发起共识。
确定了继任节点后，主节点便会执行视图切换。与现有的备份节点发起视图切换共识的方式不同，由备份节点发起视图切换共识的过程，可看作是针对视图中主节点“弹劾”的过程，而本申请实施例中主节点自行执行视图切换的过程，可看作是主动“禅让”的过程，而由主节点执行视图切换，无需发起共识，显然，也就避免了额外的共识过程。执行了视图切换后，新上任的主节点负责在切换后的视图中发起共识，并可以理解地，新上任的主节点也会执行上述的视图切换过程，这里便不再过多赘述。
通过上述步骤，在任一视图中，主节点会主动监测对视图切换条件的触发，如果触发了视图切换条件，则需要执行视图切换，进而，主节点从其他节点中选定一个继任节点，作为下一视图中的主节点，基于此，主节点进行视图切换，在切换后的视图中，继任节点作为新的主节点以进行业务的处理，同时，仍会按照前述过程执行视图切换。显然，上述的视图切换均是由主节点所发起，这样的方式避免出现备份节点发起视图切换共识的情况，换言之，也就能够避免出现额外共识的现象，从而能够减少区块链中额外的运算量以及处理耗时。
在实际应用中，存在不同的视图切换条件，下面将针对视图切换条件的触发进行详细说明：
第一种场景：
在实际应用中，客户端会向主节点发送业务请求，在正常状态下，当主节点接收到业务请求之后，会向视图中的备份节点广播该业务请求，以便进行基于该业务请求的共识，然而，主节点可能是异常节点，在接收到业务请求后长时间不进行广播，那么，备份节点便会发起切换视图的共识。因此，为了避免备份节点因主节点超时不广播所发起的切换视图共识，主节点将自行进行计时， 主动监测自身的超时现象。
换言之，在本场景下，视图切换条件为：主节点超时未广播业务请求，那么，触发视图切换条件，具体包括：所述主节点接收业务请求，并经过设定时长后未发起基于所述业务请求的共识。
其中，在实际操作时，计时可由主节点中具有计时功能的程序或服务所实现，如：前述提及的定时器。具体可从主节点接收到业务请求的时刻开始计时。设定时长，可设置为5s、10s等，具体将根据实际应用的需要进行确定，这里并不构成对本申请的限定。
第二种场景：
与前述场景不同，本场景下，主节点在接收到业务请求后，向当前视图中的各备份节点广播了该业务请求，换言之，主节点在设定时长到达前，已发起了基于业务请求的共识，相应地，视图中的各节点便会进行基于该业务请求的共识，并产生共识结果。
这里需要说明的是，基于现有的视图切换机制，如果共识结果为共识失败，则备份节点将会发起视图切换的共识。显然，共识失败可看作是一种视图切换条件。换言之，在本场景下，主节点会在共识失败时，主动执行视图切换，从而避免由备份节点发起额外的视图切换共识。
此外，基于现有的视图切换机制，如果共识结果为达成共识，则主节点将继续发起基于其他业务请求的共识，但是，该主节点有可能在后续的运行过程中失效，一旦主节点失效，备份节点仍会发起视图切换的共识。故为了避免该情况的出现，在本申请实施例中，达成共识后，主节点仍会执行视图切换。
可见，在本场景中，无论共识结果为达成共识或共识失败，主节点在确定出共识结果后，均会执行视图切换。即，触发视图切换条件，具体包括：所述主节点接收业务请求，发起基于所述业务请求的共识，并确定出共识结果。
也就是说，在本场景中，主节点需要确定出某一次共识已达成或共识失败。下面将详细说明主节点如何确定某一次共识已达成或共识失败：
首先需要说明的是，基于业务请求的共识过程，实质上是基于三阶段协议的共识过程，其中所述的三阶段包括：预准备阶段(pre-prepare)、准备阶段(prepare)、确认阶段(commit)，这三个阶段共同组成完整的共识过程。在每个阶段，各节点(既包括主节点，也包括各备份节点)均会向彼此发送共识消息。也就是说，对于视图中的每个节点而言，若要进入不同的阶段，必须得到其他节点的认可，所以，三阶段中的每个阶段，都可以看作是一种共识的过程。通常，当节点均进入确认阶段，便可以认为是共识过程的完成。
具体而言，如图2所示，为某一视图下，各节点基于三阶段协议的共识过程。图2中，客户端(Client)向标号为0的节点(replica 0，也即，主节点)发起业务请求(request)，主节点向各备份节点(replica 1、replica 2、replica 3)广播该业务请求，开始进行三阶段共识。各节点达成共识后，对业务请求进行处理，并向客户端反馈处理结果。
基于此：
一、主节点确定共识失败。
在本申请实施例中，共识失败体现为共识过程超时(以下简称为：共识超时，共识超时是指共识耗时超过预设的共识时长，其中，共识耗时可以从主节点发起共识时刻起开始计算)。这是因为：
在一种情况下，主节点为失效节点(节点失效可认为是节点中用以执行共识的数据出错，或节点中的共识逻辑出错)，也就是说，主节点向各备份节点所发送的业务请求中可能包含了错误的数据(如：错误的业务请求序号)，在BPFT机制的保证下，各备份节点会针对主节点所广播的业务请求进行校验。一旦包含了错误的数据，则正常的备份节点并不会认可，此时，主节点可能会重复发送业务请求的过程，致使共识超时。
或者，在另一种情况下，主节点同样为失效节点，在该情况下，主节点可能会向其他备份节点发送错误的共识阶段的通知消息，即，主节点“错误”的认为已进入某一阶段。此时，各备份节点将对主节点的通知消息进行共识，以便 确认主节点的通知消息的真实性。类似地，正常的备份节点仍不会认可该主节点发送的通知消息，此时，主节点可能会重复发送错误的通知消息的过程，致使共识超时。
当然，上述内容，仅是实际应用中可能导致共识超时的两种可能情况，这里并不应作为对本申请的限定。显然，从上述内容可见，一旦共识超时，则共识失败。
因此，在本申请实施例中，主节点可通过监测共识过程的整体耗时的方式，来监测某一次共识是否失败。一旦共识过程超时，主节点就会立即发起视图切换操作，从而就避免了备份节点发起视图切换的额外共识过程。也即，在本申请实施例中，主节点确定共识失败的过程可以为：主节点从向所述视图中的各备份节点发起基于所述业务请求的共识的时刻起，监测共识耗时，当监测到共识耗时超过设定时长时，则确定共识失败。
二、主节点确定达成共识。
基于前述的三阶段协议可知，若某一节点进入了确认阶段，那么，该节点便可以针对业务请求进行处理，并将生成的处理结果反馈给客户端。同时，又由于对于每一节点而言，其要进入某一阶段均需要得到视图中其他节点的认可，所以，如果某一节点进入了确认阶段，也就表明该节点得到了其他节点的认可。基于此，可见，如果主节点自身进入了确认阶段，也就表明共识已经达成，这是因为：在PBFT的机制下，若某一节点进入某一阶段后，就表明该节点的状态得到了视图中绝大多数节点的认可，相应的，也就表明绝大多数节点是正确的节点。
因此，该方式下，主节点确定达成共识的过程可以为：主节点监测自身对应的阶段，当所述主节点监测到自身进入确认阶段，且未超过预设的共识时长时，则确定完成共识。即，主节点在确认自身进行确认阶段的同时，还需保证其进入确认阶段的耗时并未超过设定时长。
作为本申请实施例中的另一种方式，主节点可能不会向其他节点发送通知 消息(即，主节点可能是失效节点)，但该主节点还能够接收到备份节点所发送的通知消息，此时，如果有设定数量的节点都进入到了确认阶段，那么，也可以认为共识完成。
在实际应用中，当某一节点进入确认阶段后，通常会向视图中的其他节点发送通知消息，其通知消息中可如：<commit，v，n，D(m)>。其中，commit表示该节点已进入确认阶段，v表示视图编号，n表示业务请求的序号，D(m)表示发出通知消息的节点对业务请求的签名。
主节点可统计其接收到的进入确认阶段的通知消息，如果接收到的通知消息的数量大于2f+1，则表示有足够多的节点彼此达成共识。那么，也就表示完成共识。其中，f为PBFT机制下最大可容忍的错误节点的数量。此时，主节点便可以确定完成共识。
所以，主节点确定达成共识的过程还可以为：主节点监测自身接收到的、备份节点进入确认阶段的通知消息，当主节点监测到接收的通知消息的数量超过设定数据，且未超过预设的共识时长，则确定完成共识。
在完成共识后，主节点将发起视图切换，以进行主节点的更换，进入新视图。
下面将说明本申请实施例中视图的切换过程。
在PBFT机制下，每一视图均具有相应的编号，正如前述示例中的v值，其代表了当前视图的编号。相应的，区块链中每个节点也都具有相应的编号，如果在区块链中一共有R个节点，那么，各节点的编号将从0开始取值，直到R-1，具体如：replica0、replica1、……、replicaR-1。具有不同编号的节点与视图编号满足一定的关系，具体地，若以replica p代表编号为p的节点，则该节点的编号与视图编号之间满足：
p＝v mod R；
其中，v的取值为：从0至正无穷的整数。
该关系表示：节点编号p由视图编号v与区块链中所包含的节点数量R进 行取模运算而得到。
换言之，由于v的取值从0到R-1，从而保证了主节点的身份有序的传递至不同节点。例如：如果当前视图的主节点为replica 0(其对应的视图编号为0)，那么，下一个视图(编号为1)中的主节点为replica 1，以此类推，直到遍历完所有节点。
从而可见，在本申请实施例中，进行视图切换的过程包括：所述主节点确定自身的编号，根据该主节点自身的编号，确定编号排列于该主节点编号后一位的节点，根据确定出的所述节点，生成视图切换通知消息，发送给各备份节点，进行视图切换，以使得确定出的所述节点成为下一视图中的主节点。
下面以一具体应用实例进行说明，如图3所示，该实例中包括如下步骤：
S301：编号为v的视图中的主节点p接收客户端发送的业务请求，并计时。
S302：在到达设定时间时，判断是否向该视图中的各备份节点发起基于所述业务请求的共识，若是，则执行步骤S303，否则，则执行步骤S305。
S303：获取共识结果。
S304：判断是否达成共识，执行步骤S305。
S305：将视图v切换至视图v+1，并确定编号为p+1的节点作为视图v+1的主节点。
上述的视图切换均是由主节点所发起，这样的方式避免出现备份节点发起视图切换共识的情况。
以上为本申请实施例提供的共识方法，基于同样的思路，本申请实施例还提供一种共识装置，如图4所示，针对任一视图，所述共识装置包括：
监测模块401，监测对视图切换条件的触发；
节点确定模块402，当所述监测模块监测到触发视图切换条件时，选定继任节点；
视图切换模块403，根据所述继任节点，将当前视图切换为以所述继任节点作为区块链主节点的视图，以使得继任的区块链主节点发起共识。
所述监测模块401，当监测到接收业务请求并经过设定时长后未发起基于所述业务请求的共识时，确定为监测到触发视图切换条件。
所述监测模块401，当监测到接收业务请求，发起基于所述业务请求的共识，并确定出共识结果时，确定为监测到触发视图切换条件。
所述节点确定模块402，确定当前视图的下一视图，确定对应于所述下一视图的继任节点；
所述视图切换模块403，将所述当前视图切换为确定出的所述下一视图，其中，所述继任节点作为切换后的视图中的主节点。
任一视图中的节点，包括联盟链和/或私有链中的节点。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced  Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内 存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来 执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

  1. 一种共识方法，其特征在于，所述方法包括：
    区块链主节点监测对视图切换条件的触发；
    当监测到触发视图切换条件时，所述区块链主节点选定继任节点；
    所述区块链主节点根据所述继任节点，将当前视图切换为以所述继任节点作为区块链主节点的视图，以使得继任的区块链主节点发起共识。
  2. 如权利要求1所述的方法，其特征在于，触发视图切换条件，具体包括：
    所述区块链主节点接收业务请求，经过设定时长后未发起基于所述业务请求的共识。
  3. 如权利要求1所述的方法，其特征在于，触发视图切换条件，具体包括：
    所述区块链主节点接收业务请求，发起基于所述业务请求的共识，并确定出共识结果。
  4. 如权利要求1所述的方法，其特征在于，所述区块链主节点选定继任节点，具体包括：
    所述区块链主节点确定当前视图的下一视图；
    选定对应于所述下一视图的继任节点；
    将当前视图切换为以所述继任节点作为区块链主节点的视图，具体包括：
    将所述当前视图切换为确定出的所述下一视图，其中，所述继任节点作为切换后的视图中的区块链主节点。
  5. 如权利要求1至4中任一所述的方法，其特征在于，任一视图中的区块链节点，包括联盟链和/或私有链中的节点。
  6. 一种共识装置，其特征在于，所述装置包括：
    监测模块，监测对视图切换条件的触发；
    节点确定模块，当所述监测模块监测到触发视图切换条件时，选定继任节 点；
    视图切换模块，根据所述继任节点，将当前视图切换为以所述继任节点作为区块链主节点的视图，以使得继任的区块链主节点发起共识。
  7. 如权利要求6所述的装置，其特征在于，所述监测模块，当监测到接收业务请求并经过设定时长后未发起基于所述业务请求的共识时，确定为监测到触发视图切换条件。
  8. 如权利要求6所述的装置，其特征在于，所述监测模块，当监测到接收业务请求，发起基于所述业务请求的共识，并确定出共识结果时，确定为监测到触发视图切换条件。
  9. 如权利要求6所述的装置，其特征在于，所述节点确定模块，确定当前视图的下一视图，确定对应于所述下一视图的继任节点；
    所述视图切换模块，将所述当前视图切换为确定出的所述下一视图，其中，所述继任节点作为切换后的视图中的区块链主节点。
  10. 如权利要求6至9中任一所述的装置，其特征在于，任一视图中的区块链节点，包括联盟链和/或私有链中的节点。
PCT/CN2018/078169 2017-03-10 2018-03-06 一种共识方法及装置 WO2018161901A1 (zh)

Priority Applications (13)

Application Number Priority Date Filing Date Title
EP18764913.2A EP3525102B1 (en) 2017-03-10 2018-03-06 Consensus method and device
BR112019009591-8A BR112019009591B1 (pt) 2017-03-10 2018-03-06 Método implementado por computador para executar troca de exibição em uma rede de protocolo de confiança, meio legível por computador, não transitório, e sistema implementado por computador
RU2019114226A RU2733221C1 (ru) 2017-03-10 2018-03-06 Способ и устройство консенсуса
PL18764913T PL3525102T3 (pl) 2017-03-10 2018-03-06 Sposób i urządzenie do konsensusu
MX2019005525A MX2019005525A (es) 2017-03-10 2018-03-06 Metodo y aparato de consenso.
KR1020197014424A KR102140903B1 (ko) 2017-03-10 2018-03-06 합의 방법 및 장치
JP2019527429A JP6756918B2 (ja) 2017-03-10 2018-03-06 コンセンサス方法およびデバイス
CA3043532A CA3043532C (en) 2017-03-10 2018-03-06 Consensus method and apparatus
ES18764913T ES2880448T3 (es) 2017-03-10 2018-03-06 Procedimiento y dispositivo de consenso
AU2018230202A AU2018230202B2 (en) 2017-03-10 2018-03-06 Consensus method and device
ZA2019/02935A ZA201902935B (en) 2017-03-10 2019-05-10 Consensus method and device
PH12019501053A PH12019501053A1 (en) 2017-03-10 2019-05-10 Consensus method and apparatus
US16/440,782 US10684925B2 (en) 2017-03-10 2019-06-13 Method for view switching in a blockchain network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710142252.1A CN107391320B (zh) 2017-03-10 2017-03-10 一种共识方法及装置
CN201710142252.1 2017-03-10

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/440,782 Continuation US10684925B2 (en) 2017-03-10 2019-06-13 Method for view switching in a blockchain network

Publications (1)

Publication Number Publication Date
WO2018161901A1 true WO2018161901A1 (zh) 2018-09-13

Family

ID=60338823

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/078169 WO2018161901A1 (zh) 2017-03-10 2018-03-06 一种共识方法及装置

Country Status (16)

Country Link
US (1) US10684925B2 (zh)
EP (1) EP3525102B1 (zh)
JP (1) JP6756918B2 (zh)
KR (1) KR102140903B1 (zh)
CN (1) CN107391320B (zh)
AU (1) AU2018230202B2 (zh)
BR (1) BR112019009591B1 (zh)
CA (1) CA3043532C (zh)
ES (1) ES2880448T3 (zh)
MX (1) MX2019005525A (zh)
PH (1) PH12019501053A1 (zh)
PL (1) PL3525102T3 (zh)
RU (1) RU2733221C1 (zh)
TW (1) TW201833855A (zh)
WO (1) WO2018161901A1 (zh)
ZA (1) ZA201902935B (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109660545A (zh) * 2018-12-27 2019-04-19 北京新唐思创教育科技有限公司 一种联盟链共识方法及计算机存储介质
CN110431580A (zh) * 2018-11-30 2019-11-08 阿里巴巴集团控股有限公司 使用随机数表来减少并发区块链交易失败
CN111130879A (zh) * 2019-12-24 2020-05-08 杭州趣链科技有限公司 一种基于pbft算法的集群异常恢复方法
JP2020519959A (ja) * 2019-03-18 2020-07-02 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ビュー変更プロトコルを終了するためのシステムおよび方法
CN111543026A (zh) * 2018-12-13 2020-08-14 阿里巴巴集团控股有限公司 分布式网络中进行主节点变更的系统
WO2021101040A1 (ko) * 2019-11-18 2021-05-27 주식회사 아이콘루프 패치 트랜잭션을 이용한 블록체인 생성 방법
US11057504B2 (en) 2019-03-18 2021-07-06 Advanced New Technologies Co., Ltd. System and method for ending view change protocol

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107391320B (zh) * 2017-03-10 2020-07-10 创新先进技术有限公司 一种共识方法及装置
CN110430064B (zh) * 2017-03-30 2020-12-04 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
CN107395665B (zh) * 2017-05-22 2020-04-24 创新先进技术有限公司 一种区块链业务受理及业务共识方法及装置
CN108182635A (zh) * 2017-12-18 2018-06-19 深圳前海微众银行股份有限公司 区块链共识方法、系统和计算机可读存储介质
US10599835B2 (en) 2018-02-06 2020-03-24 Vmware, Inc. 32-bit address space containment to secure processes from speculative rogue cache loads
CN108282539A (zh) * 2018-02-06 2018-07-13 北京奇虎科技有限公司 基于双层网络的去中心化存储系统
US11700265B2 (en) 2018-03-06 2023-07-11 Americorp Investments Llc Customized view of restricted information recorded into a blockchain
WO2019173519A1 (en) 2018-03-06 2019-09-12 Jordan Simons Customized view of restricted information recorded into a blockchain
US10951626B2 (en) 2018-03-06 2021-03-16 Americorp Investments Llc Blockchain-based commercial inventory systems and methods
CN108416593B (zh) * 2018-03-20 2021-02-12 杨鉴 一种基于网络分散度证明的区块链共识方法和系统
CN108596622A (zh) * 2018-05-02 2018-09-28 北京链链信息技术有限公司 交易信息的共享系统及方法
CN109964242B (zh) * 2018-05-25 2023-07-14 北京大学深圳研究生院 一种基于信任关系的区块链共识方法
US10713133B2 (en) * 2018-06-11 2020-07-14 Vmware, Inc. Linear view-change BFT
US10747629B2 (en) * 2018-06-11 2020-08-18 Vmware, Inc. Linear view-change BFT with optimistic responsiveness
GB2574828A (en) * 2018-06-19 2019-12-25 Setl Ltd Leader selection for permissioned blockchain
CN109087204B (zh) * 2018-07-27 2023-04-14 杭州复杂美科技有限公司 跨链交易校验方法、设备和存储介质
CA3108398A1 (en) * 2018-08-02 2020-02-06 Neuralia Technologies Inc. Method and system for proof of election on a blockchain
CN109039750B (zh) * 2018-08-13 2021-06-15 浙商银行股份有限公司 一种提升区块链应用系统多城多园区部署灾备能力的方法
CN111291110A (zh) * 2018-12-06 2020-06-16 中国电信股份有限公司 基于区块链网络的共识方法和系统
CN111327436B (zh) * 2018-12-13 2023-04-07 北京果仁宝软件技术有限责任公司 预测区块链出块节点的方法、装置和系统
CN109886681B (zh) * 2019-01-31 2021-06-18 北京瑞卓喜投科技发展有限公司 区块链共识方法及共识系统
US11398895B2 (en) 2019-03-26 2022-07-26 International Business Machines Corporation Information management in a decentralized database including a fast path service
US11418322B2 (en) * 2019-03-26 2022-08-16 International Business Machines Corporation Information management in a decentralized database including a fast path service
US11269858B2 (en) 2019-03-26 2022-03-08 International Business Machines Corporation Information management in a decentralized database including a fast path service
EP3701701A4 (en) 2019-06-05 2020-12-30 Alibaba Group Holding Limited CONSENSUS SYSTEM AND PROCESS
CN110351133B (zh) * 2019-06-28 2021-09-17 创新先进技术有限公司 用于区块链系统中的主节点切换处理的方法及装置
US10944624B2 (en) 2019-06-28 2021-03-09 Advanced New Technologies Co., Ltd. Changing a master node in a blockchain system
CN110727731B (zh) * 2019-09-05 2021-12-21 创新先进技术有限公司 区块链网络中加入节点的方法和区块链系统
CN110673914B (zh) * 2019-09-24 2021-06-29 支付宝(杭州)信息技术有限公司 一种区块链共识的视图切换方法及区块链系统
CN111327414A (zh) * 2020-01-20 2020-06-23 布比（北京）网络技术有限公司 一种区块链共识方法、系统及计算机存储介质、电子设备
WO2021166928A1 (ja) * 2020-02-21 2021-08-26 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、制御装置、及び、プログラム
CN111510317B (zh) * 2020-03-06 2022-08-26 杜晓楠 弱化dbft中连续多个节点故障导致的延迟的方法、计算机可读存储介质和dbft网络
CN112511326B (zh) * 2020-03-16 2024-02-02 中兴通讯股份有限公司 一种切换方法、装置、设备和存储介质
CN111464356B (zh) * 2020-04-01 2021-11-05 腾讯科技（深圳）有限公司 一种区块共识周期切换方法、装置及计算机设备
CN111698315B (zh) * 2020-06-09 2021-10-15 腾讯科技（深圳）有限公司 针对区块的数据处理方法、数据处理装置及计算机设备
CN111522683B (zh) 2020-07-03 2020-10-02 支付宝(杭州)信息技术有限公司 蜜獾拜占庭容错共识机制的共识节点变更方法及相关装置
CN112182113A (zh) * 2020-10-23 2021-01-05 网易（杭州）网络有限公司 区块链共识方法、系统、电子设备及存储介质
CN112507019A (zh) * 2020-11-20 2021-03-16 南京航空航天大学 一种基于智能合约的pbft共识系统及方法
CN112991066A (zh) * 2021-04-27 2021-06-18 支付宝(杭州)信息技术有限公司 联盟链中的共识方法、装置和电子设备
CN113395165B (zh) * 2021-05-28 2022-08-16 网易（杭州）网络有限公司 共识流程处理方法、装置、存储介质及计算机设备
WO2023281690A1 (ja) * 2021-07-08 2023-01-12 富士通株式会社 判定方法、情報処理装置、判定システム、及び判定プログラム
CN114047980B (zh) * 2021-11-29 2024-01-19 珠海格力电器股份有限公司 可编程控制器配置数据的管理系统
WO2024009650A1 (ja) * 2022-07-04 2024-01-11 株式会社CountUp ブロックチェーンネットワークの構成方法及びその方法を実施するためのコンピュータソフトウエアプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105488665A (zh) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 一种去中心化的交易方法
CN106060036A (zh) * 2016-05-26 2016-10-26 布比（北京）网络技术有限公司 去中心化共识方法及装置
CN106157142A (zh) * 2016-06-30 2016-11-23 惠众商务顾问（北京）有限公司 一种区块链共识及同步方法、系统和装置
CN107391320A (zh) * 2017-03-10 2017-11-24 阿里巴巴集团控股有限公司 一种共识方法及装置

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3381526D1 (de) * 1983-02-09 1990-06-07 Ibm Verfahren zum erhalten der einigung mehrfacher rechner zum vermeiden von fehlern.
US6671821B1 (en) * 1999-11-22 2003-12-30 Massachusetts Institute Of Technology Byzantine fault tolerance
US7499865B2 (en) * 2004-12-17 2009-03-03 International Business Machines Corporation Identification of discrepancies in actual and expected inventories in computing environment having multiple provisioning orchestration server pool boundaries
US7917596B2 (en) * 2009-01-07 2011-03-29 Oracle International Corporation Super master
US8639793B2 (en) * 2010-10-29 2014-01-28 Cisco Technology, Inc. Disaster recovery and automatic relocation of cloud services
DE102011088884A1 (de) * 2011-12-16 2013-06-20 Siemens Aktiengesellschaft Verfahren zur Übertragung von Daten in einem Kommunikationsnetz
US9501363B1 (en) * 2013-03-15 2016-11-22 Nuodb, Inc. Distributed database management system with node failure detection
US9329950B2 (en) * 2014-01-01 2016-05-03 International Business Machines Corporation Efficient fail-over in replicated systems
US11394773B2 (en) 2014-06-19 2022-07-19 Jim Austin Joseph Cryptographic currency block chain based voting system
TWI524289B (zh) 2014-11-12 2016-03-01 Jetsream Holding Ltd Data transfer method between bit currency trading devices
CN104679604A (zh) * 2015-02-12 2015-06-03 大唐移动通信设备有限公司 一种主节点和备节点切换的方法和装置
CN106161495A (zh) * 2015-03-25 2016-11-23 中兴通讯股份有限公司 一种主节点选举方法、装置及存储系统
US10635722B2 (en) * 2015-04-20 2020-04-28 Ogy Docs, Inc. Method of distributed management of electronic documents of title (EDT) and system thereof
CN106385319B (zh) * 2016-09-29 2020-11-27 江苏通付盾科技有限公司 区块链网络中信息的验证方法及系统
EP3281115B1 (en) * 2016-10-04 2019-06-19 Nec Corporation Method and system for byzantine fault-tolerance replicating of data on a plurality of servers
US10601907B2 (en) * 2017-09-22 2020-03-24 Artiste QB Net Inc. System and method for platform to securely distribute compute workload to web capable devices
US10671492B2 (en) * 2017-12-18 2020-06-02 International Business Machines Corporation Forecast recommended backup destination
US11474994B2 (en) * 2018-12-27 2022-10-18 Intel Corporation Distributed blockchain oracle

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105488665A (zh) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 一种去中心化的交易方法
CN106060036A (zh) * 2016-05-26 2016-10-26 布比（北京）网络技术有限公司 去中心化共识方法及装置
CN106157142A (zh) * 2016-06-30 2016-11-23 惠众商务顾问（北京）有限公司 一种区块链共识及同步方法、系统和装置
CN107391320A (zh) * 2017-03-10 2017-11-24 阿里巴巴集团控股有限公司 一种共识方法及装置

Non-Patent Citations (1)

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

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110431580A (zh) * 2018-11-30 2019-11-08 阿里巴巴集团控股有限公司 使用随机数表来减少并发区块链交易失败
JP2020518872A (ja) * 2018-11-30 2020-06-25 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ 同時ブロックチェーン取引の失敗を解決するためのナンス表の利用
CN111543026A (zh) * 2018-12-13 2020-08-14 阿里巴巴集团控股有限公司 分布式网络中进行主节点变更的系统
CN111543026B (zh) * 2018-12-13 2023-08-04 创新先进技术有限公司 分布式网络中进行主节点变更的系统
CN109660545A (zh) * 2018-12-27 2019-04-19 北京新唐思创教育科技有限公司 一种联盟链共识方法及计算机存储介质
JP2020519959A (ja) * 2019-03-18 2020-07-02 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ビュー変更プロトコルを終了するためのシステムおよび方法
US11057504B2 (en) 2019-03-18 2021-07-06 Advanced New Technologies Co., Ltd. System and method for ending view change protocol
US11263067B2 (en) 2019-03-18 2022-03-01 Advanced New Technologies Co., Ltd. System and method for ending view change protocol
WO2021101040A1 (ko) * 2019-11-18 2021-05-27 주식회사 아이콘루프 패치 트랜잭션을 이용한 블록체인 생성 방법
CN111130879A (zh) * 2019-12-24 2020-05-08 杭州趣链科技有限公司 一种基于pbft算法的集群异常恢复方法
CN111130879B (zh) * 2019-12-24 2022-11-18 杭州趣链科技有限公司 一种基于pbft算法的集群异常恢复方法

Also Published As

Publication number Publication date
JP6756918B2 (ja) 2020-09-16
KR102140903B1 (ko) 2020-08-04
AU2018230202A1 (en) 2019-05-30
EP3525102A1 (en) 2019-08-14
US20190294514A1 (en) 2019-09-26
CA3043532C (en) 2022-08-30
EP3525102B1 (en) 2021-05-05
KR20190077000A (ko) 2019-07-02
EP3525102A4 (en) 2019-12-25
TW201833855A (zh) 2018-09-16
CN107391320A (zh) 2017-11-24
PH12019501053A1 (en) 2021-02-05
BR112019009591A2 (pt) 2019-12-17
BR112019009591B1 (pt) 2021-11-23
PL3525102T3 (pl) 2021-10-25
ZA201902935B (en) 2020-05-27
ES2880448T3 (es) 2021-11-24
AU2018230202B2 (en) 2020-07-16
JP2020507142A (ja) 2020-03-05
MX2019005525A (es) 2019-08-12
CA3043532A1 (en) 2018-09-13
RU2733221C1 (ru) 2020-09-30
CN107391320B (zh) 2020-07-10
US10684925B2 (en) 2020-06-16

Similar Documents

Publication Publication Date Title
WO2018161901A1 (zh) 一种共识方法及装置
KR102255724B1 (ko) 블록체인 기반 합의 방법 및 디바이스
EP3547648B1 (en) Service processing and consensus method and device
RU2735156C1 (ru) Способ и устройство для отправки информации о транзакциях и для проверки консенсуса
KR20190091484A (ko) 블록체인 합의 방법 및 디바이스
WO2018171543A1 (zh) 一种广播消息的方法及装置

Legal Events

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

Ref document number: 18764913

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3043532

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2018764913

Country of ref document: EP

Effective date: 20190510

ENP Entry into the national phase

Ref document number: 20197014424

Country of ref document: KR

Kind code of ref document: A

Ref document number: 2019527429

Country of ref document: JP

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112019009591

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2018230202

Country of ref document: AU

Date of ref document: 20180306

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01E

Ref document number: 112019009591

Country of ref document: BR

Free format text: REAPRESENTE A DECLARACAO REFERENTE AO DOCUMENTO DE PRIORIDADE DEVIDAMENTE ASSINADA, CONFORME ART. 408 C/C ART. 410, II, DO CODIGO DE PROCESSO CIVIL.

ENP Entry into the national phase

Ref document number: 112019009591

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20190510