This application claims the benefit of, and priority to, U.S. Application

No. 15/163,007 filed on May 24, 2016. The entire disclosure of the above application is incorporated herein by reference.

FIELD

The present disclosure relates to the consensus of a permissioned blockchain, specifically the use of audit guarantees for efficient consensus of new blocks added to a permissioned blockchain and the use of bloom filters for recovery of desynchronized nodes.

BACKGROUND

Blockchains are decentralized, distributed databases that can be used to maintain a verified, and often publicly accessible, record of data. Recently, blockchains have seen increasing use via a mechanism for the storage and verification of transaction records for cryptographic currency transactions. Being a decentralized, distributed database, blockchains typically require a significant computational effort in order to have new blocks added to the chain verified. In many instances, this verification is performed via "proof of work," which is performed by nodes in the blockchain network and involves performing a very high number of computations. Over time, the processing power necessary in order to provide consensus in a blockchain via proof of work has grown to the point where it can be prohibitively expensive and time consuming.

However, for a decentralized database, consensus may be necessary to ensure that each distribution of the database is accurate and matches the other distributions. Unfortunately, many computing devices that may benefit from the use of a blockchain, acting as nodes therefore, may lack the processing power necessary to be able to participate via the performing of proof of work or other existing consensus mechanisms. In addition, existing consensus mechanisms often take a considerable amount of time in order for the consensus to be resolved. For instance, proof of work for Bitcoin, one of the most popular implementations of a blockchain, often takes upwards of ten minutes. In many instances, this length of time may be unacceptable for a blockchain implementation.

Thus, there is a need for a technical solution for a consensus mechanism for a blockchain that can be performed quickly, efficiently, and with a minimal amount of processing power as compared to existing blockchain

implementations and consensus mechanisms. A faster, more efficient consensus mechanism may enable a blockchain to be implemented more easily and distributed among computing devices with lower system specifications, while also ensuring consensus for new transactions and other records added to the blockchain more quickly.

SUMMARY

The present disclosure provides a description of systems and methods for adding blocks to a permissioned blockchain using an efficient consensus mechanism.

A method for adding a block to a permissioned blockchain using an efficient consensus mechanism includes: storing, in a memory of a processing server, a blockchain comprising a plurality of blocks including a recently added block, the recently added blocking including at least a block header and one or more transaction values; receiving, by a receiving device of the processing server, a plurality of transaction messages from one or more consensus nodes associated with the blockchain, wherein each transaction message includes at least a transaction value; generating, by a hashing module of the processing server, a Merkle root for the plurality of transaction messages using a transaction reference associated with the transaction value included in each of the plurality of transaction messages; generating, by the hashing module of the processing server, a previous hash value via application of a hashing algorithm to the block header included in the recently added block;

generating, by a generation module of the processing server, a proposed block header, wherein the proposed block header includes at least the previous hash value and the generated Merkle root; generating, by the hashing module of the processing server, a confirmation hash value via application of the hashing algorithm to the generated proposed block header; generating, by the generation module of the processing server, a proposal number, wherein the proposal number is a numeric value of a digital signature generated for the generated proposed block header; electronically

transmitting, by a transmitting device of the processing server, a prepare message to a plurality of auditing nodes associated with the blockchain, wherein the prepare message includes at least the generated confirmation hash value and generated proposal number; receiving, by the receiving device of the processing server, a response message from at least a majority of the plurality of auditing nodes, wherein each prepare response message includes at least the generated confirmation hash value and an accepted proposal number; identifying, by a data identification module of the processing server, an agreed proposal number based on the numeric value of the generated proposal number and a numeric value of the accepted proposal number included in each response message and a predetermined criteria; electronically transmitting, by the transmitting device of the processing server, an accept message to the plurality of auditing nodes, wherein the accept message includes at least the generated confirmation bash value and the identified agreed proposal number;

electronically transmitting, by the transmitting device of the processing server, a confirm message to a plurality of consensus nodes associated with the blockchain, wherein the confirm message includes at least the generated confirmation hash value and the identified agreed proposal number; and executing, by a querying module of the processing server, a query on the memory to add a new block to the blockchain, the new block including at least the transaction value included in each of the plurality of transaction messages a new block header including at least the previous hash value, the generated Merkle root, and the agreed proposal number.

