US11362808B2 - Method and system for consensus in a permissioned blockchain - Google Patents
Method and system for consensus in a permissioned blockchain Download PDFInfo
- Publication number
- US11362808B2 US11362808B2 US16/904,329 US202016904329A US11362808B2 US 11362808 B2 US11362808 B2 US 11362808B2 US 202016904329 A US202016904329 A US 202016904329A US 11362808 B2 US11362808 B2 US 11362808B2
- Authority
- US
- United States
- Prior art keywords
- block
- privileged
- node
- nodes
- timeout
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active, expires
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H04L2209/38—
Definitions
- the present disclosure generally relates to blockchain consensus. More precisely, the present disclosure relates to a consensus method for creating new blocks in a permissioned blockchain.
- the present disclosure is based on, and claims priority from Indian application 201941050462 filed on 6 Dec. 2019, the disclosure of which is incorporated by reference herein.
- Consensus is a mechanism for blockchain nodes to create and agree on a new block to be appended to the blockchain in a secure manner
- secure means immunity against malicious attacks on the system. Internal faults and attacks are prevented by consensus methods with the reasonable assumption that a minimum number of honest nodes are present. For example, two thirds of the nodes are assumed to be honest and non-faulty in BFT (Byzantine Fault Tolerant) methods.
- BFT Binaryzantine Fault Tolerant
- PoET Proof-of-Elapsed-Time
- PBFT Practical Byzantine Fault Tolerant
- a leader is elected and only the leader appends blocks and the followers accept the blocks. This does not address the problem of byzantine behaviour of the nodes and the leader is always assumed to be honest.
- the network In several existing methods employing an elected leader for one or more number of blocks, if a leader loses network connectivity, the network must start the process of electing a leader again after waiting for a predefined time. This may lead to a loss of service during that period.
- a system and a method that provides a secure consensus method in a permissioned blockchain protocol and does not have a high computational overhead is needed.
- a method for appending a new block to a blockchain in a permissioned blockchain includes sending a plurality of first messages by each of a designated plurality of privileged nodes, individually, to each of the other privileged nodes of the plurality of privileged nodes.
- the contents of each of the first messages are calculated using a first predefined method.
- the method includes computing a first wait time based on the plurality of first messages received, by each of the plurality of privileged nodes using a second predefined method.
- a timer which is set to the computed first wait time, is initiated.
- the method includes creating and broadcasting a timeout reveal message to all the other privileged nodes and creating the new block for appending to the permissioned blockchain by the privileged node whose timer times out before the timers of the other privileged nodes time out.
- the method includes computing a second wait time using the second predefined method by each of the privileged nodes receiving the timeout reveal message.
- the method includes validating the first wait time with the second wait time, by each of the other privileged nodes.
- the method includes appending the new block created to its own copy of the block chain, provided the second wait time is substantially the same as the time waited for by the privileged node that broadcasted the timeout reveal message after previous block was created.
- FIG. 1 is a system illustrating a mechanism for proof-of-coordinated-wait-time consensus, present in each of a privileged node in a permissioned blockchain network, in accordance with one embodiment of the present disclosure
- FIG. 2 illustrates an exemplary permissioned blockchain network showing a set of privileged nodes taking part in consensus, in accordance with one embodiment of the present disclosure
- FIG. 3 illustrates a method implemented for peer coordination by the privileged nodes in the permissioned blockchain network, for computation of a timeout value for creating a new block; in accordance with one embodiment of the present disclosure
- FIG. 4 illustrates a method implemented for block creation cycle in a permissioned blockchain network, in accordance with one embodiment of the present disclosure
- FIG. 5 illustrates a method implemented for sending random timeout period messages by a privileged node to each of the peer privileged nodes in the permissioned blockchain network, in accordance with one embodiment of the present disclosure
- FIG. 6 illustrates a method implemented for receiving and processing the random timeout period message by a privileged node from each of the peer privileged nodes in accordance with one embodiment of the present disclosure
- FIG. 7 illustrates a method implemented for creating and broadcasting a new block by a privileged node from each of the peer privileged nodes, in accordance with one embodiment of the present disclosure
- FIG. 8 illustrates a method implemented for creating and broadcasting timeout reveal message by the privileged node creating a new block, in accordance with one embodiment of the present disclosure
- FIG. 9 illustrates a method implemented for block receiving cycle and appending the block to blockchain by the nodes receiving the block, in accordance with one embodiment of the present disclosure
- FIG. 10 illustrates a method implemented for receiving and validating the timeout reveal message by nodes receiving the block, in accordance with one embodiment of the present disclosure
- FIG. 11 illustrates a method implemented for receiving and validating a new block, in accordance with one embodiment of the present disclosure
- FIG. 12 illustrates a method implemented for contention resolution, in accordance with one embodiment of the present disclosure
- FIG. 13 illustrates an example scenario showing privileged nodes N 1 , N 2 , N 3 , N 4 , N . . . Nn) and plurality of first messages ((N 1 - 2 , N 1 - 3 , N 1 - . . . N 1 - n ), (N 2 - 1 , N 2 - 3 , N 2 - . . . N 2 - n ), . . . (Nn- 1 , Nn- 2 , Nn- . . . Nn-(n ⁇ 1))), in accordance with one embodiment of the present disclosure;
- FIG. 14 illustrates an example scenario showing timers T 1 , T 2 , T 3 , T 4 , T . . . , Tn for each of the privileged nodes N 1 , N 2 , N 3 , N 4 , N . . . , Nn and a timeout reveal message TORM broadcast by the privileged node N 2 , whose timer T 2 times out before the timers T 1 , T 3 , T 4 , T . . . , Tn of the other privileged nodes time out, in accordance with one embodiment of the present disclosure;
- FIG. 15 is a flow chart illustrating a method for appending a new block to a blockchain in a permissioned network, in accordance with one embodiment of the present disclosure
- FIG. 16 is a timing diagram that shows the timing of the sequence of events involved in creating a new block for being appended to the blockchain and arriving at the consensus according to this disclosure.
- FIG. 17 is a is a sequence diagram that shows the sequence of events involved in creating a new block for being appended to the blockchain and arriving at the consensus according to this disclosure.
- Embodiments of the present disclosure relates to a method for consensus in a permissioned blockchain protocol.
- permissioned blockchain networks allows the network to appoint a group of participants (for example, nodes) from the network, who have the express authority to provide the validation of blocks of transactions.
- the consensus methods in a private, or permissioned blockchain is designed for a specific business purpose where the counterparties are known.
- the data posted to the blockchain network must be verified in an automated manner by the relevant parties (nodes) to the transaction.
- Embodiments of the present disclosure provide a method that has an improved tolerance to network partitioning, when up to one third of the total number of nodes have network failure and cannot communicate with the other nodes and the remaining two thirds of the total number of nodes can continue with the consensus method, without any adverse effects.
- the sequence of possible leaders in the blockchain network exists, but is not known to any node, including the current leader node at any given time. Thus, if the current leader fails, the leader next in sequence shall create the block.
- the present disclosure discloses a method that may also be less susceptible to denial-of-service (DoS) attacks. Since the creator of the block (current leader for a block) is non-deterministic, that is, it cannot be predicted a priori, unless and until the block is created, the probability of successful denial-of-service attacks against the block creator is very low.
- DoS denial-of-service
- the present disclosure relates to a method of reaching consensus for appending a new block to the blockchain such that all the nodes in the blockchain network have identical copies of a given block in the blockchain.
- each of the privileged nodes has the prior information with respect to: the identity of all its peer privileged nodes, digital signature public key, digital signature public encryption key or (EC)DH public key.
- each privileged node of the network is in a position to establish a symmetric key with each of the peer privileged nodes using any of the existing mechanisms as known in art, that may include ECDH key exchange or encrypting the symmetric key generated on one of the nodes with its peer's public asymmetric encryption key.
- the digital certificate of each of the nodes is itself present in the blockchain, so that every node in the permissioned blockchain network can be used as trusted information.
- the information in the digital certificate in the preferred embodiment includes the node identifier, ECDSA public key, ECDH public key for establishing symmetric keys between peer nodes.
- the word ‘node’, ‘privileged nodes’, and ‘participants’ used in the description may refer to the network node in a permissioned blockchain and are synonyms, in this context and may be used interchangeably.
- the word ‘privileged nodes’, ‘nodes’ used in the description are referred to as (N 1 , N 2 , N 3 , N . . . Nn), or by ‘N” are synonyms, in this context and may be used interchangeably.
- the word ‘first message’, ‘random timeout message’ used in the description are referred to as ((N 1 - 2 , N 1 - 3 , N 1 - . . . N 1 - n ), (N 2 - 1 , N 2 - 3 , N 2 - . . . N 2 - n ), . . . (Nn- 1 , Nn- 2 , Nn- . . . Nn-(n ⁇ 1))), are synonyms, in this context and may be used interchangeably.
- the word ‘first wait time’, ‘least timeout value’ used in the description are referred to as (WT 1 , WT 2 , WT . . . WTn), are synonyms, in this context and may be used interchangeably.
- timer ‘timer’, ‘block creation timer’ used in the description are referred to as (T 1 , T 2 , T . . . , Tn), are synonyms, in this context and may be used interchangeably.
- the privileged node whose timer times out before the timers of the other privileged nodes is referred to as privileged node N 2 , node ‘m’, node ‘n’, privileged node creating a new block, are synonyms, in this context and may be used interchangeably.
- each of the privileged nodes (N 1 , (no N 2 ), N 3 , . . . Nn) receiving the timeout reveal message (TORM) are also referred as the peer privileged node in the description.
- N 2 is the node whose timer has timed out before the timers of the other nodes have timed out and N 2 creates the new block.
- (no N 2 ) has been included in the list of nodes in parenthesis.
- FIG. 1 is a system 100 illustrating a mechanism for proof-of-coordinated-wait-time consensus, present in each of a privileged node in a permissioned blockchain network, in accordance with one embodiment of the present disclosure.
- the step of creating and broadcasting a new block is shown by reference numeral 105 .
- a contention resolution section 110 a timer management section 115 , a peer timeout value coordination section 125 are activated.
- a storage space 130 for a next block number and block hash for acceptance is created after the step of 105 .
- the step 120 illustrates the step of receiving and validating a new block section.
- Each step as shown in FIG. 1 is described in detail below.
- FIG. 2 illustrates an exemplary permissioned blockchain network 150 showing a set of privileged nodes taking part in consensus, in accordance with one embodiment of the present disclosure.
- a subset of nodes 161 , 162 , 163 and so on in this blockchain network form the set of privileged nodes 160 .
- the privileged nodes 161 , 162 , 163 may participate in a consensus method for creating and appending new blocks to blockchain.
- the remaining normal peer nodes 171 , 172 , 173 and so on as shown in FIG. 2 may participate in validation of transactions and blocks and may store a copy of the blockchain.
- FIG. 3 illustrates a method 300 implemented for peer coordination by the privileged nodes in the permissioned blockchain network, for computation of a timeout value for creating a new block, in accordance with one embodiment of the present disclosure.
- FIG. 3 illustrates the steps performed by the peer timeout value coordination section 125 of FIG. 1 .
- the step 305 for creating and sending signed and encrypted random timeout messages by each privileged node, individually to each peer privileged nodes is shown.
- the step 305 is executed, when a block is appended to the blockchain.
- the peer timeout value coordination section also includes a procedure to process random timeout message from each peer privileged node as shown by step 310 and a storage 315 to store the peer random timeout messages.
- FIG. 4 illustrates an exemplary method 400 implemented for block creation cycle in a permissioned blockchain network, in accordance with one embodiment of the present disclosure.
- the steps for block creation cycle are performed by privileged nodes of the permissioned blockchain network.
- a privileged node is selected from the group of privileged nodes and is configured for creating the block and appending the block to the blockchain.
- the steps performed by the nodes for creating the block and appending the block to the blockchain are explained in detail below.
- the method 400 illustrates an example of a new block creation by a node “m”.
- the starting of a new block creation cycle begin when a block numbered “i” is appended to the blockchain at step 402 by node “m”, the block “i” having been either created by node “m” or by some other node in the permissioned blockchain network.
- node “m” sends a random timeout message that contains the block number and block hash of the most recent block accepted and appended to the blockchain, to each of the peer privileged nodes.
- the block number and block hash values together with the message header comprising source and destination identifiers is signed with ECDSA (Elliptic Curve Digital Signature Algorithm) private key of node “m” and encrypted with symmetric key shared between node “m” and respective peer privileged node.
- ECDSA Elliptic Curve Digital Signature Algorithm
- the random timeout message is sent by each of the peer privileged nodes to all the peer privileged nodes that are active and authorized to be part of consensus procedure in the permissioned blockchain network.
- the random timeout message from node “m” also signifies that node “m” has accepted block “i”.
- the total number of random timeout messages exchanged would be (N (N ⁇ 1)) for one block creation cycle.
- the node “m” receives random timeout messages from its peer privileged nodes.
- Each of the privileged nodes are expected to receive a maximum of (N ⁇ 1) random timeout messages.
- the node “m” processes the received random timeout message that includes computation of a random timeout value and random nonce. If random timeout messages are received from at least two-thirds of total privileged nodes, then a timeout value is selected by node “m” from the computed set of 2-tuples, comprising a random timeout value and random nonce. Receiving two-thirds random timeout messages also implies that two-thirds of the privileged nodes in the permissioned blockchain network have accepted block “i”.
- the current block number “i” is incremented at step 410 and block creation timer is started with the selected timeout value at step 412 . If node “m” has the least timeout value among all the other privileged nodes, then block creation timer of node “m” expires first and the procedure to create and broadcast new block is executed at step 414 . After the new block has been broadcasted, the block “i” is appended to blockchain by node “m” at step 402 and the next block creation cycle begins.
- FIG. 5 illustrates a method 500 implemented for sending random timeout period messages by a privileged node to each of the peer privileged nodes in the permissioned blockchain network, in accordance with one embodiment of the present disclosure.
- the method 500 illustrates the steps performed by nodes, to send random timeout messages to each other peer privileged node after appending a block “i” to its copy of blockchain.
- the random timeout message is created for the peer privileged node, with “j” as destination node id and source id as node “m”.
- the block number and block hash of block “i” are included as parameters in the random timeout message.
- the message is digitally signed by node “m” with its ECDSA private key at step 512 .
- the signed message is encrypted with symmetric key shared between node “m” and node “j”. The encrypted message is then sent to node “j”.
- “j” is incremented to continue the loop. If the random timeout messages have been sent to all the peer privileged nodes, the process stops at step 506 .
- FIG. 6 illustrates a method 600 implemented for receiving and processing the random timeout message, by a privileged node from each of the peer privileged nodes in accordance with one embodiment of the present disclosure.
- the method 600 illustrates the steps performed by each privileged node for receiving and processing the random timeout period messages from each of the other privileged nodes.
- the random timeout message is received by node “n” from a peer privileged node “j”.
- the message is decrypted by node “n” using the symmetric key shared between node “n” and node “j”. Then the decrypted message signature verification is done by node “n”.
- step 606 If the signature verification is determined to have failed at step 606 , then the processing stops at step 624 . If the signature verification is determined to be successful at step 606 , then the block number and block hash accepted by the peer privileged node “j” is verified. If this is determined to be the same as the block number and block hash accepted by node “n” at step 608 , then node “n” performs the computation of random timeout value and random nonce at step 610 as described below.
- step 608 if the block number and block hash accepted by the peer privileged node “j” is not the same as the block number and block hash accepted by node “n”, then the processing stops at step 624 .
- a random timeout value is computed at step 610 in a pre-fixed range ‘T R ’ in milliseconds with a granularity ‘g’ of ten milliseconds (10 ms) in this embodiment.
- the pre-fixed range for random timeout value is 2000 ms to 10,000 ms.
- a random nonce is computed with a pre-fixed length of 4-bytes in this embodiment. The detailed steps to compute the random timeout and random nonce are as follows.
- H S SHA256_Hash( S ) H S is 32 bytes in length and is split into two halves of 16 bytes each.
- H1 S H S [0] . . . H S [15]
- H 2 S H S [16] . . . H S [31]
- Q S H 1 S ⁇ H 2 S
- Q S is 16 bytes in length and is split into two halves of 8 bytes each.
- T j T Min +( T mod( T R /g ))
- T j and N j corresponds to the random timeout value and random nonce computed by node “n” from random timeout message received from a peer privileged node “j”.
- T j and N j are added to the set of 2-tuples by node “n”.
- the random timeout message is added to the storage 315 ( FIG. 3 ) at step 612 .
- the 2-tuples are sorted in ascending order of random timeout values and the 2-tuples corresponding to first “k” nodes with least timeout values are considered.
- step 620 the timeout value is selected for node “n” at index “I” computed in step 618 in the sorted set of 2-tuples. This completes the processing and selecting the timeout values from the set of 2-tuples and the selected timeout value is returned to the caller at step 622 to start the block creation timer. Thereafter, the processing stops at step 624 .
- FIG. 7 illustrates a method 700 implemented for creating and broadcasting a new block by a privileged node ‘m’ from each of the peer privileged nodes, in accordance with one embodiment of the present disclosure.
- the method 700 illustrates the steps performed by nodes in the permissioned blockchain network, for creating and broadcasting a new block.
- the steps to be performed by nodes for creating and broadcasting a new block starts when the block creation timer expires at step 702 in node “m”.
- a new block “i” is created at step 704 that includes pending transactions to be committed in a block.
- a cryptographic hash of the block is computed.
- a timeout reveal message is created that includes all the random timeout messages received from peer privileged nodes of node ‘m”.
- the timeout reveal message also includes the block number and block hash computed for the new block.
- This message is then digitally signed with ECDSA private key of node “m” and broadcasted to all nodes Immediately following this, the block “i” that has been created is broadcasted to all the nodes at step 708 .
- FIG. 8 illustrates a method 800 implemented for creating and broadcasting timeout reveal message by the privileged node creating a new block, in accordance with one embodiment of the present disclosure.
- the method 800 illustrates the steps performed by the privileged node creating a new block, for creating and broadcasting timeout reveal message to all the nodes.
- the block number, block hash and random timeout value of block “i” created are obtained. Using the block number, it is determined if block “i” is a contention block at step 804 . If block “i” is a contention block, then contention resolution procedure is executed at step 806 . If block “i” is determined to be not a contention block at step 804 or if block “i” wins the contention resolution procedure at step 808 , then the block number and block hash to be accepted for block “i” is updated in the storage 130 ( FIG. 1 ) at step 810 . If block “i” does not win the contention at step 808 then processing stops at step 818 .
- a timeout reveal message is framed by node “m” with data containing all the random timeout messages from all the peer privileged nodes of node “m” that was used to compute the random timeout value by node “m” for the current block “i”.
- the random timeout messages that is retrieved from storage 315 will be in plain text (decrypted) and will contain the digital signature of the respective peer privileged node that sent this message to node “m”.
- node “m” digitally signs the timeout reveal message with its ECDSA private key and broadcasts the timeout reveal message to all the nodes at step 816 . Then the processing stops at step 818 .
- block creation timer of two nodes for example, “m” and “l” can timeout at the same time or at nearly the same time, such that neither timeout reveal message nor the new block from either of the nodes has been received by the other before either of the nodes send the timeout reveal message. It is also possible that block creation timer of one node can expire after receiving the timeout reveal message from the other node, but before receiving the subsequent block. It is also possible that one of the nodes having a shorter timeout value times out after the other node has timed out since they started the timers at slightly different times.
- a contention block is accepted up to 1 second from the time a block “i” is received and appended to blockchain. This contention block might either get rejected or can replace block “i”, based on the contention resolution procedure 110 depicted in FIG. 1 . The details of the procedure are explained later in this disclosure.
- contention as described herein is also commonly known as a fork in the blockchain. So, contention resolution is equivalent to fork resolution. Since there is a resolution before the next block is appended, in this embodiment, the method provides block finality one second (1 s) after the time at which block “i” is received”. It has to be noted here that block finality means an assurance that the block is not going to be replaced and hence, the transactions confirmed in the block can be acted upon.
- FIG. 9 illustrates a method 900 implemented for block receiving cycle and appending the block to blockchain by the nodes receiving the block, in accordance with one embodiment of the present disclosure.
- the method 900 illustrates the steps performed to receive a new block “i” by a node “n” and append to its copy of blockchain.
- step 902 Let the starting of a new block receiving cycle begin at step 902 when a block numbered “i” is appended to the blockchain by node “n”, the block “i” having been either created by node “n” or by some other node in the permissioned blockchain network.
- node “n” sends a random timeout message that contains the block number and block hash of the most recent block accepted and appended to the blockchain, to each of the peer privileged nodes.
- the block number and block hash values together with the message header comprising source and destination identifiers is signed with ECDSA private key of node “n” and encrypted with symmetric key shared between node “n” and respective peer privileged node.
- the random timeout message is sent by each of the peer privileged nodes to all the peer privileged nodes that are active and authorized to be part of consensus procedure in the permissioned blockchain network.
- the random timeout message from node “n” also signifies that node “n” has accepted block “i”.
- node “n” receives random timeout messages from its peer privileged nodes.
- Each of the privileged nodes are expected to receive a maximum of (N ⁇ 1) random timeout messages.
- node “n” processes the received random timeout message that includes computation of a random timeout value and random nonce. If random timeout messages are received from two-thirds of total privileged nodes, then a timeout value is selected by node “n” from the computed set of 2-tuples, comprising a random timeout value and random nonce. Receiving two-thirds random timeout messages also implies that two-thirds of the privileged nodes in the permissioned blockchain network have accepted block “i”.
- the current block number “i” is incremented at step 910 and block creation timer is started with the selected timeout value at step 912 . If node “n” does not have the least timeout value among all the privileged nodes, then block creation timer of node “n” does not expire first. If block creation timer of node “m” expires first, then block “n” receives, and processes timeout reveal message from node “m” for block “i” at step 914 .
- Node “n” will validate the received timeout reveal message at step 916 .
- node “n” will receive block “i” and if the validation of the received block is successful, it is accepted and appended to blockchain by node “n” at step 902 .
- the next block creation cycle begins.
- the block validation steps include, but not limited to validation of individual transactions, block format validation, digital signature verification etc.
- the block acceptance or rejection logic is dependent on the blockchain framework implementation and the fields present in the block header. So, this is not discussed in this disclosure.
- FIG. 10 illustrates a method 1000 implemented for receiving and validating the timeout reveal message by nodes receiving the block, in accordance with one embodiment of the present disclosure.
- the method 1000 illustrates the steps performed to receive and process the timeout reveal message for block “i” from node “m” by node “n” is shown.
- step 1002 the timeout reveal message is received by node “n” and the authenticity and integrity of the message is verified using the digital signature present in the message and ECDSA public key of node “m”.
- step 1004 for each random timeout message that is part of data section of the timeout reveal message, sender's signature is verified along with correctness of destination node, block number and block hash. If the validation result of step 1004 is determined to be successful at step 1006 , then the timeout value for the block “i” is computed by node “n” at step 1008 , the method of computing the timeout value being the same as that computed by node “m” for starting the block creation timer.
- step 1014 If the validation result of step 1004 is determined to have failed, then the processing stops at step 1014 and the timeout reveal message and the subsequent block “i” from node “m” will be ignored.
- node “n” computes the elapsed time since the last block was created and at step 1012 validates whether node “m” waited for the correct timeout value before sending block “i”. If the validation is successful, then at step 1016 , the block number and block hash present in the timeout reveal message and computed random timeout value of block “i” are obtained. Using the block number, at step 1018 , it is determined if block “i” is a contention block. If it is a contention block, the contention resolution procedure is executed at step 1022 .
- block “i” is not a contention block or if this block wins the contention resolution procedure at step 1024 , then the block number and block hash to be accepted for block “i” is updated in the storage 130 at step 1020 . Thereafter the processing stops at step 1014 . If block “i” does not win the contention resolution procedure at step 1024 , node “n” will not accept the block “i” received subsequently and the processing stops at step 1014 .
- FIG. 11 illustrates a method 1100 implemented for receiving and validating a new block, in accordance with one embodiment of the present disclosure.
- the method 1100 illustrates the steps performed to receive and validate a new block “i” by node “n” is shown.
- step 1104 the block number and block hash of the block “i” received is matched with the values stored in storage 130 when a previous timeout reveal message for block “i” was successfully processed.
- the block “i” received will be rejected if there is no match and the processing will stop at step 1112 .
- step 1104 If the matching is successful at step 1104 , then at step 1106 , the result of the contention resolution procedure is checked when timeout reveal message was processed.
- the received block “i” is ignored and processing stops at step 1112 . If the contention resolution outcome is to reject or ignore the block, then the received block “i” is ignored and processing stops at step 1112 . If the contention resolution outcome is to accept the block, the received block “i” is subjected to block validation in step 1108 . If the block validation is not successful, then block “i” is rejected and processing stops at step 1112 . If block validation is successful, then block “i” is accepted at step 1110 and either directly appended to the blockchain or an existing block is replaced with block “i” based on contention resolution outcome when timeout reveal message was processed.
- FIG. 12 illustrates a method 1200 implemented for contention resolution, in accordance with one embodiment of the present disclosure.
- the method 1200 illustrates the steps performed for the contention resolution.
- BH P BT P be the block hash and block timeout values respectively for the first contention block created by node P. Let this block be denoted as “i P ”. Further, let BH Q , BT Q be the block hash and block timeout values respectively for the second contention block created by node Q. Let this block be denoted as “i Q ”.
- step 1204 if the value of BT P is determined to be less than BT Q , then the first block “i P ” wins the contention at step 1206 since the absolute timeout value that was computed with peer coordination is less than the timeout value computed for the second block “i Q ”. Then the contention resolution is complete at step 1218 .
- Block appended to the blockchain, block “i” block “i P ”, if (BT P ⁇ BT Q )
- step 1208 if the value of BT Q is less than BT P , then the second block i Q wins the contention at step 1210 since the absolute timeout value that was computed with peer coordination is less than the timeout value computed for the first block i P .
- Block appended to the blockchain, block “i” block “i Q ”, if (BT Q ⁇ BT P )
- FIG. 13 illustrates an example scenario 1300 showing privileged nodes N 1 , N 2 , N 3 , N 4 , N . . . Nn and plurality of first messages ((N 1 - 2 , N 1 - 3 , N 1 - . . . N 1 - n ), (N 2 - 1 , N 2 - 3 , N 2 - . . . N 2 - n ), . . . (Nn- 1 , Nn- 2 , Nn- . . . Nn-(n ⁇ 1))), in accordance with one embodiment of the present disclosure.
- FIG. 13 illustrates an example scenario 1300 showing privileged nodes N 1 , N 2 , N 3 , N 4 , N . . . Nn and plurality of first messages ((N 1 - 2 , N 1 - 3 , N 1 - . . . N 1 - n ), (N 2 - 1 , N 2
- the privileged nodes are the set of nodes of the permissioned blockchain network taking part in consensus.
- the privileged nodes N 1 , N 2 , N 3 , N 4 , N . . . Nn participate in the consensus method for creating and appending new blocks to blockchain.
- each of the privileged nodes of the permissioned blockchain sends a plurality of random timeout message (first messages), individually to each of the other privileged nodes of the plurality of privileged nodes.
- the first message sent by the privileged node N 1 to all the other privileged nodes in the permissioned network is shown by N 1 - 2 , N 1 - 3 , N 1 - . . . N 1 - n .
- the first message sent by the privileged node N 2 to all the other privileged nodes in the permissioned network is shown by (N 2 - 1 , N 2 - 3 , N 2 - . . . N 2 - n ).
- the first message sent by the privileged node Nn to all the other privileged nodes in the permissioned network is shown by Nn- 1 , Nn- 2 , Nn- . . . Nn-(n ⁇ 1))).
- Each node is configured to send first message individually to each of the other privileged nodes of the plurality of privileged nodes of the permissioned blockchain network.
- FIG. 14 illustrates an example scenario 1400 showing timers T 1 , T 2 , T 3 , T 4 , T . . . , Tn for each of the privileged nodes N 1 , N 2 , N 3 , N 4 , N . . . , Nn and a timeout reveal message TORM broadcasted by the privileged node N 2 , whose timer T 2 times out before the timers T 1 , T 3 , T 4 , T . . . , Tn of the other privileged nodes, in accordance with one embodiment of the present disclosure.
- the timers T 1 , T 2 , T 3 , T 4 , T . . . , Tn are the block creation timers. Each timer is set to the computed first wait time WT 1 , WT 2 , WT 3 , WT 4 , WT . . . , WTn and initiated. The computation of first wait time is explained in detail above in FIG. 6 . For the purposes of description, it is assumed here that the timer T 2 , set to a first wait time of WT 2 , of the node N 2 has the smallest of first wait times among all wait times and hence times out before the other timers time out.
- the privileged node N 2 since the timer T 2 of the privileged node N 2 times out before the timers T 1 , T 3 , T 4 , T . . . , Tn of the other privileged nodes N 1 , N 3 , N 4 , N . . . , Nn, the privileged node N 2 creates the new block for appending to the permissioned blockchain.
- the below flow chart is explained considering the example scenarios as depicted in FIG. 13 and FIG. 14 .
- FIG. 15 is a flow chart illustrating a method 1500 for appending a new block to a blockchain in a permissioned network, in accordance with one embodiment of the present disclosure.
- FIG. 15 may be described from the perspective of a processor that is configured to execute computer-readable instructions to carry out the functionalities of the system 100 of FIG. 1 .
- the steps as described in FIG. 15 may be executed for reaching consensus for appending the new block to the blockchain such that all the nodes in the blockchain network have identical copies of any given block in the blockchain. Each step is described in further detail below.
- each of a designated plurality of privileged nodes (N 1 , N 2 , N 3 , N . . . Nn) of the permissioned blockchain sends a plurality of first messages ((N 1 - 2 , N 1 - 3 , N 1 - . . . N 1 - n ), (N 2 - 1 , N 2 - 3 , N 2 - . . . N 2 - n ), . . . (Nn- 1 , Nn- 2 , Nn- . . . Nn-(n ⁇ 1))), individually to each of the other privileged nodes of the plurality of privileged nodes.
- the contents of each of the first messages are calculated using a first predefined method.
- the first predefined method for creating each of the first messages comprises the steps of creating a first data packet, signing the first data packet digitally and encrypting the signed first data packet using a predetermined encryption method.
- the first data packet comprises a block number of a last accepted block, a hash of the last accepted block, a header with an identifier of the privileged node sending the first message and an identifier of the privileged node to which the first message is to be sent.
- the steps for calculating a pairs of values for each of the plurality of first messages include creating a 32-byte hash of each of the digital signatures; splitting the 32-byte hash into two equal parts of 16-bytes each; computing the EXOR value of the two parts split equally for obtaining a 16-byte number; splitting the 16-byte number into two equal parts of 8-bytes each; computing the EXOR value of the two parts split equally for obtaining a 8-byte number; computing a random time out value from a first set of 4-bytes; and computing a nonce value from a second set of 4-bytes.
- the pair of values comprising a time out value and a nonce from each of the first messages received. It has to be noted here that the split has to be in predefined order and not necessarily sequential. However the same predefined manner has to be followed in each of the nodes.
- each of the plurality of privileged nodes (N 1 , N 2 , N 3 , N . . . Nn) computing a first wait time (WT 1 , WT 2 , WT . . . WTn) based on the plurality of first messages received by each of the plurality of privileged nodes (N 1 , N 2 , N 3 , N . . . Nn), using a second predefined method.
- a timer (T 1 , T 2 , T . . . , Tn) which is set to the computed first wait time (WT 1 , WT 2 , WT . . . WTn) is initiated.
- the second predefined method of computing the first wait time comprises the steps of calculating a pair of values comprising a time out value and a nonce from each of the first messages received, arranging the time out values in ascending order of magnitude, calculating an index into the ordered list using all the nonce values calculated, and selecting the value of the time corresponding to the index value as the time out value for the timer.
- the privileged node (N 2 ) whose timer times out before the timers of the other privileged nodes, creates the new block for appending to the permissioned blockchain.
- a timeout reveal message (TORM) is created and broadcasted to all the other privileged nodes (N 1 , N 3 , . . . Nn) by the privileged node (N 2 ).
- the steps for creating the timeout reveal message (TORM) for broadcasting to all the other privileged nodes (N 1 , N 3 , . . . Nn) includes creating a second data packet containing a block number of the new block, a block hash of the new block, all the time out messages received by the node (N 2 ) creating the new block and signing the second data packet digitally.
- the step of creating the timeout reveal message (TORM) for broadcasting to all the other privileged nodes (N 1 , N 3 , . . . Nn) starts after the timer of the privileged node (N 2 ) times out and the new block is created.
- each of the privileged nodes (N 1 , N 3 , . . . Nn) receiving the timeout reveal message (TORM) computes a second wait time using the second predefined method.
- the second predefined method is explained a step 1504 .
- the first wait time (WT 1 , WT 2 , WT . . . WTn) is validated with the second wait time, by each of the other privileged nodes.
- the steps for validating the first wait time comprises the steps of comparing the second wait time and a time between the creating of the last block and receiving the timeout reveal message (TORM) and treating the first wait time as validated.
- TORM timeout reveal message
- the new block created is appended to its own copy of the block chain, provided the second wait time is substantially the same as the time waited for by the privileged node (N 2 ) that broadcast the timeout reveal message (TORM) after previous block was created.
- N 2 privileged node
- TORM timeout reveal message
- FIG. 16 is a timing diagram 1600 that shows the timing of the sequence of events involved in creating a new block for being appended to the blockchain and arriving at the consensus according to this disclosure.
- FIG. 17 is a is a sequence diagram 1700 that shows the sequence of events involved in creating a new block for being appended to the blockchain and arriving at the consensus according to this disclosure.
Abstract
Description
H S=SHA256_Hash(S)
HS is 32 bytes in length and is split into two halves of 16 bytes each. Let the first half be denoted by H1S and second half by H2S
H1S =H S[0] . . . H S[15]
H2S =H S[16] . . . H S[31]
Q S =H1S ⊕H2S
QS is 16 bytes in length and is split into two halves of 8 bytes each. Let Q1S and Q2S be the first half and second half of QS respectively.
Q1S =Q S[0] . . . Q S[7]
Q2S =Q S[8] . . . Q S[15]
R S =Q1S ⊕Q2S
RS is 8 bytes in length. The first half is used for computing the timeout value and the second half is used as nonce.
T=R S[0] . . . R S[3]
Nonce, N j =R S[4] . . . R S[7]
Let TMin be the minimum timeout value in the pre-fixed range.
Random timeout value, T j =T Min+(T mod(T R /g))
Here, Tj and Nj corresponds to the random timeout value and random nonce computed by node “n” from random timeout message received from a peer privileged node “j”. Tj and Nj are added to the set of 2-tuples by node “n”.
Or for small values of ‘p’ (<0.1),
S={(T 1 ,N 1),(T 2 ,N 2),(T 3 ,N 3) . . . (T k ,N k)}
N≡(N 0 ⊕N 1 ⊕N 2 ⊕ . . . ⊕N k)(mod k)
Index, I=|N|
Claims (14)
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IN201941050462 | 2019-12-06 | ||
IN201941050462 | 2019-12-06 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20210176041A1 US20210176041A1 (en) | 2021-06-10 |
US11362808B2 true US11362808B2 (en) | 2022-06-14 |
Family
ID=76210453
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/904,329 Active 2040-12-31 US11362808B2 (en) | 2019-12-06 | 2020-06-17 | Method and system for consensus in a permissioned blockchain |
Country Status (1)
Country | Link |
---|---|
US (1) | US11362808B2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2233535A1 (en) | 2009-03-23 | 2010-09-29 | Xerox Corporation | Low polarity nanoparticle metal pastes for printing application |
EP2236565A1 (en) | 2009-03-31 | 2010-10-06 | Xerox Corporation | Low polarity nano silver gels |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11227057B2 (en) * | 2018-11-08 | 2022-01-18 | International Business Machines Corporation | Membership access management of a database |
CN113630455B (en) * | 2021-08-02 | 2022-06-21 | 上海华能电子商务有限公司 | Raft consensus method applicable to Internet of things |
CN113596180B (en) * | 2021-09-17 | 2021-12-14 | 深圳时空云科技有限公司 | Distributed multi-end docking method and device |
CN114745135A (en) * | 2022-04-19 | 2022-07-12 | 西南石油大学 | Block chain system for energy transaction based on V-raft consensus algorithm |
CN115022022B (en) * | 2022-05-31 | 2023-07-18 | 南京邮电大学 | Improved method of Raft consensus mechanism based on node past behavior analysis |
CN116915505B (en) * | 2023-09-12 | 2023-11-21 | 南京理工大学 | Block chain consensus method and device based on improved PBFT algorithm |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170300627A1 (en) * | 2016-04-13 | 2017-10-19 | Accenture Global Solutions Limited | Distributed healthcare records management |
US20180349879A1 (en) * | 2017-05-31 | 2018-12-06 | Walmart Apollo, Llc | Systems and methods to enable robotic node participation in peer-to-peer commercial transactions |
US20190207751A1 (en) * | 2018-01-04 | 2019-07-04 | Bank Of America Corporation | Blockchain enterprise data management |
US20190251199A1 (en) * | 2018-02-14 | 2019-08-15 | Ivan Klianev | Transactions Across Blockchain Networks |
US20190340269A1 (en) * | 2018-05-02 | 2019-11-07 | Rockwell Automation Technologies, Inc. | Blockchain-enabled industrial devices |
US20200026785A1 (en) * | 2018-07-18 | 2020-01-23 | Bank Of America Corporation | Data Manifest as a Blockchain Service |
US20200118096A1 (en) * | 2019-05-31 | 2020-04-16 | Alibaba Group Holding Limited | System and method for providing privacy and security protection in blockchain-based private transactions |
US20200125269A1 (en) * | 2018-10-18 | 2020-04-23 | NEC Laboratories Europe GmbH | Secure and transparent pruning for blockchains |
US20200167770A1 (en) * | 2018-11-28 | 2020-05-28 | Bank Of America Corporation | Blockchain implementation across multiple organizations |
US20200211024A1 (en) * | 2018-12-29 | 2020-07-02 | Alibaba Group Holding Limited | Blockchain-based recordkeeping method and apparatus |
US11243943B2 (en) * | 2018-03-09 | 2022-02-08 | Nchain Licensing Ag | Methods and systems for controlling access to, and integrity of, resources on a blockchain |
-
2020
- 2020-06-17 US US16/904,329 patent/US11362808B2/en active Active
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170300627A1 (en) * | 2016-04-13 | 2017-10-19 | Accenture Global Solutions Limited | Distributed healthcare records management |
US20180349879A1 (en) * | 2017-05-31 | 2018-12-06 | Walmart Apollo, Llc | Systems and methods to enable robotic node participation in peer-to-peer commercial transactions |
US20190207751A1 (en) * | 2018-01-04 | 2019-07-04 | Bank Of America Corporation | Blockchain enterprise data management |
US20190251199A1 (en) * | 2018-02-14 | 2019-08-15 | Ivan Klianev | Transactions Across Blockchain Networks |
US11243943B2 (en) * | 2018-03-09 | 2022-02-08 | Nchain Licensing Ag | Methods and systems for controlling access to, and integrity of, resources on a blockchain |
US20190340269A1 (en) * | 2018-05-02 | 2019-11-07 | Rockwell Automation Technologies, Inc. | Blockchain-enabled industrial devices |
US20200026785A1 (en) * | 2018-07-18 | 2020-01-23 | Bank Of America Corporation | Data Manifest as a Blockchain Service |
US20200125269A1 (en) * | 2018-10-18 | 2020-04-23 | NEC Laboratories Europe GmbH | Secure and transparent pruning for blockchains |
US20200167770A1 (en) * | 2018-11-28 | 2020-05-28 | Bank Of America Corporation | Blockchain implementation across multiple organizations |
US20200211024A1 (en) * | 2018-12-29 | 2020-07-02 | Alibaba Group Holding Limited | Blockchain-based recordkeeping method and apparatus |
US20200118096A1 (en) * | 2019-05-31 | 2020-04-16 | Alibaba Group Holding Limited | System and method for providing privacy and security protection in blockchain-based private transactions |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2233535A1 (en) | 2009-03-23 | 2010-09-29 | Xerox Corporation | Low polarity nanoparticle metal pastes for printing application |
EP2236565A1 (en) | 2009-03-31 | 2010-10-06 | Xerox Corporation | Low polarity nano silver gels |
Also Published As
Publication number | Publication date |
---|---|
US20210176041A1 (en) | 2021-06-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11362808B2 (en) | Method and system for consensus in a permissioned blockchain | |
US11838407B2 (en) | Computer-implemented systems and methods for using a blockchain to perform an atomic swap | |
US10396995B2 (en) | Method of providing a hash value for a piece of data, electronic device and computer program | |
CN112583596B (en) | Complete cross-domain identity authentication method based on block chain technology | |
Blanchet | Symbolic and computational mechanized verification of the ARINC823 avionic protocols | |
US11849052B2 (en) | Certificate in blockchain network, storage medium, and computer device | |
US20220156735A1 (en) | Methods and devices for propagating blocks in a blockchain network | |
EP3659060B1 (en) | Consensus protocol for permissioned ledgers | |
CN115378604A (en) | Identity authentication method of edge computing terminal equipment based on credit value mechanism | |
CN113328997A (en) | Alliance chain cross-chain system and method | |
Charapko et al. | Bridging paxos and blockchain consensus | |
KR101253683B1 (en) | Digital Signing System and Method Using Chained Hash | |
US20230344658A1 (en) | Methods and devices for secure symbiotic mining | |
US20200153622A1 (en) | System and method for enforcement of correctness for key derivation | |
Civit et al. | As easy as ABC: Optimal (A) ccountable (B) yzantine (C) onsensus is easy! | |
US20230319103A1 (en) | Identifying denial-of-service attacks | |
US20210111900A1 (en) | Verification information attaching device, verification device, information management system, method, and program | |
US20240121109A1 (en) | Digital signatures | |
JP6911231B1 (en) | Reliability verification system for digital asset data packets | |
CN112039837B (en) | Electronic evidence preservation method based on block chain and secret sharing | |
CN111787034A (en) | Block generation method, synchronization method, device, block chain system and storage medium | |
CN115943609A (en) | Block propagation for poisoned transactions in block chain networks | |
CN110912687A (en) | Distributed identity authentication method | |
US20230171109A1 (en) | Method for authenticating distributed votes for a distributed system | |
Wu et al. | Redactable consortium blockchain based on verifiable distributed chameleon hash functions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SASKEN TECHNOLOGIES LTD, INDIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SUBRA GIRISH, BANAVATHI VENKATA;REEL/FRAME:052968/0294 Effective date: 20200518 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |