Faster view change for blockchain

1 . An apparatus, comprising:

a network interface configured to receive, from a plurality of peers in a group of peers within a blockchain network, a plurality of view change messages with a request to change a role of a lead peer of a consensus process for the group of peers, wherein each view change message of the plurality of view change messages comprises metadata including a view number and a plurality of signatures corresponding to the group of peers, wherein the plurality of signatures are based at least in part on a hash of a block being added to a blockchain ledger of the blockchain network before the lead peer experiences a fault, the plurality of signatures having been collected from prepare messages of the group of peers; and

a processor configured to:

verify, based on respective metadata included in the plurality of view change messages, that the lead peer has faulted during a proposed in-process change to the blockchain ledger and that a predetermined threshold of the plurality of view change messages identify a same view number and a same hash of the block,

identify a next lead peer of the group of peers based on the metadata included in the plurality of view change messages,

verify the plurality of signatures included in the plurality of view change messages based on the hash of the block and the view number to determine that peers satisfying the predetermined threshold agree on the proposed in-process change to the blockchain ledger,

generate, based at least in part on the plurality of signatures, a view data message comprising a checkpoint of the blockchain ledger of the blockchain network and signed prepare messages from other peers that include the hash of the block and the view number,

compare the checkpoint in the view data message to the hash of the block in the plurality of view change messages to verify that a current state of the blockchain ledger matches the proposed in-process change to the blockchain ledger, and wherein the network interface is further configured to:

transmit the view data message to the next lead peer from among the group of peers with instructions to lead a next consensus process for the group of peers after receipt of the view data message without waiting for the predetermined threshold of view data messages.

2 . The apparatus of claim 1 ,

wherein the network interface is further configured to receive a plurality of messages from a plurality of peers in the group of peers, and the processor is further configured to verify sequence numbers based on respective metadata included in the plurality of messages.

3 . The apparatus of claim 1 ,

wherein the metadata includes information corresponding to the current state of the blockchain ledger of the blockchain network.

4 . The apparatus of claim 1 ,

wherein the processor is further configured to receive a new block from the next lead peer, execute a blockchain consensus process with the next lead peer based on the new block, and commit the new block to the blockchain ledger of the blockchain network.

5 . The apparatus of claim 1 ,

wherein the view number identifies the next lead peer within an on-chain file.

6 . The apparatus of claim 1 ,

wherein the metadata includes a sequence number identifying a next block to be added to the blockchain ledger.

7 . A method, comprising:

receiving, from a plurality of peers in a group of peers within a blockchain network, a plurality of view change messages with a request to change a role of a lead peer of a consensus process for the group of peers, wherein each view change message of the plurality of view change message comprises metadata including a view number and a plurality of signatures corresponding to the group of peers, wherein the plurality of signatures are based at least in part on a hash of a block being added to a blockchain ledger of the blockchain network before the lead peer experiences a fault, the plurality of signatures having been collected from prepare messages of the group of peers;

verifying, based on respective metadata included in the plurality of view change messages, that the lead peer has faulted during a proposed in-process change to the blockchain ledger and that a predetermined threshold of the plurality of view change messages identify a same view number and a same hash of the block;

identifying a next lead peer of the group of peers based on the metadata included in the plurality of view change messages;

generating, based at least in part on the plurality of signatures, a view data message comprising a checkpoint of the blockchain ledger of the blockchain network and signed prepare messages from other peers that include the hash of the block and the view number;

comparing the checkpoint in the view data message to the hash of the block in the plurality of view change messages to verify that a current state of the blockchain ledger matches the proposed in-process change to the blockchain ledger; and

transmitting the view data message to the next lead peer from among the group of peers with instructions to lead a next consensus process for the group of peers after receipt of the view data message without waiting for the predetermined threshold of view data messages.

8 . The method of claim 7 , further comprising:

receiving a plurality of messages from a plurality of peers in the group of peers and verifying sequence numbers based on respective metadata included in the plurality of messages.

9 . The method of claim 7 ,

wherein the metadata includes information corresponding to the current state of the blockchain ledger of the blockchain network.

10 . The method of claim 7 , further comprising:

receiving a new block from the next lead peer, executing a blockchain consensus process with the next lead peer based on the new block, and committing the new block to the blockchain ledger of the blockchain network.

11 . The method of claim 7 ,

wherein the view number identifies the next lead peer within an on-chain file.

12 . The method of claim 7 ,

wherein the metadata includes a sequence number identifying a next block to be added to the blockchain ledger.

13 . A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising:

one or more instructions that, when executed by one or more processors of a device, cause the device to:

receive, from a plurality of peers in a group of peers within a blockchain network, a plurality of view change messages with a request to change a role of a lead peer of a consensus process for the group of peers, wherein each view change message of the plurality of view change messages comprises metadata including a view number and a plurality of signatures corresponding to the group of peers, wherein the plurality of signatures are based at least in part on a hash of a block being added to a blockchain ledger of the blockchain network before the lead peer experiences a fault, the plurality of signatures having been collected from prepare messages of the group of peers;

verify, based on respective metadata included in the plurality of view change messages, that the lead peer has faulted during a proposed in-process change to the blockchain ledger and that a predetermined threshold of the plurality of view change messages identify a same view number and a same hash of the block;

identify a next lead peer of the group of peers based on the metadata included in the plurality of view change messages;