A system for adding a block to a permissioned blockchain using an efficient consensus mechanism includes: a transmitting device of a processing server; a data identification module of the processing server; a querying module of the processing server; a memory of the processing server configured to store a blockchain comprising a plurality of blocks including a recently added block, the recently added blocking including at least a block header and one or more transaction values; a receiving device of the processing server configured to receive a plurality of transaction messages from one or more consensus nodes associated with the blockchain, wherein each transaction message includes at least a transaction value; a hashing module of the processing server configured to generate a Merkle root for the plurality of transaction messages using a transaction reference associated with the transaction value included in each of the plurality of transaction messages, and a previous hash value via application of a hashing algorithm to the block header

included in the recently added block; and a generation module of the processing server configured to generate a proposed block header, wherein the proposed block header includes at least the previous hash value and the generated Merkle root. The hashing module of the processing server is further configured to generate a confirmation hash value via application of the hashing algorithm to the generated proposed block header. The generation module of the processing server is further configured to generate a proposal number, wherein the proposal number is a numeric value of a digital signature generated for the generated proposed block header. The transmitting device of the processing server is configured to electronically transmit a prepare message to a plurality of auditing nodes associated with the blockchain, wherein the prepare message includes at least the generated confirmation hash value and generated proposal number. The receiving device of the processing server is further configured to receive a response message from at least a majority of the plurality of auditing nodes, wherein each prepare response message includes at least the generated confirmation hash value and an accepted proposal number. The data identification module of the processing server is configured to identify an agreed proposal number based on the numeric value of the generated proposal number and a numeric value of the accepted proposal number included in each response message and a predetermined criteria. The transmitting device of the processing server is further configured to electronically transmit: an accept message to the plurality of auditing nodes, wherein the accept message includes at least the generated confirmation hash value and the identified agreed proposal number; and a confirm message to a plurality of consensus nodes associated with the blockchain, wherein the confirm message includes at least the generated confirmation hash value and the identified agreed proposal number. The querying module of the processing server is further configured to execute a query on the memory to add a new block to the blockchain, the new block including at least the transaction value included in each of the plurality of transaction messages a new block header including at least the previous hash value, the generated Merkle root, and the agreed proposal number.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The scope of the present disclosure is best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings. Included in the drawings are the following figures:

FIG. 1 is a block diagram illustrating a high level system architecture for the efficient consensus and recovery of desynchronized nodes in a permissioned blockchain network in accordance with exemplary embodiments.

FIG. 2 is a block diagram illustrating the auditing node of FIG..1 for the efficient consensus and recovery of desynchronized nodes in a permissioned blockchain network in accordance with exemplary embodiments.

FIG. 3 is a flow diagram illustrating a process for identifying a consensus proposal in a consensus node of a permissioned blockchain network in accordance with exemplary embodiments.

FIGS. 4 A and 4B are a flow diagram illustrating a process for the recovery of a desynchronized consensus node in a permissioned blockchain network via the use of a bloom filter in the system of FIG. 1 in accordance with exemplary embodiments.

FIG. 5 is a flow diagram illustrating a process for resynchronization in a desynchronized consensus node in a permissioned blockchain network in accordance with exemplary embodiments.

FIG.6 is 'a flow chart illustrating a process for the performing of a consensus audit in auditing nodes in a permissioned blockchain network for efficient consensus of a new block in accordance with exemplary embodiments.

FIG. 7 is a flow chart illustrating a process for the verification and adding of a new block to a permissioned blockchain as a result of an efficient consensus mechanism in accordance with exemplary embodiments.

FIG. 8 is a flow chart illustrating an exemplary method for adding a block to a permissioned blockchain using an efficient consensus mechanism in accordance with exemplary embodiments.

FIGS. 9 and 10 are flow charts illustrating exemplary methods for recovery of missing or extra data using a bloom filter in accordance with exemplary embodiments.

FIG. 11 is a block diagram illustrating a computer system architecture in accordance with exemplary embodiments.

Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments are intended for illustration purposes only and are, therefore, not intended to necessarily limit the scope of the disclosure.

DETAILED DESCRIPTION

Glossary of Terms

