Consensus system downtime recovery

Patent metadata

Field	Value
Publication number	US-2020004643-A1
Application number	US-201916490871-A
Country	US
Kind code	A1
Filing date	Mar 18, 2019
Priority date	Mar 18, 2019
Publication date	Jan 2, 2020
Grant date	—

Abstract

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for consensus system downtime recovery. One of the methods includes: obtaining a pre-prepare message from the primary node; multicasting a prepare message indicating an acceptance of the pre-prepare message to at least some of the primary node and the other (N−2) backup nodes; obtaining (Q−1) or more prepare messages respectively from (Q−1) or more of the backup nodes; storing the pre-prepare message and the (Q−1) or more prepare messages; multicasting a commit message to at least some of the primary node and the other backup nodes, the commit message indicating that the one backup node agrees to the (Q−1) or more prepare messages; and obtaining, respectively from Q or more nodes among the primary node and the backup nodes, Q or more commit messages each indicating that the corresponding node agrees to (Q−1) or more prepare messages.

First claim

1 .- 15 . (canceled)

16 . A computer-implemented consensus method to be implemented on a blockchain maintained by a number (N) of nodes, wherein one of the nodes acts as a primary node and the other (N−1) nodes act as backup nodes, and the method is performed by one of the backup nodes, the method comprising:
obtaining a pre-prepare message from the primary node;
multicasting a prepare message to at least some of the primary node and the other (N−2) backup nodes, the prepare message indicating an acceptance of the pre-prepare message;
obtaining (Q−1) or more prepare messages respectively from (Q−1) or more of the backup nodes, wherein Q (quorum) is (N+F+1)/2 rounded up to the nearest integer, and F is (N−1)/3 rounded down to the nearest integer;
storing the pre-prepare message and the (Q−1) or more prepare messages;
multicasting a commit message to at least some of the primary node and the other backup nodes, the commit message indicating that the one backup node agrees to the (Q−1) or more prepare messages; and
obtaining, respectively from Q or more nodes among the primary node and the backup nodes, Q or more commit messages each indicating that the corresponding node agrees to (Q−1) or more prepare messages received by the corresponding node.

17 . The method of claim 16 , wherein:
before obtaining the pre-prepare message from the primary node, the method further comprises obtaining one or more transaction requests from at least one of: a client, the primary node, or one or more of the other backup nodes; the pre-prepare message comprises an order of one or more transactions corresponding to the one or more transaction requests; the commit message indicates that the corresponding node that sent the commit message agrees to the order; and the method further comprises packing the one or more transactions into a local copy of the blockchain maintained by the one backup node according to the order.

18 . The method of claim 16 , wherein storing the pre-prepare message and the (Q−1) or more prepare messages comprises:
storing only the pre-prepare message and the (Q−1) or more prepare messages.

19 . The method of claim 16 , wherein:
the (Q−1) or more prepare messages include the multicast prepare message; and the Q or more commit messages include the multicast commit message.

20 . The method of claim 16 , after multicasting the commit message, further comprising:
performing a system restart; and loading the stored pre-prepare message and the stored (Q−1) or more prepare messages.

21 . The method of claim 16 , after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, further comprising:
performing a system restart; and
loading the stored pre-prepare message and the stored (Q−1) or more prepare messages.

22 . The method of claim 21 , after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, further comprising:
multicasting a view change message comprising the loaded pre-prepare message and the loaded (Q−1) or more prepare messages.

23 . The method of claim 22 , after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, further comprising:
obtaining from a new primary node a new view message indicating that the new primary node has received Q or more view change messages each indicating that the corresponding node agrees to the view change message;
multicasting another prepare message to at least some of the backup nodes including the new primary node, the another prepare message indicating an acceptance of the new view message; and
obtaining another (Q−1) or more prepare messages respectively from (Q−1) or more of the backup nodes.

24 . The method of claim 22 , after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, further comprising:
obtaining, respectively from Q or more of the backup nodes, Q or more view change messages each indicating that the corresponding node agrees to the view change message;
multicasting to at least some of the backup nodes a new view message indicating that the one backup node acting as a new primary node has received the Q or more view change messages; and
obtaining another (Q−1) or more prepare messages respectively from (Q−1) or more of the backup nodes.

25 . The method of claim 21 , wherein performing the system restart comprises:
performing the system restart without triggering a view change.

26 . A consensus system for maintaining a blockchain, wherein a number of N nodes maintain the blockchain with one of the N nodes acting as a primary node and the other (N−1) nodes acting as backup nodes, the consensus system acting as one of the (N−1) backup nodes and comprising one or more processors and one or more non-transitory computer-readable memories coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system to perform operations comprising:
obtaining a pre-prepare message from the primary node;
multicasting a prepare message to at least some of the primary node and the other (N−2) backup nodes, the prepare message indicating an acceptance of the pre-prepare message;
obtaining (Q−1) or more prepare messages respectively from (Q−1) or more of the backup nodes, wherein Q (quorum) is (N+F+1)/2 rounded up to the nearest integer, and F is (N−1)/3 rounded down to the nearest integer;
storing the pre-prepare message and the (Q−1) or more prepare messages;
multicasting a commit message to at least some of the primary node and the other backup nodes, the commit message indicating that the one backup node agrees to the (Q−1) or more prepare messages; and
obtaining, respectively from Q or more nodes among the primary node and the backup nodes, Q or more commit messages each indicating that the corresponding node agrees to (Q−1) or more prepare messages received by the corresponding node.

27 . The system of claim 26 , wherein, after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, the operations further comprise:
performing a system restart; and
loading the stored pre-prepare message and the stored (Q−1) or more prepare messages.

28 . The system of claim 27 , wherein, after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, the operations further comprise:
multicasting a view change message comprising the loaded pre-prepare message and the loaded (Q−1) or more prepare messages.

29 . The system of claim 28 , wherein, after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, the operations further comprise:
obtaining from a new primary node a new view message indicating that the new primary node has received Q or more view change messages each indicating that the corresponding node agrees to the view change message;
multicasting another prepare message indicating an acceptance of the new view message to at least some of the backup nodes including the new primary node; and
obtaining another (Q−1) or more prepare messages respectively from (Q−1) or more of the backup nodes.

30 . The system of claim 28 , wherein, after storing the pre-prepare message and the (Q−1) or more prepare messages and before multicasting the commit message, the operations further comprise:
obtaining, respectively from Q or more of the

Assignees

• Alibaba Group Holding Ltd

Inventors

• Yang Dayi

Classifications

• G06F11/1464 Primary

  for networked environments · CPC title

• H04L9/0637

  Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM] · CPC title

• G06F11/1438

  Restarting or rejuvenating · CPC title

• G06F21/57 Primary

  Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities · CPC title

• H04L9/3239

  involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD · CPC title