verify the plurality of signatures included in the plurality of view change messages based on the hash of the block and the view number to determine that peers satisfying the predetermined threshold agree on the proposed in-process change to the blockchain ledger;

generate, based at least in part on the plurality of signatures, a view data message comprising a checkpoint of the blockchain ledger of the blockchain network and signed prepare messages from other peers that include the hash of the block and the view number;

compare the checkpoint in the view data message to the hash of the block in the plurality of view change messages to verify that a current state of the blockchain ledger matches the proposed in-process change to the blockchain ledger; and

transmit the view data message to the next lead peer from among the group of peers with instructions to lead a next consensus process for the group of peers after receipt of the view data message without waiting for the predetermined threshold of view data messages.

14 . The non-transitory computer-readable medium of claim 13 ,

wherein the one or more instructions cause the device to:

receive a plurality of messages from a plurality of peers in the group of peers and verifying sequence numbers based on respective metadata included in the plurality of messages.

15 . The non-transitory computer-readable medium of claim 13 ,

wherein the metadata includes information corresponding to the current state of the blockchain ledger of the blockchain network.

16 . The non-transitory computer-readable medium of claim 13 ,

wherein the one or more instructions cause the device to:

receive a new block from the next lead peer, executing a blockchain consensus process with the next lead peer based on the new block, and committing the new block to the blockchain ledger of the blockchain network.

17 . The non-transitory computer-readable medium of claim 13 ,

wherein the metadata includes a sequence number identifying a next block to be added to the blockchain ledger.

18 . An apparatus, comprising:

a network interface configured to receive, from a primary peer, a message that is a pre-prepare message of a Byzantine fault tolerant consensus process which comprises proposed data to be added to a blockchain ledger,

receive prepare messages from other consensus peers of the blockchain ledger, and

transmit a view change message to a next primary peer in response to a fault of the primary peer; and

a processor configured to:

generate a hash of the proposed data to be added to the blockchain ledger;

generate a prepare message which comprises a signature over the hash of the proposed data and a hash puzzle;

transmit the prepare message to a plurality of other consensus peers of the blockchain ledger;

determine that a predetermined threshold of the received prepare messages include a same hash of the proposed data;

generate a commit message comprising a solution to the hash puzzle, and transmit the commit message to the other consensus peers, such that the other consensus peers verify, by hashing the solution and matching a resulting hash to the hash puzzle in the prepare message, that a same consensus peer sent both the prepare message and the commit message; and

generate, in response to detecting that the primary peer has faulted, the view change message to include the hash of the proposed data, metadata comprising a view number and a sequence number, and signatures collected from the received prepare messages that prove that a majority of blockchain peers are in process of a same update to the blockchain ledger, for use by the next primary peer, before transmitting a new view message, to verify an in-process change to a state of the blockchain ledger based on one view data message rather than waiting for a predetermined threshold of view data messages, wherein the one view data message includes a checkpoint that matches the hash of the proposed data.

19 . The apparatus of claim 18 ,

wherein the network interface is further configured to receive a plurality of prepare messages sent from the plurality of other consensus peers, and determine that the plurality of prepare messages satisfy the predetermined threshold.

20 . The apparatus of claim 18 ,

wherein the processor is configured to add the view number and the sequence number to the prepare message prior to transmission of the prepare message to the plurality of other consensus peers.

21 . The apparatus of claim 18 ,

wherein the view number identifies the next primary peer and the sequence number identifies a next block to be added to the blockchain ledger.

22 . A method, comprising:

receiving, from a primary peer, a message that is a pre-prepare message of a Byzantine fault tolerant consensus process which comprises proposed data to be added to a blockchain ledger;

receiving prepare messages from other consensus peers of the blockchain ledger,

transmitting a view change message to a next primary peer in response to a fault of the primary peer;

generating a hash of the proposed data to be added to the blockchain ledger;

generating a prepare message which comprises a signature over the hash of the proposed data and a hash puzzle;

transmitting the prepare message to a plurality of other consensus peers of the blockchain ledger;

determining that a predetermined threshold of the received prepare messages include a same hash of the proposed data;

generating a commit message comprising a solution to the hash puzzle, and transmit the commit message to the other consensus peers, such that the other consensus peers verify, by hashing the solution and matching a resulting hash to the hash puzzle in the prepare message, that a same consensus peer sent both the prepare message and the commit message; and

generating, in response to detecting that the primary peer has faulted, the view change message to include the hash of the proposed data, metadata comprising a view number and a sequence number, and signatures collected from the received prepare messages that prove that a majority of blockchain peers are in process of a same update to the blockchain ledger, for use by the next primary peer, before transmitting a new view message, to verify an in-process change to a state of the blockchain ledger based on one view data message rather than waiting for a predetermined threshold of view data messages, wherein the one view data message includes a checkpoint that matches the hash of the proposed data.

23 . The method of claim 22 , further comprising:

receiving a plurality of prepare messages sent from the plurality of other consensus peers, and determining that the plurality of prepare messages satisfy the predetermined threshold.

24 . The method of claim 22 , further comprising:

adding the view number and the sequence number to the prepare message prior to transmission of the prepare message to the plurality of other consensus peers.

25 . The method of claim 22 ,

wherein the view number identifies the next primary peer and the sequence number identifies a next block to be added to the blockchain ledger.