Blockchain - A public ledger of all transactions of a blockchain-based currency. One or more computing devices may comprise a blockchain network, which may be configured to process and record transactions as part of a block in the blockchain. Once a block is completed, the block is added to the blockchain and the transaction record thereby updated. In many instances, the blockchain may be a ledger of transactions in chronological order, or may be presented in any other order that may be suitable for use by the blockchain network. In some configurations, transactions recorded in the blockchain may include a destination address and a currency amount, such that the blockchain records how much currency is attributable to a specific address. In some instances, the transactions are financial and others not financial, or might include additional or different information, such as a source address, timestamp, etc. In some embodiments, a blockchain may also or

alternatively include nearly any type of data as a form of transaction that is or needs to be placed in a permissionless, distributed database that maintains a continuously growing list of data records hardened against tampering and revision, even by its operators, and may be confirmed and validated by the blockchain network through proof of work and/or any other suitable verification techniques associated therewith. In some cases, data regarding a given transaction may further include additional data that is not directly part of the transaction appended to transaction data. In some instances, the inclusion of such data in a blockchain may constitute a transaction. In such instances, a blockchain may not be directly associated with a specific digital, virtual, fiat, or other type of currency. In some cases, participation in a blockchain (e.g., as a node submitting and/or confirming transactions) may be permissionless (e.g., not moderated or restricted). In other cases, a blockchain may be a

permissioned blockchain where only authorized computing devices may operate as nodes, where a level of participation may be based on permissions associated therewith.

System for Efficient Consensus and Recovery in a Permissioned Blockchain Network

FIG. 1 illustrates a system 100 for the use of an efficient consensus mechanism for consensus of new blocks added to a permissioned blockchain network and the recovery of desynchronized nodes included therein.

The system 100 may include an auditing node 102. The auditing node 102 may be a part of a permissioned blockchain network. The permissioned blockchain network may be a network of a plurality of nodes associated with a permissioned blockchain. The permissioned blockchain may be a blockchain where participation therein for the contribution of and consensus of new blocks, and transactions and other data included therein, to be added to the blockchain may be restricted to authorized (e.g., "permissioned") nodes. In the system 100, the permissioned blockchain network may be comprised of a plurality of auditing nodes 104 and consensus nodes 106. As discussed in more detail below, consensus nodes 106 may be configured to receive and contribute transactions for inclusion in the permissioned blockchain, and auditing nodes 104 may be configured to perform the functions of a consensus node as well as being configured to perform a consensus audit, for auditing of new blocks to be added to the permissioned blockchain. In some embodiments, a permissioned blockchain may include additional types of nodes, such as member or application nodes that contribute transactions but do not participate in consensus, and other nodes that may be suitable depending on the functions and implementation of the permissioned blockchain.

The auditing node 102 may be a processing server or other specially configured computing device and/or system configured to perform the functions of both a consensus node 106 and an auditing node 104. The auditing node 102 may be connected via a suitable communication network and methods to a plurality of consensus nodes 106, illustrated in FIG. 1 as consensus nodes 106a, 106b, 106c, and 106d. Each of the consensus nodes 106 in the permissioned blockchain network may be connected to a plurality of other consensus nodes 106 in any suitable network topology. For example, consensus nodes 106 may be connected using a mesh topology. In some instances, some consensus nodes 106 may only be connected to other consensus nodes, and may not be connected to an auditing node 104. Each of the other auditing nodes 104 in the blockchain network may also be connected to a plurality of consensus nodes 106, in addition to being connected to each of the other auditing nodes 104. In some instances, a consensus node 106 may be connected to only a single auditing node, such as the auditing node 102 or one of the other auditing nodes 104.

The auditing node 102 may, in performing the functions of an auditing node 104, be connected to a plurality of auditing nodes 104 using a suitable communication network and methods. In an exemplary embodiment, the number of auditing nodes 104 in the permissioned blockchain network may be limited to a maximum number, such as for a faster, more efficient consensus using the methods discussed herein. For example, a permissioned blockchain network may limit the number of auditing nodes 104 to seven, even in instances where the number of consensus nodes may be in the thousands, tens of thousands, hundreds of thousands, or even greater. In some cases, the number of auditing nodes 104 may be an odd number, such as for the determination of a majority thereof during the consensus audit, as discussed in more detail below. In an exemplary embodiment, each of the auditing nodes 104 may be interconnected, such as illustrated in FIG. 1 where each of the auditing nodes 104 are connected to each of the other auditing nodes. In some instances, the auditing nodes 104 may be geographically distributed in the permissioned blockchain network, such as to reduce the likelihood of a significant network disconnect or partition.

