• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    the embodiments of the present application reveal a consensus method and device based on a trust protocol. a trusted protocol node includes a first server, a second server, and at least one database. the method includes: storing, through the database, consensus data necessary for carrying out a consensus procedure, in which consensus data is invoked by the first server and the second server during the consensus procedure; obtain, by the second server instead of the first server, consensus data from the database and execute the consensus procedure based on the consensus data to generate a consensus result, in response to the determination that the first server has defect before the consensus procedure or during the consensus procedure; and store, by the second server, the consensus result in the database. according to the embodiments of the present invention, a normal server on a node can obtain, instead of a defective server, consensus data from a database to perform the consensus procedure. it ensures the normal execution of the consensus procedure and can, to some extent, improve the success rate of a consensus procedure, thereby improving the efficiency of the service processing of a trusted protocol.
    公开号:BR112019013379A2
    申请号:R112019013379
    申请日:2018-03-26
    公开日:2019-12-17
    发明作者:Tang Qiang
    申请人:Alibaba Group Holding Ltd；
    IPC主号:
    专利说明:

    “METHOD FOR CONSENSUS BASED ON TRUSTED PROTOCOL AND DEVICE FOR CONSENSUS BASED ON TRUSTED PROTOCOL”
    Technical Field [001] This application relates to the field of computer technologies and, in particular, to a consensus method and device based on a trust protocol (blockchain).
    Background of the Invention [002] Currently, reliable protocol technology is widely applied and its decentralization mode ensures that data is not easily tampered with, thus improving security.
    [003] In a practical application scenario, a trust protocol can provide a corresponding service to a client, and a trust protocol node can process a service request from a user and generate a corresponding processing result. However, the trust protocol can include a malicious node or a defective node. Undoubtedly, affecting the service obtained by the customer. Therefore, for example, a consensus procedure based on Practical Byzantine Fault Tolerance (PBFT) can be performed between nodes in the trust protocol, so that the nodes can agree on a correct processing result.
    [004] The PBFT-based consensus procedure is used as an example. As shown in Figure 1, the PBFT-based consensus procedure includes a pre-preparation (pre-preparation) step, a preparation (preparation) step and a confirmation (confirmation) step. A node (a node numbered 0 in Figure 1) that receives a service request from a customer (represented by C in Figure 1) sends the service request to other nodes (for example, nodes numbered 1, 2 and 3) to execute one
    Petition 870190059821, of 06/27/2019, p. 80/109
    2/26 consensus procedure. At each stage, the nodes send a consensus message to each other, so that the nodes perform a consensus procedure. After the three-stage consensus procedure, a consensus can be considered to have been reached. In this case, the nodes process the service request separately and each one returns a processing result to the customer.
    [005] In some scenarios in the existing technology, to process a large number of consensus procedures, a plurality of servers are generally arranged on each node in the trust protocol described above, and different servers can participate separately in different consensus procedures, to improve the amount of processing and processing efficiency of the trust protocol.
    [006] However, in practice, a server on a node may be defective, for example, it may be offline or restarted. For example, in the PBFT-based consensus procedure, once a server is defective, the server cannot continue participating in the consensus and affects the likelihood of reaching consensus. If a consensus is not reached in a given round, the consensus needs to be restarted from the pre-preparation stage, regardless of a consensus stage in which the trust protocol is currently in place. Apparently, this undoubtedly affects the efficiency of the trust protocol consensus, and further affects the efficiency of trust service processing.
    Brief Description of the Invention [007] Embodiments of the present invention provide a method and device of consensus based on a reliable protocol, to solve a current problem that the efficiency of consensus is relatively low when a server on a node has defect.
    Petition 870190059821, of 06/27/2019, p. 81/109
    3/26 [008] An embodiment of the present invention provides a consensus method based on a trust protocol. A trust protocol node includes a first server, a second server, and at least one database. The method includes: storing, through the database, consensus data necessary to carry out a consensus procedure, in which the consensus data is invoked by the first server and the second server during the consensus procedure; obtain, by the second server instead of the first server, consensus data from the database and execute the consensus procedure based on the consensus data to generate a consensus result, in response to the determination that the first server has defect before the consensus procedure or during the consensus procedure; and store, by the second server, the consensus result in the database.
    [009] An embodiment of the present invention provides a trust protocol based consensus device, wherein a trust protocol node includes a first server, a second server and at least one database; the database stores the consensus data needed to perform a consensus procedure, in which the consensus data is invoked by the first server and the second server during the consensus procedure; the first server is defective before the consensus procedure or during the consensus procedure; and the device includes: an acquisition module, configured to obtain consensus data corresponding to a consensus message from the database based on the consensus message; a consensus execution module, configured to execute the consensus procedure based on the consensus data to generate a consensus result; and a storage module, configured to store the consensus message and the consensus result in the database.
    Petition 870190059821, of 06/27/2019, p. 82/109
    4/26 [0010] According to the consensus method based on trust protocol and device provided in the embodiments of the present invention, for each server in a trust protocol node, a server participating in a certain consensus procedure “Publicly” stores consensus messages at different stages of consensus or a consensus result generated by the server at a current stage. In other words, the server stores, in a database in the trust protocol node, the consensus messages at the different stages of consensus or the consensus result generated by the server in the current step, and the database can be used to all servers in the trust protocol node. As such, if a server participating in a certain round of consensus is defective, for example, offline or restarted, the server's consensus data can be used by another server on the trust protocol node, and the other server can continue executing the corresponding consensus procedure in place of the defective server.
    [0011] Apparently, compared to the existing technology, in the method in which each server in a trust protocol node stores consensus data in a database in the trust protocol node, even when a given server is defective, a Normally functioning server can obtain corresponding consensus data from the database and complete consensus in place of the defective server. It ensures the normal execution of the consensus procedure and can improve to some extent a success rate of the consensus procedure, while the number of times of consensus reset is reduced, thus improving the service processing efficiency of a trusted protocol.
    Brief Description of the Drawings [0012] The attached drawings described here are intended to provide
    Petition 870190059821, of 06/27/2019, p. 83/109
    5/26 further understanding of this application and constitute a part of this application. The illustrative embodiments of the present application and their descriptions are intended to describe the present application and do not constitute any limitation to the present application. In the attached drawings:
    Figure 1 illustrates a PBFT-based consensus procedure on existing technology;
    Figure 2a illustrates an architecture of a trust protocol in a consensus procedure based on a trust protocol, according to an embodiment of the present application;
    Figure 2b illustrates an architecture of a trust protocol node in a consensus procedure based on a trust protocol, according to an embodiment of the present application;
    Figure 2c illustrates a consensus procedure based on a server-side trust protocol, in accordance with an embodiment of the present application;
    Figure 2d illustrates an architecture of another type of trust protocol node, according to an embodiment of the present invention;
    Figure 3a and Figure 3b are schematic diagrams that illustrate a server change process in the same consensus procedure, according to an embodiment of the present application; and
    Figure 4 is a schematic structural diagram illustrating a consensus device based on a trust protocol on one side of the server, according to an embodiment of the present application.
    Detailed Description of the Invention [0013] To make the objectives, technical solutions and advantages of this application clearer and more comprehensive, the technical solutions of this application are described below with reference to the embodiments
    Petition 870190059821, of 06/27/2019, p. 84/109
    6/26 specific and corresponding accompanying drawings of this application. Apparently, the described embodiments are just a few and not all embodiments of the present application. All other embodiments obtained by a person skilled in the art based on the embodiments of this application without creative efforts must fall within the scope of protection of this application.
    [0014] As described above, during any moment of consensus executed between nodes in a trust protocol, a server participating in the current consensus time on any node may be defective, for example, it may be offline or restarted and, consequently, the server cannot continue participating in the consensus. Therefore, a consensus success rate can be reduced. In particular, in a case of consensus based on PBFT, a number of consensus failures can trigger a garbage collection mechanism in the PBFT, to clear consensus data on each server. Apparently, this undoubtedly affects the service processing of the trust protocol.
    [0015] Based on the previous descriptions, the embodiments of the present invention provide a consensus method based on a protocol of trust. In the method, consensus data is stored in a database on a trust protocol node, so that when a server is malfunctioning (offline or restarted), a server that is functioning normally on the trust protocol node it can also read the consensus data that has been stored in the database and continues to execute a consensus procedure in place of the defective server. Certainly, the consensus method based on a protocol of trust in the embodiments of the present application is not limited to just a consensus procedure based on PBFT, and can also be used in a consensus procedure that is based on a
    Petition 870190059821, of 06/27/2019, p. 85/109
    7/26 consensus algorithm like Paxos.
    [0016] It is worth noting that, in the embodiments of the present application, an architecture used in the consensus method based on a trust protocol is shown in Figure 2a. It can be seen from Figure 2a that a trust protocol includes a plurality of trust protocol nodes. To facilitate subsequent description, a trust protocol node is referred to below briefly as a node.
    [0017] A plurality of clients can perform the service interaction with the trust protocol. The trust protocol can be a consortium chain and / or a private chain, and can provide a service to a user. The customer can include a browser, an application, etc. The client can run on a terminal, a server, a database etc. The embodiments are not specifically limited here.
    [0018] Based on the architecture shown in Figure 2a, an architecture of any node can be shown in Figure 2b. It can be seen from Figure 2b that, the node includes n servers and a database shared by the servers. Different servers can participate in different consensus procedures, and the servers can run independently of each other. The database is configured to provide a data storage service for the servers on the node. In other words, each server can store the corresponding consensus data in the database in a consensus procedure. Certainly, the number of databases on the node shown in Figure 2b is merely a common number. In practice, the number of databases on the node can be adjusted based on actual demand. In addition, in some scenarios, the server on the node can be replaced with a device that has a computing processing function, such as a computer.
    [0019] It is also worth noting that, for ease of description,
    Petition 870190059821, of 06/27/2019, p. 86/109
    8/26 below, a server that may be defective during execution is referred to as a first server, and a server that can normally run is referred to as a second server. Therefore, in the architecture shown in Figure 2b, it can be considered that the architecture includes two types of servers: the first server and the second server. The foregoing content should not be construed as limiting this application.
    [0020] Based on the relationship architecture shown in Figure 2b, an embodiment of the present invention provides a consensus procedure based on a trust protocol. As shown in Figure 2c, the procedure specifically includes the following steps.
    [0021] (S201). A database stores the consensus data needed to perform a consensus procedure, in which the consensus data is invoked by a first server and a second server during the consensus procedure.
    [0022] Based on the architecture of Figure 2b, the database is arranged on a node where the servers are located and is shared by all servers on the node. After receiving a consensus message or generating a consensus result, any server on the node stores the consensus message or consensus result in the database. Then, a server can obtain, from the database, consensus data needed to perform a consensus procedure. Consensus data can include a consensus message that is received by the server from a server on another node, a consensus result generated by the server, a service request sent by a client and that can trigger a consensus procedure, etc. .
    [0023] It is worth noting here that storing the consensus data in the database ensures that the consensus data is
    Petition 870190059821, of 06/27/2019, p. 87/109
    9/26 available to all servers on the node. That is, if the first server is at fault, although the first server cannot continue to participate in the consensus, the second server at the node can execute the consensus in place of the defective server based on the consensus data stored in the database.
    [0024] (S202). The second server obtains, in place of the first server, consensus data from the database and performs the consensus procedure based on the consensus data to generate a consensus result, in response to the determination that the first server is defective before consensus procedure or during the consensus procedure.
    [0025] During practical execution, the first server participating in the consensus may be defective (for example, it may be disabled or restarted), and the failure may occur on a random occasion, but the implementation of the consensus procedure is affected regardless of the first server is defective before the consensus procedure or during the consensus procedure. In this case, to ensure that the consensus procedure is not affected, the second server that is normally operating the trust protocol node can execute consensus in place of the first defective server.
    [0026] As the first server is defective and cannot continue executing the consensus. Therefore, the second server can receive a consensus message in place of the first server and participate in the consensus procedure in which the first server originally participates.
    [0027] As described above, any server on the node stores consensus data in the database, so that the second server can search the database and obtain the necessary consensus data in the consensus procedure, to execute consensus instead of first
    Petition 870190059821, of 06/27/2019, p. 88/109
    10/26 defective server, and still generate the corresponding consensus result.
    [0028] Apparently, the server that is working normally runs the consensus in place of the defective server, so it is ensured that the consensus procedure is not affected.
    [0029] (S203). The second server stores the consensus result in the database.
    [0030] In this embodiment of the present invention, the second server that performs consensus in place of the first server also stores the consensus result in the database as a type of consensus data based on a data storage mechanism in present invention.
    [0031] According to the previous steps, for each server in a trust protocol node, a server that participates in a certain consensus procedure “publicly” stores consensus messages at different stages of consensus or a consensus result generated by the server in a current step. In other words, the server stores, in a database in the trust protocol node, the consensus messages at the different stages of consensus or the consensus result generated by the server in the current step, and the database can be used to all servers in the trust protocol node. As such, if a server participating in a certain round of consensus is defective, for example, offline or restarted, the server's consensus data can be used by another server on the trust protocol node, and the other server can continue executing the corresponding consensus procedure in place of the defective server.
    [0032] Apparently, compared to existing technology, in the method in which each server on a node stores consensus data in a database on the node, even when a given server is
    Petition 870190059821, of 06/27/2019, p. 89/109
    11/26 defect, a functioning server can obtain corresponding consensus data from the database and complete consensus in place of the defective server. It ensures the normal execution of the consensus procedure and can improve to some extent a success rate of the consensus procedure, while the number of times of consensus reset is reduced, thus improving the service processing efficiency of a trusted protocol.
    [0033] It is worth noting here that, during the consensus procedure, any server on the node receives a consensus message that is sent by another device participating in the same consensus procedure. The other device includes, but is not limited to, another node and / or customer participating in the consensus procedure. The consensus message can include a service request that is sent by a customer and that can trigger consensus or it can include consensus data sent by another node in the consensus procedure.
    [0034] Apparently, for a given consensus procedure, if the first server is defective, the second server receives a consensus message in place of the first server, to participate in the consensus procedure of the first server.
    [0035] Therefore, in response to the determination that the first server is defective before the consensus procedure, that the second server obtains, in place of the first server, consensus data from the database may include: receiving, at least second server in place of the first server, a consensus message that is sent by another device participating in the consensus procedure and obtains consensus data corresponding to the consensus message from the database based on the consensus message, in response to the determination that the first server is defective before the consensus procedure.
    Petition 870190059821, of 06/27/2019, p. 90/109
    12/26 [0036] Furthermore, in this embodiment of the present invention, there is a retry mechanism. Specifically, after another device participating in the consensus procedure sends a consensus or service request message, the other device resends the same consensus or service request message if the other device does not receive a response from a final peer in specified period. It can be learned that if the first server is at fault during the consensus procedure, the first server will not be able to respond to another device at the specified time.
    [0037] Therefore, in response to the determination that the first server is defective during the consensus procedure, the second server receives, in place of the first server, a consensus message that another device participating in the consensus procedure tries again to send , and obtains consensus data corresponding to the consensus message from the database based on the consensus message.
    [0038] The second server usually obtains consensus data from the database based on a corresponding identifier in a consensus message. The following describes a process for obtaining consensus data from the database.
    [0039] During a PBFT-based consensus procedure, a service request corresponds to a consensus procedure and a node (also referred to as a master node) that receives a service request from a customer number (for example , indexes) of the service request. In other words, a number associated with the service request may correspond exclusively to a consensus procedure.
    [0040] Specifically, in a given consensus procedure in which any server on a node participates, a number (ie
    Petition 870190059821, of 06/27/2019, p. 91/109
    13/26 a service request identifier) of a service request in the consensus procedure can uniquely identify a consensus procedure. The number associated with the service request can be used to distinguish the consensus procedure from a consensus procedure in which another server on the node participates. Therefore, if the server receives a consensus message that carries a number associated with a given service request, the server can obtain consensus data (the consensus data obtained and the consensus message belong to the same consensus procedure) that has the same service request number as the database based on the service request number.
    [0041] For example, in a consensus procedure, a consensus message format can be: <consensus stage identifier, a display number, a service request number and a service request summary>. It is assumed that a server receives a specific consensus message ccommit, v, n, D (m)>, where commit indicates that the node has entered a confirmation step, v indicates a display number, n indicates an associated number to a service request, and D (m) indicates a subscription, from a node sending a notification message, to the service request. In this case, the server can search the database for all consensus data corresponding to the number “n” based on the number “n”.
    [0042] Based on the previous descriptions, a process of obtaining, by the second database server, the consensus data corresponding to the consensus message is as follows: The second server searches, based on an included service request identifier in the consensus message, in the database and obtain the consensus data corresponding to the identifier.
    [0043] In addition to the previous content, in practice, to prevent a
    Petition 870190059821, of 06/27/2019, p. 92/109
    14/26 consensus message is sent to the first defective server, in this embodiment of the present invention, the consensus message can be scheduled using an access port (gateway) on the node. That is, the trust protocol node also includes the access port. In this case, a node architecture can be shown in Figure 2d. It can be seen that the gateway is responsible for scheduling a consensus message to the server on the node. Since the first server is defective, the gateway does not send a consensus message to the first defective server; instead, it sends the consensus message to the second server that is functioning normally.
    [0044] Therefore, specifically, for the second server, a process of receiving a consensus message can be as follows:
    [0045] The access port forwards the received consensus message to the second server that is functioning normally, which is sent by the other device participating in the consensus procedure, when the access port determines that the first server is defective before consensus procedure. In this case, the second server receives the consensus message that is sent by the other device participating in the consensus procedure and which is forwarded through the access door.
    [0046] In addition, the access port forwards the consensus message received that the other device participating in the consensus procedure tries to send again, when the access port determines that the first server is defective during the consensus procedure. Correspondingly, the second server receives the consensus message that the other device participating in the consensus procedure tries to send again and that it is forwarded through the access port.
    [0047] It can be understood that, in this way of carrying out the
    Petition 870190059821, of 06/27/2019, p. 93/109
    In the present invention, the access port forwards the consensus message to the second normal server on the node. In other words, the gateway needs to know about a defective server and a server that continues to function normally on the node.
    [0048] In this embodiment of the present invention, each server on the node can communicate with the access door using a heartbeat mechanism, so that the access door can know a functioning state of each server . That is, the access port determines a health status of the first server and a health status of the second server in the following method: receive health status messages sent by the first server and the second server to the access door. access door based on a predetermined period; and determining, by the gateway, the health status of the first server and the health status of the second server based on health messages.
    [0049] That is, if the gateway can receive a periodic health message, the gateway can determine that a server that sends the health message operates normally; and if the gateway does not receive any health status messages from a particular server within a specified period, the gateway can determine that the server is defective.
    [0050] The following uses an example application for description.
    [0051] For example, as shown in Figure 3a, it is assumed that both the server (11) on node (1) and the server (21) on node (2) participate in a certain consensus procedure (Figure 3a shows , in gray, that the two servers are in the same consensus procedure). It is further assumed that the server (21) is offline (that is, on node (2), the server (21) is the first
    Petition 870190059821, of 06/27/2019, p. 94/109
    16/26 server). In this case, the server (11) sends a certain consensus message to the server (21). Apparently, since server (21) is offline, server (21) does not provide any feedback. In this case, after waiting for a specific period of time, the server (11) initiates a new attempt (the new attempt can also be considered as a new attempt initiated by the node (1)), in other words, resends the consensus message . After an access port on node (2) receives the consensus message that node (1) tries to send again, the access port selects a particular server that normally operates within node (2), to process the retry the node (1). As shown in Figure 3b, in this example, server (22) on node (2) is selected (i.e., server (22) is the second server). That is, the gateway forwards, to the server (22), the consensus message that the node (1) tries to send again, and the server (22) performs the consensus procedure in place of the server (21).
    [0052] In addition, for a storage process, by the second server, the consensus data on the server, in a method in this embodiment of the present invention, the second server can store a received consensus message (the consensus message can be considered as a type of consensus data) in the database immediately after receiving the consensus message, and storing a consensus result (the consensus result can also be considered as a type of consensus data) corresponding to the consensus message in the database after generating the consensus result through a consensus procedure.
    [0053] Additionally, in another method in this embodiment of the present invention, after receiving a consensus message, the second server waits for a consensus result to generate through the preceding process, and then stores the consensus message
    Petition 870190059821, of 06/27/2019, p. 95/109
    17/26 together with the consensus result in the database.
    [0054] The two previous methods of storage do not constitute any limitation in this application.
    [0055] The consensus method based on the trust protocol provided in the embodiments of the present application is described above. Based on the same idea, as shown in Figure 4, an embodiment of the present invention further provides a consensus device based on a trust protocol. A trusted protocol node includes a plurality of servers and at least one database. The database stores the consensus data needed to perform a consensus procedure, in which the consensus data is invoked by a first server and a second server during the consensus procedure.
    [0056] The first server is defective before the consensus procedure or during the consensus procedure.
    [0057] The consensus device based on a trust protocol includes at least one receiver module (401), an acquisition module (402), a consensus execution module (403) and a storage module (404).
    [0058] The acquisition module (402) is configured to obtain consensus data from the database.
    [0059] The consensus execution module (403) is configured to execute the consensus procedure based on the consensus data to generate a consensus result.
    [0060] The storage module (404) is configured to store the consensus result in the database.
    [0061] The receiving module (401) is configured to receive a consensus message that is sent by another participating device
    Petition 870190059821, of 06/27/2019, p. 96/109
    18/26 in the consensus procedure, and the acquisition module is configured to obtain consensus data corresponding to the consensus message from the database based on the consensus message, in response to the determination that the first server is defective before the consensus procedure.
    [0062] The receiving module (401) is configured to receive a consensus message that another device participating in the consensus procedure tries to send again, and the acquisition module is configured to obtain consensus data corresponding to the consensus message from database based on the consensus message, in response to the determination that the first server is defective during the consensus procedure.
    [0063] The other device tries to send the consensus message again when the other device sends the consensus message, but receives no response after a specified time.
    [0064] The consensus message includes a service request identifier. The acquisition module (402) is configured to search, based on the service request identifier included in the consensus message, the database and obtain consensus data corresponding to the identifier.
    [0065] In addition, the trust protocol node may also include an access port. In this case, the device further includes at least an access door receiver module (405), an operating state determination module (406), and a routing module (407).
    [0066] The routing module (407) is configured to forward, to the second server that normally operates, the received consensus message that is sent by the other device participating in the consensus procedure, when the status determination module
    Petition 870190059821, of 06/27/2019, p. 97/109
    19/26 operation (406) determines that the first server is defective before the consensus procedure.
    [0067] The routing module (407) is configured to forward, to the second server that normally works, the consensus message received that the other device participating in the consensus procedure tries to send again, when the status determination module (406) determines that the first server is defective during the consensus procedure.
    [0068] The access door receiver module (405) is configured to receive health status messages that are sent by the first server and the second server to the access door based on a predetermined period.
    [0069] The health determination module (406) is configured to determine a health status of the first server and a health status of the second server based on health messages.
    [0070] In the 1990s, if a technical improvement is a hardware improvement (for example, an improvement to a circuit structure like a diode, a transistor or a switch) or a software improvement (an improvement to a method) can be clearly distinguished. However, as technologies develop, current improvements in many method procedures can be seen as direct improvements in hardware circuit structures. Almost all designers program an improved method procedure on a hardware circuit to obtain a corresponding hardware circuit structure. Therefore, a method procedure can be improved using a hardware entity module. For example, a programmable logic device (PLD) (for example, an FPGA (Field
    Petition 870190059821, of 06/27/2019, p. 98/109
    20/26
    Programmable Gate Array)) is an integrated circuit, and a logical PLD function is determined by a user through device programming. The designer performs the programming to "integrate" a digital system into a PLD without asking a chip manufacturer to design and manufacture an application-specific integrated circuit chip. In addition, nowadays, instead of manually manufacturing an integrated circuit chip, this type of programming is mainly implemented using the “logical compiler” software. The "logical compiler" software is similar to a software compiler used to develop and write a program. The original code needs to be written in a specific programming language before it can be compiled. The language is referred to as a hardware description language (HDL). There are many HDLs, such as Advanced Boolean Expression Language (ABEL), Altera Hardware Description Language (AHDL), Confluence, Cornell University Programming Language (CUPL), HDCal,
    Java Hardware Description Language (JHDL), Lava, Lola, MyHDL,
    PALASM and the Ruby hardware description language (RHDL). The very high speed integrated circuit hardware (VHDL) description language and Verilog are most used today. A person skilled in the art should also understand that a hardware circuit that implements a logical method procedure can be easily obtained as long as the method procedure is logically programmed using the various preceding hardware description languages and programmed in an integrated circuit.
    [0071] A controller can be implemented in any appropriate way. For example, the controller may be in the form of a microprocessor, a processor, a computer-readable medium that stores computer-readable program code (such as software or firmware) that can be executed by the microprocessor or processor,
    Petition 870190059821, of 06/27/2019, p. 99/109
    21/26 a logic port, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller or a built-in microprocessor. Controller examples include, but are not limited to, the following microprocessors: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320. A memory controller can alternatively be implemented as part of a memory's control logic. A person skilled in the art also knows that, in addition to implementing the controller using computer-readable program code, method steps can be logically programmed to allow the controller to implement the same function in the form of the logic port, the switch, the integrated circuit application-specific, programmable logic controller, built-in microcontroller, etc. Therefore, the controller can be considered as a hardware component, and a device that is included in the controller and configured to implement various functions can also be considered as a structure in the hardware component. Alternatively, the device configured to implement various functions can even be considered as a software module to implement the method and a structure in the hardware component.
    [0072] The system, device, module or unit illustrated in the previous embodiments can be implemented specifically using a computer chip or an entity, or using a product having a certain function. A typical deployment device is a computer. Specifically, the computer can be, for example, a personal computer, a portable computer, a mobile phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an e- mail, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
    Petition 870190059821, of 06/27/2019, p. 100/109
    22/26 [0073] To facilitate description, the previous device is described by dividing the device into several units based on the functions. Certainly, when the present invention is implemented, the functions of the units can be implemented in one or more pieces of software and / or hardware.
    [0074] A person skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system or a computer program product. Therefore, the present invention can use a form of hardware implementations, software-only implementations or implementations by a combination of software and hardware. In addition, the present invention may use a form of computer program product that is implemented on one or more storage media usable per computer (including but not limited to magnetic disk storage, CD-ROM, optical memory, etc.) that include program code usable by computer.
    [0075] The present description is described with reference to the flowcharts and / or block diagrams of the method, the device (system) and the computer program product according to the embodiments of the present invention. It is worth noting that computer program instructions can be used to implement each process and / or each block in flowcharts and / or block diagrams and a combination of processes and / or blocks in flowcharts and / or block diagrams . These computer program instructions can be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor from another programmable data processing device to generate a machine, so that instructions executed by the computer or the processor another programmable data processing device manages a device to implement
    Petition 870190059821, of 06/27/2019, p. 101/109
    23/26 a specific function in one or more processes in flowcharts and / or in one or more blocks in block diagrams.
    [0076] These computer program instructions can alternatively be stored in a computer-readable memory that can instruct a computer or other programmable data-processing device to function in a specific way, so that the instructions stored in the computer-readable memory generate an artifact that includes an instructional device. The instruction device implements a specific function in one or more processes in the flowcharts and / or in one or more blocks in the block diagrams.
    [0077] These computer program instructions can, alternatively, be loaded on a computer or other programmable data processing device, so that a series of operations and steps are performed on the computer or on the other programmable device, thus generating implemented processing per computer. Therefore, instructions executed on the computer or other programmable device provide steps to implement a specific function in one or more processes in flowcharts and / or in one or more blocks in block diagrams.
    [0078] In a typical configuration, a computing device includes one or more processors (CPU), one or more input / output interfaces, one or more network interfaces, and one or more memories.
    [0079] Memory may include non-persistent memory, random access memory (RAM), non-volatile memory and / or other form of memory on computer-readable media, for example, a read-only memory (ROM) or a flash memory (flash RAM). Memory is an example of a computer-readable medium.
    [0080] The computer-readable medium includes persistent media, not
    Petition 870190059821, of 06/27/2019, p. 102/109
    24/26 persistent, mobile and immobile that can store information using any method or technology. The information can be a computer-readable instruction, a data structure, a program module or other data. Examples of a computer storage medium include but are not limited to a parameter random access memory (PRAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), another type of memory random access (RAM), a read-only memory (ROM), an electrically erasable programmable read memory (EEPROM), a flash memory or other memory technology, a compact disk read memory (CD-ROM), a disk digital versatile (DVD) or other optical storage, magnetic tape, magnetic tape, magnetic disk memory or other magnetic storage device or any other non-transmission medium that can be used to store information accessible to the computing device. Based on the definition of this specification, the computer-readable medium does not include computer-readable transient means (transient means), such as a modulated data signal and vehicle.
    [0081] It is also worth noting that the terms "comprise", "include", or any other variants thereof, are intended to cover a non-exclusive inclusion, so that a process, method, product or device that includes a list of elements does not only include those elements, but also includes other elements that are not expressly listed or still includes elements inherent in such a process, method, product or device. Without further restrictions, an element preceded by "includes a ..." does not exclude the existence of additional identical elements in the process, method, product or device that includes the element.
    [0082] A person skilled in the art should understand that the embodiments of the present invention can be provided as a method,
    Petition 870190059821, of 06/27/2019, p. 103/109
    25/26 a computer program product or system. Therefore, the present application may use a form of hardware-only implementations, software-only implementations or implementations with a combination of software and hardware. In addition, the present invention may use a form of computer program product that is implemented on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, CD-ROM, optical memory, etc. .) that include program code usable by computer.
    [0083] The present invention can be described in the general context of computer executable instructions executed by a computer, for example, a program module. Generally, the program module includes a routine, a program, an object, a component, a data structure, etc. to perform a specific task or implement a specific abstract data type. The present invention can alternatively be practiced in distributed computing environments. In these distributed computing environments, tasks are performed by remote processing devices that are connected via a communications network. In distributed computing environments, the program module can be located on both local and remote computer storage media, including storage devices.
    [0084] The embodiments in this specification are described in a progressive manner. For equal or similar parts of the embodiments, mutual references can be made to the embodiments. Each embodiment focuses on a difference from other embodiments. In particular, a system embodiment is basically similar to a method embodiment and is therefore briefly described. For related parties, references can be made to some descriptions in the method's realization.
    Petition 870190059821, of 06/27/2019, p. 104/109
    26/26 [0085] The preceding descriptions are merely embodiments of this application and are not intended to limit this application. A person skilled in the art can make several modifications and changes to this application. Any modification, equivalent substitution, improvement, etc., made without departing from the spirit and principle of this order, must fall within the scope of the claims of this order.
    权利要求:
    Claims (11)
    [1]
    Claims
    1. METHOD FOR CONSENSUS BASED ON TRUST PROTOCOL (blockchain), characterized by the fact that the method comprises:
    store, through a database of a trust protocol node, consensus data necessary to perform a consensus procedure, in which consensus data is invoked by a first server and a second server during the consensus procedure, in that the trust protocol node is included in a trust protocol and comprises the first server, the second server and the database;
    receive, by the second server in place of the first server and from another device, a consensus message that is sent by the other device participating in the consensus procedure;
    in response to determining that the first server is defective, obtain, by the second server in place of the first server, consensus data from the database; the consensus data corresponding to the database consensus message based on the consensus message;
    execute the consensus procedure based on the consensus data to generate a consensus result, in response to the determination that the first server is defective before the consensus procedure or during the consensus procedure; and store, by the second server, the consensus result in the database.
    [2]
    2. METHOD, according to claim 1, characterized by the fact that the determination that the first server is defective before or during the consensus procedure comprises determining that the first server has been restarted.
    [3]
    3. METHOD, according to claim 1, characterized
    Petition 870190059821, of 06/27/2019, p. 106/109
    2/3 due to the fact that the other device tries again to send the consensus message when the other device sends the consensus message, but receives no response after a specified time.
    [4]
    4. METHOD, according to claim 1, characterized by the fact that the consensus message comprises a service request identifier.
    [5]
    5. METHOD, according to claim 4, characterized by the fact that obtaining the consensus data corresponding to the consensus message from the database, based on the consensus message, comprises specifically:
    search the database for the second server based on the service request identifier included in the consensus message and obtain consensus data corresponding to the identifier.
    [6]
    6. METHOD, according to claim 1, characterized by the fact that the trust protocol node also comprises an access door.
    [7]
    7. METHOD, according to claim 6, characterized by the fact that the receipt of the consensus message sent by another device participating in the consensus procedure comprises:
    forward, through the access door to the second server that is functioning normally, the consensus message sent by the other device participating in the consensus procedure, in response to the determination that the first server is defective before the consensus procedure; and receive, by the second server, the consensus message that is sent by the other device participating in the consensus procedure and that is forwarded through the access door.
    [8]
    8. METHOD, according to claim 7, characterized
    Petition 870190059821, of 06/27/2019, p. 107/109
    3/3 due to the fact that receiving the consensus message that another device participating in the consensus procedure tries to send again understands:
    forward, through the access port to the second normally functioning server, the consensus message that the other device participating in the consensus procedure tries to send again, in response to the determination that the first server is failing during the consensus procedure ; and receive, by the second server, the consensus message that the other device participating in the consensus procedure tries to send again and that it is forwarded through the access door.
    [9]
    9. METHOD, according to claim 8, characterized by the fact that the access door determines a state of functioning of the first server and a state of functioning of the second server, performing operations comprising:
    receive, through the access port, health status messages that are sent by the first server and the second server to the access port based on a predetermined period; and determining, by the gateway, the health status of the first server and the health status of the second server based on health messages.
    [10]
    10. METHOD, according to claim 1, characterized by the fact that the trust protocol comprises at least one consortium chain and one private chain.
    [11]
    11. DEVICE FOR CONSENSUS BASED ON TRUSTED PROTOCOL, characterized by the fact that the device comprises a plurality of modules configured to execute the method, as defined in any of claims 1 to 10.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112019013379A2|2019-12-17|trusted protocol based consensus method and trusted protocol based consensus device
    BR112019020374B1|2022-01-25|Method, non-transient computer-readable storage media and system for blockchain consensus
    AU2018243075B2|2020-06-18|Service processing and consensus method and device
    ES2880448T3|2021-11-24|Consensus procedure and device
    ES2626655T3|2017-07-25|Failover of grouped clients
    BR112019012905A2|2019-12-03|method for submitting transaction information and device for submitting transaction information
    US20180157516A1|2018-06-07|Allocating or announcing availability of a software container
    WO2017025203A1|2017-02-16|Managing lifecycle of a software container
    BR112019009576A2|2019-10-22|data processing method and device
    Biswas et al.2018|A novel leader election algorithm based on resources for ring networks
    WO2018004403A1|2018-01-04|Managing a lifecycle of a software container
    CN110870286B|2021-07-09|Fault tolerance processing method and device and server
    Bouteiller et al.2016|Surviving errors with openshmem
    BR112019009591B1|2021-11-23|COMPUTER IMPLEMENTED METHOD FOR PERFORMING DISPLAY SWITCHING IN A TRUST PROTOCOL NETWORK, COMPUTER-READABLE, NON- TRANSIENT, AND COMPUTER IMPLEMENTED SYSTEM
    BR112019010368B1|2021-12-14|METHOD FOR PROCESSING A SERVICE REQUEST AND DEVICE FOR PROCESSING A SERVICE REQUEST
    US20220086037A1|2022-03-17|Technique for Connection Handling in a Distributed System
    BR112019010368A2|2019-11-12|methods for processing a service request and devices for processing a service request
    BR112019019871A2|2020-04-22|consensus verification method and apparatus
    CN111488247A|2020-08-04|High-availability method and device for managing and controlling multiple fault tolerance of nodes
    同族专利:
    公开号 | 公开日
    CA3048742A1|2018-10-04|
    CN107368507B|2020-03-27|
    CN111327703A|2020-06-23|
    PH12019501519A1|2020-03-09|
    MX2019007808A|2019-09-04|
    US20200201719A1|2020-06-25|
    AU2018241568A1|2019-07-18|
    JP6756924B2|2020-09-16|
    CN107368507A|2017-11-21|
    ZA201904224B|2021-05-26|
    EP3547170A4|2019-11-20|
    US10642699B2|2020-05-05|
    US20190324867A1|2019-10-24|
    WO2018177255A1|2018-10-04|
    CA3048742C|2021-07-20|
    KR102255724B1|2021-05-27|
    TW201837748A|2018-10-16|
    RU2731331C1|2020-09-01|
    KR20190099222A|2019-08-26|
    EP3547170B1|2021-09-01|
    US10846182B2|2020-11-24|
    EP3547170A1|2019-10-02|
    AU2018241568B2|2020-12-03|
    JP2020514865A|2020-05-21|
    TWI696083B|2020-06-11|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US6215766B1|1998-01-30|2001-04-10|Lucent Technologies Inc.|Hierarchical rate control of receivers in a communication system transmitting layered video multicast data with retransmission |
    US9361311B2|2005-01-12|2016-06-07|Wandisco, Inc.|Distributed file system using consensus nodes|
    TWI416901B|2005-11-30|2013-11-21|Ibm|Failure tolerant transaction processing system|
    US7725764B2|2006-08-04|2010-05-25|Tsx Inc.|Failover system and method|
    CN101394306B|2008-07-08|2010-10-27|国电南瑞科技股份有限公司|Seamless switching method for dual server system|
    CN102724272B|2011-12-30|2017-12-29|新奥特（北京）视频技术有限公司|A kind of backup method of TV station's service distribution data|
    RU2510623C2|2012-04-19|2014-04-10|Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации |Method for information replication in distributed databases with competitive flow distribution|
    US20150172412A1|2012-07-06|2015-06-18|Cornell University|Managing dependencies between operations in a distributed system|
    CN103220165B|2013-03-20|2017-04-19|杭州华三通信技术有限公司|Processing method and device for server active downtime|
    US20160125403A1|2014-04-28|2016-05-05|Chin-hao Hu|Offline virtual currency transaction|
    CN103744809B|2013-12-23|2016-10-05|天泽信息产业股份有限公司|Vehicle information management system double hot standby method based on VRRP|
    US20150310476A1|2014-04-24|2015-10-29|Elizabeth M. Gadwa|System and method for attention based currency|
    US9690675B2|2014-07-17|2017-06-27|Cohesity, Inc.|Dynamically changing members of a consensus group in a distributed self-healing coordination service|
    US9436923B1|2015-02-26|2016-09-06|Skuchain, Inc.|Tracking unitization occurring in a supply chain|
    TWI676943B|2015-05-06|2019-11-11|現代財富控股有限公司|Electronic trading system for cryptocurrency and method thereof|
    US20170048209A1|2015-07-14|2017-02-16|Fmr Llc|Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems|
    US10268744B2|2015-09-22|2019-04-23|Walmart Apollo, Llc|System for maintaining consistency across a decentralized database cluster and method therefor|
    CN105912618B|2016-04-07|2019-04-23|浙江万马新能源有限公司|The charging pile charging transaction means of communication and device based on block chain|
    KR101701131B1|2016-04-28|2017-02-13|주식회사 라피|Data recording and validation methods and systems using the connecting of blockchain between different type|
    CN106060036B|2016-05-26|2019-07-16|布比（北京）网络技术有限公司|Decentralization common recognition method and device|
    CN106209877A|2016-07-19|2016-12-07|井创（北京）科技有限公司|A kind of be certification core with block chain backstage false-proof authentication system|
    CN106296191A|2016-08-13|2017-01-04|深圳市樊溪电子有限公司|A kind of PoW common recognition mechanism of block chain power-aware|
    CN106339639A|2016-08-30|2017-01-18|弗洛格（武汉）信息科技有限公司|Credit score management method and system based on block chain|
    US20180062831A1|2016-08-31|2018-03-01|Jiangang Zhang|Massively Scalable Blockchain Ledger|
    CN106452785B|2016-09-29|2019-05-17|财付通支付科技有限公司|Block chain network, branch node and block chain network application method|
    US10158527B2|2016-10-28|2018-12-18|International Business Machines Corporation|Changing an existing blockchain trust configuration|
    CN106528775B|2016-10-28|2020-01-03|济南大学|Private block chain operation support system supporting logic multi-chain and working method thereof|
    CN106341421B|2016-10-31|2019-04-02|杭州云象网络技术有限公司|A kind of method for interchanging data based on block chain technology|
    CN106534273A|2016-10-31|2017-03-22|中金云金融（北京）大数据科技股份有限公司|Block chain metadata storage system, and storage method and retrieval method thereof|
    US10862959B2|2016-11-28|2020-12-08|Keir Finlow-Bates|Consensus system and method for adding data to a blockchain|
    WO2018112949A1|2016-12-23|2018-06-28|深圳前海达闼云端智能科技有限公司|Block chain mining method, device, and node apparatus|
    US10291413B2|2017-02-17|2019-05-14|Accenture Global Solutions Limited|Hardware blockchain corrective consensus operating procedure enforcement|
    US20180267539A1|2017-03-17|2018-09-20|Jeanne Louise Shih|Distributive networks of groups of moveable autonomous devices|
    CN107368507B|2017-03-28|2020-03-27|创新先进技术有限公司|Block chain-based consensus method and device|
    US10984134B2|2017-07-14|2021-04-20|Microsoft Technology Licensing, Llc|Blockchain system for leveraging member nodes to achieve consensus|US10817873B2|2017-03-22|2020-10-27|Factom, Inc.|Auditing of electronic documents|
    CN107368507B|2017-03-28|2020-03-27|创新先进技术有限公司|Block chain-based consensus method and device|
    CN110445619B|2017-03-30|2020-10-16|腾讯科技（深圳）有限公司|Block chain system, message processing method and storage medium|
    US10270599B2|2017-04-27|2019-04-23|Factom, Inc.|Data reproducibility using blockchains|
    CN108111604B|2017-12-21|2020-08-14|广州广电运通金融电子股份有限公司|Block chain consensus method, device and system, and identification information processing method and device|
    CN108200208B|2018-02-11|2021-01-05|南宁师范大学|Logistics block chain consensus algorithm based on cloud computing|
    CN108537525B|2018-03-09|2020-06-09|阿里巴巴集团控股有限公司|Consensus verification method, device and equipment|
    CN108763302A|2018-04-19|2018-11-06|深圳市网心科技有限公司|Block chain common recognition processing method, electronic device and computer readable storage medium|
    CN108665363B|2018-05-09|2021-08-03|合肥达朴汇联科技有限公司|Block chain consensus achieving device|
    US10783164B2|2018-05-18|2020-09-22|Factom, Inc.|Import and export in blockchain environments|
    US11170366B2|2018-05-18|2021-11-09|Inveniam Capital Partners, Inc.|Private blockchain services|
    CN109144781B|2018-08-13|2021-06-18|浙商银行股份有限公司|Method for improving disaster recovery capability of single-park deployment of application system realized based on block chain technology|
    CN110969527A|2018-09-29|2020-04-07|北京天能博信息科技有限公司|Data processing method of block chain and related equipment|
    BR112019008172B1|2018-11-07|2022-01-25|Advanced New Technologies Co., Ltd|Computer-implemented method of facilitating a consensus process in a trusted protocol network based on practical Byzantine fault tolerance, computer-readable non-transient storage medium, and system|
    CN110266765B|2019-05-21|2022-03-01|西安中星测控有限公司|Real-time updating method and device for Internet of things online consensus node based on block chain|
    CN110492988B|2019-07-03|2020-07-21|特斯联（北京）科技有限公司|Multi-path parallel multiplexing big data system and processing method thereof|
    CN110336707A|2019-08-07|2019-10-15|卓尔智联研究院有限公司|Block chain common recognition device, method and computer readable storage medium|
    WO2021166931A1|2020-02-21|2021-08-26|パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ|Control method, control device, and program|
    CN111064813B|2020-03-16|2020-06-30|支付宝信息技术有限公司|Method and device for synchronizing processing messages during block chain consensus processing|
    CN111654415B|2020-05-28|2021-09-10|腾讯科技（深圳）有限公司|Block chain based information processing method, device, equipment and readable storage medium|
    CN111522696B|2020-07-03|2020-12-29|支付宝信息技术有限公司|Downtime processing method, data persistence method and hardware of block chain common identification node|
    CN112286731A|2020-07-03|2021-01-29|支付宝信息技术有限公司|Restarting processing method of block chain consensus node, consensus node and block chain system|
    CN112100234B|2020-08-12|2021-09-10|北京大学|Content addressing method and system of graph type account book based on random consensus|
    CN113254306A|2021-05-10|2021-08-13|支付宝信息技术有限公司|Running state monitoring method, device, equipment and storage medium|
    CN113067895B|2021-06-02|2021-08-31|支付宝信息技术有限公司|Method for building block chain sub-network and block chain system|
    法律状态:
    2021-04-06| B25A| Requested transfer of rights approved|Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-04-27| B25A| Requested transfer of rights approved|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-10-13| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    2022-01-11| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2022-01-11| B15K| Others concerning applications: alteration of classification|Free format text: A CLASSIFICACAO ANTERIOR ERA: G06F 17/30 Ipc: G06F 11/14 (2006.01), H04L 29/08 (2006.01) |
    优先权:
    申请号 | 申请日 | 专利标题
    CN201710190786.1A|CN107368507B|2017-03-28|2017-03-28|Block chain-based consensus method and device|
    PCT/CN2018/080513|WO2018177255A1|2017-03-28|2018-03-26|Blockchain-based consensus method and device|
    [返回顶部]