In the system 100, the auditing node 102, and other nodes in the permissioned blockchain network configured to perform the functions of a consensus node 106 (e.g., each of the consensus nodes 106 and auditing nodes 104), may receive transaction messages from application nodes or other nodes in the permissioned blockchain network configured to contribute data for transactions to be added to the permissioned blockchain. Transaction messages may be electronically transmitted to the auditing node 102 via a suitable communication network, and may include at least a transaction value. The transaction value may be a transaction record or other value to be added to the permissioned blockchain. For instance, the transaction value may be a transaction record that includes destination and source addresses and digital signatures associated therewith and a transaction amount for an amount of cryptographic currency transferred from the destination address to the source address or addresses. In another instance, the transaction value may be an alphanumeric or other suitable type of value that represents a transaction or other data, such as in an opaque, permissioned blockchain. Additional data regarding opaque blockchains may be found in U.S. Patent Application No. 14/950,117, entitled "Method and System for Gross Settlement by the Use of an Opaque Blockchain," filed on November 24, 2015, by Steven C. Davis, which is herein incorporated by reference in its entirety.

In some embodiments, transaction messages may also include a slot identifier. The slot identifier may be an identification value representative of a slot to which the corresponding transaction value belongs. The slot may be a demarcation or other categorical organization used for the organization of transactions to be added to the permissioned blockchain. In an exemplary embodiment, a slot may be associated with a time or range of times to which the associated transactions correspond. For example, a slot may be associated with a second in time, where each transaction associated with the slot's corresponding slot identifier may be a transaction conducted at that second in time. In such an example, the slot identifier may be a representation of that second in time, such as a timestamp in seconds since the start of the UNIX epoch or other suitable date and time representation that indicates that second. For instance, the slot identifier for all transactions conducted at the first second of 2016 may be 1451606400.

When the auditing node 102 receives a transaction message, the auditing node 102 may determine if the transaction value included in that transaction message is already stored in a local database of unconfirmed transaction values to be added to the permissioned blockchain. In instances where the transaction message includes a slot identifier, the determination may be based on inclusion of that transaction value in a storage of transaction values for the included slot identifier. If that transaction value has not already been received, then the auditing node 102 may store the transaction value with other transaction values for that slot identifier. The auditing node 102 may then rebroadcast that transaction message to each consensus node 106 connected thereto. The connected consensus nodes 106 may receive the transaction message and also perform the determination, storage, and rebroadcast as necessary. If the transaction value has already been received by the auditing node 102, then the auditing node 102 may ignore the transaction message and may not rebroadcast the transaction message. The auditing node 102 may repeat the process for each transaction message received from application nodes, as well as transaction messages rebroadcast from consensus nodes 106 connected thereto.

As a result, the auditing node 102 and each of the consensus nodes 106 may quickly propagate all transaction messages throughout the permissioned blockchain network. Due to rebroadcasting only occurring in instances where a

transaction message has not been previously received (e.g., due to lack of the transaction value in the stored list of unconfirmed transactions), traffic in the permissioned blockchain network may be kept to a minimum with the number of redundant transaction messages received minimized.

In some embodiments, the auditing node 102 may be configured to generate reference values for each transaction value received and added to the list of unconfirmed transactions. Reference values may be a hash value or other representation of the transaction value as a single value. In instances where the transaction value may already be a reference value, such as in an opaque blockchain, the transaction value itself may be used as the reference value, hi other instances, such as when the transaction value is a transaction record that includes a number of data values, the transaction record may be hashed by the auditing node 102 via one or more predetermined hashing algorithms to obtain the corresponding transaction reference value. In such embodiments, the list of unconfirmed transactions may be a list of transaction reference values. In such an instance, the auditing node 102 may generate the reference value for each received transaction value prior to the determination if the transaction value has already been received.

The auditing node 102, and other nodes performing the functions of consensus nodes 106, may be configured to keep a timestamp of the arrival of transaction messages. In such instances, the auditing node 102 may update the timestamp each time a new transaction message is received, where the timestamp therefore indicates the time of arrival of the latest transaction message. In some instances, such as when each slot identifier represents a single second, the timestamp used by the auditing node 102 to mark the latest arrival of a transaction message may use milliseconds, nanoseconds, or other representation smaller than the slot identifier.

The auditing node 102 and other consensus nodes 106 may continue to receive transaction messages and then perform a consensus proposal. In some embodiments, the auditing node 102 may begin the consensus proposal process after a predetermined period of time since the arrival of the last transaction message (e.g., as indicated by the timestamp therefor), referred to herein as a "consensus delay time." In some cases, the consensus delay time may be considered by the auditing node 102 as the time between the timestamp marking the arrival of the latest transaction message and a time when the auditing node 102 was open to receive transaction messages for that slot identifier, with an additional buffer interval. In some cases, the consensus delay time may be different for each consensus node 106, such as based on the location of the consensus node 106 in the permissioned blockchain network and other considerations. In some embodiments, the consensus delay time may be recalculated based on performance of the permissioned blockchain network. For instance, the consensus delay time may be recalculated at a periodic interval (e.g., hourly, daily, etc.).

Consensus proposal may be a process in which the auditing node 102 and other consensus nodes 106 propose a consensus for the unconfirmed transactions that are to be added to the permissioned blockchain. In instances where a slot identifier is used, the consensus proposal may be with respect to a specific slot identifier. As part of the consensus proposal, the auditing node 102 may generate a Merkle root for the unconfirmed transactions. The Merkle root may be the value of the root node in a Merkle tree generated for the unconfirmed transactions that have been stored in the auditing node 102 (e.g., associated with the slot identifier, if applicable) from transaction messages. In instances where a transaction reference is generated for transaction values, the reference values may be used in the generation of the Merkle tree and subsequent identification of the Merkle root. The auditing node 102 may use one or more predetermined hashing algorithms to generate the Merkle root, by application thereof to the transaction references and subsequent hash values.

In some embodiments, the auditing node 102 and each consensus node

106 may be configured to order the transaction reference values prior to generation of the Merkle root, such that each consensus node 106 generates the Merkle root with the transaction references in the same order. In such embodiments, the transaction references may be ordered in a natural order based on the type of reference values. For instance, if the reference values are integers or alphanumeric values, they may be ordered in a natural ascending or descending order. The ordering of the transaction references, as well as the use of predetermined hashing algorithms, may ensure that the auditing node 102 and each consensus node 106 generates the same Merkle root if the respective node has received all of the transaction values for that slot identifier.

In order to determine if such a consensus has been reached (e.g., the auditing node 102 has generated the same Merkle root, and thus received the same transaction values, as the consensus nodes 106 connected thereto), the auditing node 102 may generate a proposal message. The proposal message may include at least the generated Merkle root, and may also include the slot identifier for the associated slot, if applicable. The auditing node 102 may electronically transmit the proposal message to each of the connected consensus nodes 106. Each of the connected consensus nodes 106 may also generate a proposal message, which may be transmitted therefrom to each of the other nodes connected thereto. As a result, the auditing node 102 may receive a proposal message from each of the connected consensus nodes 106. The auditing node 102 may store a list of each of the Merkle roots received from the neighboring (e.g., connected) consensus nodes 106.

The auditing node 102 may be configured to determine if there is a consensus among the auditing node 102 and its neighboring consensus nodes 106 via a comparison of the Merkle roots. If the Merkle roots received from the neighboring consensus nodes 106 match the Merkle root generated by die auditing node 102, then the auditing node 102 may consider itself to be synchronized with the rest of the permissioned blockchain network. If the Merkle root generated by the auditing node 102 is different from the Merkle roots received from the neighboring consensus nodes 106, then the auditing node 102 may be desynchronized, which may indicate that the auditing node 102 failed to receive one or more transaction values or may have included extraneous transaction references in the list of unconfirmed transactions. In instances where the auditing node 102 is desynchronized, the auditing node 102 may perform recovery processes, discussed in more detail below. If the Merkle root generated by the auditing node 102 matches a majority of the Merkle roots received from the neighboring consensus nodes 106, but one or more of the received Merkle roots are different, it may indicate that the consensus node 106 or nodes that supplied the different Merkle roots are out of sync, which may prompt their performing of recovery processes.

Once consensus proposals have been exchanged among the consensus nodes 106, a consensus audit may be performed. The consensus audit may be performed by the auditing node 102 and each of the auditing nodes 104 in the permissioned blockchain network. In an exemplary embodiment, the consensus audit may be performed using Paxos protocols adapted for usage in the system 100 for the consensus of the unconfirmed transactions by the auditing nodes 104 for addition to the permissioned blockchain. The consensus audit may be performed using digital signatures generated by the auditing node 102 and each of the auditing nodes 104, which may operate as the proposal number in the Paxos protocol, as discussed below.

To perform the consensus audit, the auditing node 102 may generate a temporary block header for the new block to be added to the permissioned blockchain that incorporates the unconfirmed transactions. The temporary block header may include at least the Merkle root generated for the unconfirmed transactions and a hash value of the block header of the prior block most recently added to the permissioned blockchain. The hash value of the block header of the prior block may be generated by the auditing node 102 using one or more predetermined hashing algorithms that may be the same used by each of the auditing nodes 104 in generating the hash value. ID some embodiments, the temporary block header may also include additional data that may be included in headers of blocks added to the permissioned blockchain, such as a slot identifier or other data discussed in more detail below.

After generation of the temporary block header, the auditing node 102 may hash the temporary block header using the same one or more predetermined hashing algorithms used in the generation of the prior block header's hash value to generate a hash value for the temporary block header, referred to herein as a "block hash." The block hash may then be included in a prepare message generated by the auditing node 102. The prepare message may include the block hash, slot identifier, if applicable, and may also include a proposal number generated by the auditing node 102.

The proposal number may be a digital signature generated by the auditing node 102. In some instances, the auditing node 102 may use a collision-resistant algorithm for generation of the digital signature such that there is a higher likelihood of uniqueness of the proposal numbers generated by the auditing node 102 and each of the auditing nodes 104. For example, the auditing node 102 may use the elliptic curve digital signature algorithm (ECDSA) for generation of the digital signature. In such an example, the auditing node 102 may use a public key associated therewith for generation of the digital signature. In such embodiments, the public key may also be included in the prepare message. In some such embodiments, the public key may also be included in the temporary block header prior to generation of the block hash. In some embodiments, the auditing node 102 may also generate a random or pseudo-random nonce to be included in the prepare message to act as a

cryptographic salt, which may also be included in the temporary block header prior to generation of the block hash.

Once the prepare message has been generated, the auditing node 102 may electronically transmit the prepare message to each of the auditing nodes 104 connected thereto. The auditing node 102 may similarly receive a prepare message from each of the auditing nodes 104 generated thereby. Each of the received prepare messages may include a different digital signature as a proposal number, generated via the respective associated public keys. Upon receipt of the prepare messages, the auditing node 102 may identify the highest (e.g., with respect to a natural ordering of the digital signatures) proposal number. It will be apparent to persons having skill in the relevant art that the use of the highest proposal number for consensus, as discussed herein, is merely illustrative, and that any other suitable criteria may be used for determining consensus of the proposal number, such as the lowest proposal number, the proposal number closest to a predetermined value, etc.

Once the auditing node 102 has identified the highest proposal number, the auditing node 102 may generate a prepare response message to send to the originator of me prepare message that included the highest proposal number. In instances where the highest proposal number was generated by the auditing node 102, the auditing node 102 may not generate a prepare response message. The prepare response message may include the digital signature that was identified as being the highest proposal number and, if applicable, the slot identifier associated with the slot for which consensus is being performed. In instances where the auditing node 102 has generated (e.g., and distributed) a higher proposal number than a neighboring auditing node 104, the auditing node 102 may receive a prepare response message from the neighboring auditing node 104, indicating that the digital signature generated by the auditing node 102 was higher.

When the auditing node 102 or other auditing node 104 receives a prepare response message from a majority of the auditing nodes 104, that node may enter into a consensus accept phase. In the accept phase, the auditing node 102 (e.g., or other node having received the majority prepare response messages) may generate an accept message. The accept message may include the same data included in the prepare message generated by that node, which would thus include the digital signature identified as being the highest proposal number. The accept message may then be electronically transmitted to each of the auditing nodes 104 that had provided a prepare response message to that node.

claims
identifying, by a data identification module of the processing server, an agreed proposal number based on the numeric value of the generated proposal number and a numeric value of the accepted proposal number included in each response message and a predetermined criteria;

electronically transmitting, by the transmitting device of the processing server, an accept message to the plurality of auditing nodes, wherein the accept message includes at least the generated confirmation hash value and the identified agreed proposal number;

electronically transmitting, by the transmitting device of the processing server, a confirm message to a plurality of consensus nodes associated with the blockchain, wherein the confirm message includes at least the generated confirmation hash value and the identified agreed proposal number; and

executing, by a querying module of the processing server, a query on the memory to add a new block to the blockchain, the new block including at least the transaction value included in each of the plurality of transaction messages a new block header including at least the previous hash value, the generated Merkle root, and the agreed proposal number.

2. The method of claim 1, wherein

each of the plurality of transaction messages further includes a specific slot identifier,

the proposed block header, prepare message, response message, accept message, confirm message, and new block header each include the specific slot identifier, and

the block header included in the recently added block includes a different slot identifier.

3. The method of claim 1, wherein the transaction reference associated with the transaction value included in each of the plurality of transaction messages is the transaction value.

4. The method of claim 1, further comprising:

generating, by the hashing module of the processing server, the transaction reference associated with the transaction value included in each of the plurality of transaction messages by hashing the respective transaction value using a

predetermined hashing algorithm.

5. The method of claim 1, further comprising:

storing, in the memory of the processing server, a consensus delay time, wherein

each of the plurality of transaction messages further includes a common identification value associated with a time, and

the Merkle root is generated after expiration of the consensus delay time after the time associated with the common identification value.

6. The method of claim 1, further comprising:

sorting, by the querying module of the processing server, the transaction reference associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering prior to generating the Merkle root.

7. The method of claim 1, further comprising:

electronically transmitting, by the transmitting device of the processing server, a proposal message to the plurality of consensus nodes, wherein the proposal message includes at least the generated Merkle root.

8. The method of claim 1, further comprising:

receiving, by the receiving device of the processing server, a proposal message from each of the plurality of consensus nodes, wherein the proposal message includes at least a proposed Merkle root; and

verifying, by a verification module of the processing server, that the generated Merkle root is equivalent to at least a majority of the proposed Merkle roots included in the received proposal messages.

9. The method of claim 1, wherein

the proposal number is further generated using a nonce in combination with the digital signature,

the prepare message further includes the nonce,

each response message further includes an associated nonce, and

the accept message, confirm message, and new block header further include the nonce associated with the agreed proposal number.

10. The method of claim 1, further comprising:

storing, in the memory, a public key associated with the processing server, wherein

the digital signature is generated for the proposed block header using the public key,

the prepare message further includes the public key,

each response message further includes an associated public key used in generation of the associated accepted proposal number, and

the accept message, confirm message, and new block header further include the public key associated with the agreed proposal number.

11. The method of claim 1, further comprising:

sorting, by the querying module of the processing server, the generated proposal number and the accepted proposal number included in each response message based on the respective numeric value, wherein

the agreed proposal number is identified based on the sorting and a predetermined criteria.

12. The method of claim 11, wherein the predetermined criteria is selecting the highest numeric value.

13. A system for adding a block to a permissioned blockchain using an efficient consensus mechanism, comprising:

a transmitting device of a processing server;

a data identification module of the processing server;

a querying module of the processing server;

a memory of the processing server configured to store a blockchain comprising a plurality of blocks including a recently added block, the recently added blocking including at least a block header and one or more transaction values;

a receiving device of the processing server configured to receive a plurality of transaction messages from one or more consensus nodes associated with the blockchain, wherein each transaction message includes at least a transaction value; a hashing module of the processing server configured to generate

a Merkle root for the plurality of transaction messages using a transaction reference associated with the transaction value included in each of the plurality of transaction messages, and

a previous hash value via application of a hashing algorithm to the block header included in the recently added block; and

a generation module of the processing server configured to generate a proposed block header, wherein the proposed block header includes at least the previous hash value and the generated Merkle root, wherein

the hashing module of the processing server is further configured to generate a confirmation hash value via application of the hashing algorithm to the generated proposed block header,

the generation module of the processing server is further configured to generate a proposal number, wherein the proposal number is a numeric value of a digital signature generated for the generated proposed block header,

the transmitting device of the processing server is configured to electronically transmit a prepare message to a plurality of auditing nodes associated with the blockchain, wherein the prepare message includes at least the generated confirmation hash value and generated proposal number,

the receiving device of the processing server is further configured to receive a response message from at least a majority of the plurality of auditing nodes, wherein each prepare response message includes at least the generated confirmation hash value and an accepted proposal number,

the data identification module of the processing server is configured to identify an agreed proposal number based on the numeric value of the generated proposal number and a numeric value of the accepted proposal number included in each response message and a predetermined criteria,

the transmitting device of the processing server is further configured to electronically transmit

an accept message to the plurality of auditing nodes, wherein the accept message includes at least the generated confirmation hash value and the identified agreed proposal number, and

a confirm message to a plurality of consensus nodes associated with the blockchain, wherein the confirm message includes at least the generated confirmation hash value and the identified agreed proposal number, and

the querying module of the processing server is further configured to execute a query on the memory to add a new block to the blockchain, the new block including at least the transaction value included in each of the plurality of transaction messages a new block header including at least the previous hash value, the generated Merkle root, and the agreed proposal number.

14. The system of claim 13, wherein

each of the plurality of transaction messages further includes a specific slot identifier,

the proposed block header, prepare message, response message, accept . message, confirm message, and new block header each include the specific slot identifier, and

the block header included in the recently added block includes a different slot identifier.

15. The system of claim 13, wherein the transaction reference associated with the transaction value included in each of the plurality of transaction messages is the transaction value.

16. The system of claim 13, wherein the hashing module of the processing server is further configured to generate the transaction reference associated with the transaction value included in each of the plurality of transaction messages by hashing the respective transaction value using a predetermined hashing algorithm.

17. The system of claim 13, wherein

the memory of the processing server is further configured to store a consensus delay time,

each of the plurality of transaction messages further includes a common identification value associated with a time, and

the Merkle root is generated after expiration of the consensus delay time after the time associated with the common identification value.

18. The system of claim 13, wherein the querying module of the processing server is further configured to sort the transaction reference associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering prior to generating the Merkle root

19. The system of claim 13, wherein the transmitting device of the processing server is further configured to electronically transmit a proposal message to the plurality of consensus nodes, wherein the proposal message includes at least the generated Merkle root.

20. The system of claim 13, further comprising:

a verification module of the processing server, wherein

the receiving device of the processing server is farther configured to receive a proposal message from each of the plurality of consensus nodes, wherein the proposal message includes at least a proposed Merkle root, and

the verification module of the processing server is configured to that the generated Merkle root is equivalent to at least a majority of the proposed Merkle roots included in the received proposal messages.

21. The system of claim 13, wherein

the proposal number is further generated using a nonce in combination with the digital signature,

the prepare message further includes the nonce,

each response message further includes an associated nonce, and

the accept message, confirm message, and new block header further include the nonce associated with the agreed proposal number.

22. The system of claim 13, wherein

the memory is further configured to store a public key associated with the processing server,

the digital signature is generated for the proposed block header using the public key,

the prepare message further includes the public key,

each response message further includes an associated public key used in generation of the associated accepted proposal number, and

the accept message, confirm message, and new block header further include the public key associated with the agreed proposal number.

23. The system of claim 13, wherein

the querying module of the processing server is further configured to sort the generated proposal number and the accepted proposal number included in each response message based on the respective numeric value, and

the agreed proposal number is identified based on the sorting and a

predetermined criteria.

24. The system of claim 23, wherein the predetermined criteria is selecting the highest numeric value.

the receiving device of the processing server is further configured to receive a proposal message from each of the plurality of consensus nodes, wherein the proposal message includes at least a proposed Merk!e root, and

the verification, module of the processing server is configured to that the generated Merkie root is equivalent to at least a majority of the proposed Merkle roots included in the received proposal messages,

21 , The system of claim 1.3, wherein

the proposal number is further generated using a nonce in combination with the digital signature,
the prepare message further Includes the nonce,
each response message further includes an associated nonce, and
the accept message, confirm message, and new b!ock header further Include the nonce associated with the agreed proposal number.
22 , The system of claim 13, wherein
the memory is further configured to store a public key associated with the processing server,
the digital signature is generated for the proposed block header using the public key,
the prepare message further includes the public key,
each response message further includes an associated public key used in generation of the associated accepted proposal number, and
the accept message, confirm message, and new block header .further include the public key associated with the agreed proposal number.
23. The system of claim 13, wherein
the querying module of the processing server is further configured to sort the generated proposal number and the accepted proposal number included in each response message based on the respective numeric value, and
the agreed proposal number is identified based on the sorting and a predetermined criteria,
24, The system of claim 23, wherein the predetermined criteria is selecting the highest numeric value.