Method and system for desynchronization recovery of permissioned blockchains

Abstract

A method for recovering lost or additional data using a Bloom filter, comprising: storing a plurality of transaction messages, wherein each transaction message includes a transaction value; generating a Bloom filter for the transaction messages, wherein the Bloom filter is generated using a plurality of hash cycles and the size of the Bloom filter is at least twice the number of transaction messages; generating a recovery message including the number of the plurality of transaction messages, the number of hash cycles, the size, and the generated Bloom filter; sending the recovery message to a consensus node; receiving a response message from the consensus node, wherein the response message includes at least one additional transaction message; and inserting the at least one additional transaction message into the plurality of transaction messages.

Description

[0001] This application is a divisional application of the invention patent application with application number 201780032307.1 filed on April 19, 2017.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of and priority to U.S. Application No. 15 / 163,077, filed May 24, 2016. The entire disclosure of the above application is incorporated herein by reference. Technical Field

[0004] The present disclosure relates to consensus in permissioned blockchains, and in particular to using auditing to ensure valid consensus of new blocks added to permissioned blockchains and using Bloom filters to recover desynchronized nodes. Background Art

[0005] Blockchain is a decentralized, distributed database that can be used to maintain a verified, generally publicly accessible record of data. Recently, blockchain has seen increasing use as a mechanism for storing and verifying transaction records for cryptocurrency transactions. As a decentralized, distributed database, blockchains typically require significant computational effort to add new blocks to the verified chain. In many cases, this verification is performed through "proof of work," which is performed by nodes in the blockchain network and involves performing a very large number of computations. Over time, the processing power required to provide consensus in blockchains through proof of work has grown to the point where it can be prohibitively expensive and time-consuming.

[0006] However, for decentralized databases, consensus may be required to ensure that each distribution of the database is accurate and matches the other distributions. Unfortunately, many computing devices that could benefit from using a blockchain to act as nodes may lack the processing power required to participate by executing proof-of-work or other existing consensus mechanisms. Furthermore, existing consensus mechanisms often require a considerable amount of time (e.g., more than ten minutes) to reach consensus. In many cases, this time period may be unacceptable for blockchain implementations.

[0007] Therefore, there is a need for a technical solution for a consensus mechanism for blockchain that can be executed quickly, efficiently, and with a minimal amount of processing power compared to existing blockchain implementations and consensus mechanisms. A faster, more efficient consensus mechanism can make blockchains easier to implement and distribute across computing devices with lower system specifications, while also ensuring faster consensus on new transactions and other records added to the blockchain. Summary of the Invention

[0008] This disclosure provides a description of systems and methods for recovering lost or additional data using Bloom filters.

[0009] A method for recovering lost or additional data using a Bloom filter, comprising: storing a plurality of transaction messages in a transaction database of a processing server, wherein each transaction message comprises a structured data set associated with a blockchain transaction and including at least a transaction value; generating, by a generation module of the processing server, a Bloom filter for the plurality of transaction messages, wherein the Bloom filter is generated using a predetermined number of hash rounds and has a size that is at least twice the count of the plurality of transaction messages stored in the transaction database; generating, by the generation module of the processing server, a recovery message, wherein the recovery message comprises at least the count of the plurality of transaction messages, the predetermined number of hash rounds, the size, and the generated Bloom filter; electronically sending, by a sending device of the processing server, the generated recovery message to at least one consensus node; receiving, by a receiving device of the processing server, a response message from one or more of the at least one consensus node, wherein the response message comprises at least one additional transaction message; and executing, by a query module of the processing server, a query on the transaction database to insert the at least one additional transaction message.

[0010] Another method for recovering lost or additional data using a Bloom filter comprises: storing a plurality of transaction messages in a transaction database of a processing server, wherein each transaction message comprises a structured data set related to a blockchain transaction and including at least a transaction value; generating, by a generation module of the processing server, a Bloom filter for the plurality of transaction messages, wherein the Bloom filter is generated using a predetermined number of hash cycles and a size of the Bloom filter is at least twice the count of the plurality of transaction messages stored in the transaction database; generating, by the generation module of the processing server, a recovery message, wherein the recovery message comprises at least the count of the plurality of transaction messages, the predetermined number of hash cycles, the size, and the generated Bloom filter; and transmitting, by a sending device of the processing server, electronically sending the generated recovery message to at least one consensus node; receiving, by a receiving device of the processing server, a response message from one or more of the at least one consensus node, wherein the response message includes at least a second Bloom filter, an indicated number of hash cycles, an indicated filter size, and an expected number of transaction messages; identifying, by a data identification module of the processing server, at least one transaction message of the plurality of transaction messages that is not included in the second Bloom filter based on the included transaction value, the indicated number of hash cycles, the indicated filter size, the expected number of transaction messages, and the second Bloom filter; and executing, by a query module of the processing server, a query on the transaction database to delete the at least one identified transaction message.

[0011] A system for recovering lost or additional data using a Bloom filter, comprising: a transaction database of a processing server configured to store a plurality of transaction messages, wherein each transaction message comprises a structured data set associated with a blockchain transaction and including at least a transaction value; a generation module of the processing server configured to generate a Bloom filter for the plurality of transaction messages, wherein the Bloom filter is generated using a predetermined number of hash cycles and has a size that is at least twice the count of the plurality of transaction messages stored in the transaction database; and generating a recovery message, wherein the recovery message comprises at least the count of the plurality of transaction messages, the predetermined number of hash cycles, the size, and the generated Bloom filter; a sending device of the processing server configured to electronically send the generated recovery message to at least one consensus node; a receiving device of the processing server configured to receive a response message from one or more of the at least one consensus node, wherein the response message comprises at least one additional transaction message; and a query module of the processing server configured to perform a query on the transaction database to insert the at least one additional transaction message.

[0012] Another system for recovering lost or additional data using a Bloom filter comprises: a transaction database of a processing server configured to store a plurality of transaction messages, wherein each transaction message comprises a structured data set associated with a blockchain transaction and including at least a transaction value; a generation module of the processing server configured to generate a Bloom filter for the plurality of transaction messages, wherein the Bloom filter is generated using a predetermined number of hash cycles and a size of the Bloom filter is at least twice a count of the plurality of transaction messages stored in the transaction database; and generating a recovery message, wherein the recovery message comprises at least the count of the plurality of transaction messages, the predetermined number of hash cycles, the size, and the generated Bloom filter; and a sending device of the processing server configured to electronically transmit the message to the server. sending the generated recovery message to at least one consensus node; a receiving device of the processing server, configured to receive a response message from one or more of the at least one consensus node, wherein the response message includes at least a second Bloom filter, an indicated number of hash cycles, an indicated filter size, and an expected number of transaction messages; a data identification module of the processing server, configured to identify at least one transaction message of the plurality of transaction messages that is not included in the second Bloom filter based on the included transaction value, the indicated number of hash cycles, the indicated filter size, the expected number of transaction messages, and the second Bloom filter; and a query module of the processing server, configured to perform a query on the transaction database to delete the at least one identified transaction message. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] 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, which include the following figures:

[0014] Figure 1 is a block diagram illustrating a high-level system architecture for efficient consensus and recovery of desynchronized nodes in a permissioned blockchain network, according to an exemplary embodiment;

[0015] Figure 2 is a diagram illustrating efficient consensus and recovery for desynchronizing nodes in a permissioned blockchain network according to an exemplary embodiment Figure 1 Block diagram of the audit node in ;

[0016] Figure 3 is a flow chart illustrating a process for identifying a consensus proposal among consensus nodes of a permissioned blockchain network according to an exemplary embodiment;

[0017] Figure 4A and 4B is a diagram showing how to use the Figure 1A flowchart of a process for recovering desynchronized consensus nodes in a permissioned blockchain network using a Bloom filter in a system;

[0018] Figure 5 is a flow chart illustrating a process for resynchronizing a desynchronized consensus node in a permissioned blockchain network according to an exemplary embodiment;

[0019] Figure 6 is a flow chart illustrating a process of performing consensus auditing in an audit node in a permissioned blockchain network for valid consensus on a new block according to an exemplary embodiment;

[0020] Figure 7 is a flow chart illustrating a process for validating and adding new blocks to a permissioned blockchain as a result of an effective consensus mechanism according to an exemplary embodiment;

[0021] Figure 8 is a flow chart illustrating an exemplary method for adding a block to a permissioned blockchain using an efficient consensus mechanism according to an exemplary embodiment;

[0022] Figure 9 and 10 is a flow chart illustrating an exemplary method of recovering lost data or additional data using a Bloom filter according to an exemplary embodiment;

[0023] Figure 11 is a block diagram illustrating a computer system architecture according to an exemplary embodiment.

[0024] 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 the exemplary embodiments is for illustration purposes only and is therefore not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION

[0025] Glossary

[0026] Blockchain - A public ledger of all transactions in a blockchain-based currency. One or more computing devices may comprise a blockchain network configured to process and record transactions as part of blocks in the blockchain. Once a block is completed, it is added to the blockchain, thereby updating the transaction record. In many cases, the blockchain can be a chronological ledger of transactions, or it can be presented in any other order suitable for use by the blockchain network. In some configurations, transactions recorded in the blockchain can include a destination address and a monetary amount, so that the blockchain records how much money is attributable to a particular address. In some cases, transactions are financial, while in other cases they are not, or they may include additional or different information, such as a source address, a timestamp, etc. In some embodiments, the blockchain may also or alternatively include virtually any type of data in the form of transactions, which is or is required to be stored in a permissionless, distributed database that maintains a continuously growing list of data records that is tamper-proof and cannot be modified, even by the operator of the data, and can be validated and verified by the blockchain network through proof-of-work and / or any other suitable verification technology associated therewith. In some cases, data associated with a given transaction may further include additional data appended to the transaction data that is not directly part of the transaction. In some cases, the inclusion of such data in a blockchain may constitute a transaction. In some cases, participation in a blockchain (e.g., as a node that submits and / or confirms transactions) may be permissionless (e.g., unrestricted or unrestricted). In other cases, a blockchain may be a permissioned blockchain, in which only authorized computing devices may operate as nodes, where the level of participation may be based on the permissions associated therewith.

[0027] A system for achieving efficient consensus and recovery in permissioned blockchain networks

[0028] Figure 1 A system 100 is shown that uses an efficient consensus mechanism for consensus on new blocks added to a permissioned blockchain network and recovery of desynchronized nodes included in the blockchain network.

[0029] System 100 may include an audit node 102. Audit node 102 may be part of a permissioned blockchain network. A permissioned blockchain network may be a network of multiple nodes associated with a permissioned blockchain. A permissioned blockchain may be a blockchain in which contribution and consensus of new blocks to be added to the blockchain, as well as participation in transactions and other data included therein, may be restricted to authorized (e.g., "permissioned") nodes. In system 100, the permissioned blockchain network may include multiple audit nodes 104a, 104b, 104c, and 104d and consensus nodes 106a, 106b, 106c, and 106d. As discussed in more detail below, consensus nodes 106a, 106b, 106c, and 106d may be configured to receive and provide transactions for inclusion in the permissioned blockchain, and audit nodes 104a, 104b, 104c, and 104d may be configured to perform the functions of a consensus node and to perform consensus audits to audit new blocks to be added to the permissioned blockchain. In some embodiments, a permissioned blockchain may include other types of nodes, such as member or application nodes that serve transactions but do not participate in consensus, as well as other nodes that may be appropriate depending on the functionality and implementation of the permissioned blockchain.

[0030] Audit node 102 may be a processing server or other specially configured computing device and / or system configured to perform the functions of consensus nodes 106a, 106b, 106c, and 106d and audit nodes 104a, 104b, 104c, and 104d. Audit node 102 may be connected to multiple consensus nodes 106a, 106b, 106c, and 106d (e.g., Figure 1106a, 106b, 106c, and 106d). Each consensus node 106a, 106b, 106c, and 106d in the permissioned blockchain network may be connected to a plurality of other consensus nodes 106a, 106b, 106c, and 106d in any suitable network topology. For example, a mesh topology may be used to connect the consensus nodes 106a, 106b, 106c, and 106d. In some cases, some consensus nodes 106a, 106b, 106c, and 106d may only be connected to other consensus nodes and may not be connected to the audit nodes 104a, 104b, 104c, and 104d. Each other audit node 104a, 104b, 104c, and 104d in the blockchain network may also be connected to multiple consensus nodes 106a, 106b, 106c, and 106d in addition to being connected to each other audit node 104a, 104b, 104c, and 104d. In some cases, consensus nodes 106a, 106b, 106c, and 106d may only be connected to a single audit node, such as audit node 102 or one of the other audit nodes 104a, 104b, 104c, and 104d.

[0031] Audit node 102, when performing the functions of audit nodes 104a, 104b, 104c, and 104d, may connect to multiple audit nodes 104a, 104b, 104c, and 104d using suitable communication networks and methods. In an exemplary embodiment, the number of audit nodes 104a, 104b, 104c, and 104d in a permissioned blockchain network may be limited to a maximum number, for example, so that consensus can be reached more quickly and efficiently using the methods discussed herein. For example, a permissioned blockchain network may limit the number of audit nodes 104a, 104b, 104c, and 104d to 7, even in cases where the number of consensus nodes may be in the thousands, tens of thousands, hundreds of thousands, or even larger. In some cases, as discussed in more detail below, the number of audit nodes 104a, 104b, 104c, and 104d may be an odd number, for example, so that a majority of them can be determined during a consensus audit. In an exemplary embodiment, each audit node 104a, 104b, 104c, and 104d may be interconnected, such as Figure 1 As shown, each audit node 104a, 104b, 104c, and 104d is connected to each other audit node. In some cases, audit nodes 104a, 104b, 104c, and 104d can be geographically distributed in the permissioned blockchain network to reduce the possibility of important network disconnects or partitions.

[0032] In system 100, audit node 102 and other nodes in a permissioned blockchain network configured to perform the functions of consensus nodes 106a, 106b, 106c, and 106d (e.g., consensus nodes 106a, 106b, 106c, and 106d and audit nodes 104a, 104b, 104c, and 104d) can receive transaction messages from application nodes or other nodes in the permissioned blockchain network, which are configured to provide data for transactions to be added to the permissioned blockchain. The transaction message can be electronically sent to audit node 102 via a suitable communication network and can include at least a transaction value. The transaction value can be a transaction record or other value to be added to the permissioned blockchain. For example, the transaction value can be a transaction record including destination and source addresses, their associated digital signatures, and a transaction amount representing an amount of cryptocurrency transferred from the destination address to the source address. In another example, the transaction value can be an alphanumeric or other suitable value representing a transaction or other data, such as data in an opaque permissioned blockchain. Additional data regarding opaque blockchains can be found in U.S. patent application Ser. No. 14 / 950,117, filed by Steven C. Davis on November 24, 2015, entitled “Method and System for Gross Settlement by the Use of an Opaque Blockchain,” which is incorporated herein by reference in its entirety.

[0033] In some embodiments, a transaction message may also include a timeslot identifier. A timeslot identifier may be an identifying value indicating the timeslot to which the corresponding transaction value belongs. A timeslot may be a delimiter or other classification organization for transactions to be added to a permissioned blockchain. In exemplary embodiments, a timeslot may be associated with the time or time range corresponding to the relevant transaction. For example, a timeslot may be associated with a second in time, where each transaction associated with a corresponding timeslot identifier for a timeslot may be a transaction conducted at that second in time. In such an example, the timeslot identifier may be a representation of that second in time, such as a timestamp in seconds since the beginning of UNIX, or another suitable date and time representation indicating that second. For example, the timestamp identifier for all transactions conducted at the first second of 2016 may be 1451606400.

[0034] When an audit node 102 receives a transaction message, it may determine whether the transaction value included in the transaction message is already stored in its local database of unconfirmed transaction values ​​to be added to the permissioned blockchain. If the transaction message includes a slot identifier, this determination may be made based on whether the transaction value is already stored for the included slot identifier. If the transaction value has not yet been received, the audit node 102 may store it along with other transaction values ​​associated with the slot identifier. The audit node 102 may then rebroadcast the transaction message to each of its connected consensus nodes 106a, 106b, 106c, and 106d. Connected consensus nodes 106a, 106b, 106c, and 106d may receive the transaction message and further perform determination, storage, and rebroadcast as needed. If the audit node 102 has already received the transaction value, the audit node 102 may ignore the transaction message and not rebroadcast it. The audit node 102 may repeat this process for each transaction message received from the application node and rebroadcasted from the consensus nodes 106a, 106b, 106c, and 106d to which it is connected.

[0035] Thus, the audit node 102 and each consensus node 106a, 106b, 106c, and 106d can quickly propagate all transaction messages throughout the permissioned blockchain network. Since rebroadcasting only occurs when a transaction message has not been previously received (e.g., because the transaction value is not in the stored unconfirmed transaction list), traffic in the permissioned blockchain network can be kept to a minimum, while the number of redundant transaction messages received is minimized.

[0036] In some embodiments, the audit node 102 may be configured to generate a reference value for each transaction value received and added to the list of unconfirmed transactions. The reference value may be a hash value or other representation of the transaction value as a single value. In cases where the transaction value may already be a reference value (e.g., in an opaque blockchain), the transaction value itself may be used as a reference value. In other cases, such as when the transaction value is a transaction record comprising multiple data values, the audit node 102 may hash the transaction record using one or more predetermined hashing algorithms to obtain a corresponding transaction reference value. In such an embodiment, the list of unconfirmed transactions may be a list of transaction reference values. In such an instance, the audit node 102 may generate a reference value for each received transaction value before determining whether the transaction value has been received.

[0037] Audit node 102 and other nodes performing the functions of consensus nodes 106a, 106b, 106c, and 106d can be configured to maintain a timestamp for the arrival of transaction messages. In this case, audit node 102 can update the timestamp each time a new transaction message is received, where the timestamp thereby indicates the arrival time of the most recent transaction message. In some examples, for example, when each timeslot identifier represents one second, the timestamp used by audit node 102 to mark the most recent arrival of a transaction message can use milliseconds, nanoseconds, or other representations smaller than the timeslot identifier.

[0038] Audit node 102 and other consensus nodes 106a, 106b, 106c, and 106d may continue to receive transaction messages and subsequently execute consensus proposals. In some embodiments, audit node 102 may begin the consensus proposal process after a predetermined period of time has passed since the arrival of the last transaction message (e.g., indicated by its timestamp), referred to herein as the "consensus delay time." In some cases, audit node 102 may consider the consensus delay time to be the time between the timestamp marking the arrival of the most recent transaction message and the time audit node 102 is turned on to receive the transaction message corresponding to that timeslot identifier, plus an additional buffer time interval. In some cases, for example, based on the location of consensus nodes 106a, 106b, 106c, and 106d in the permissioned blockchain network and other considerations, the consensus delay time may be different for each consensus node 106a, 106b, 106c, and 106d. In some embodiments, the consensus delay time may be recalculated based on the performance of the permissioned blockchain network. For example, the consensus delay time may be recalculated at periodic intervals (e.g., hourly, daily, etc.).

[0039] A consensus proposal can be a process by which the audit node 102 and other consensus nodes 106a, 106b, 106c, and 106d come to a consensus on an unconfirmed transaction to be added to a permissioned blockchain. In the case of slot identifiers, the consensus proposal can relate to a specific slot identifier. As part of the consensus proposal, the audit node 102 can generate a Merkle root for the unconfirmed transaction. The Merkle root can be the value of the root node in a Merkle tree generated from the transaction message for the unconfirmed transaction already stored in the audit node 102 (e.g., associated with the slot identifier, if applicable). In the case of generating a transaction reference value for the transaction value, the reference value can be used in the generation of the Merkle tree and the subsequent identification of the Merkle root. The audit node 102 can generate the Merkle root using one or more predetermined hashing algorithms by applying them to the transaction reference value and a subsequent hash value.

[0040] In some embodiments, the audit node 102 and each consensus node 106a, 106b, 106c, and 106d can be configured to sort the transaction reference values ​​before generating a Merkle root, such that each consensus node 106a, 106b, 106c, and 106d generates a Merkle root that maintains the same order of the transaction reference values. In such an embodiment, the transaction reference values ​​can be sorted in a natural order based on the type of the reference value. For example, if the reference values ​​are integers or alphanumeric values, they can be sorted in a natural ascending or descending order. The sorting of the transaction reference values ​​and the use of a predetermined hashing algorithm can ensure that the audit node 102 and each consensus node 106a, 106b, 106c, and 106d generate the same Merkle root if the corresponding node has received all transaction values ​​corresponding to the time slot identifier.

[0041] To determine whether such consensus has been reached (e.g., that the audit node 102 has generated the same Merkle root as the consensus nodes 106a, 106b, 106c, and 106d connected to it, and therefore received the same transaction value), the audit node 102 may generate a proposal message. The proposal message may include at least the generated Merkle root and, if applicable, the slot identifier of the relevant slot. The audit node 102 may electronically send the proposal message to each connected consensus node 106a, 106b, 106c, and 106d. Each connected consensus node 106a, 106b, 106c, and 106d may also generate a proposal message, which may be sent from the consensus node 106a, 106b, 106c, and 106d to each other node connected to it. Thus, the audit node 102 may receive a proposal message from each connected consensus node 106a, 106b, 106c, and 106d. Audit node 102 may store a list of each Merkle root received from neighboring (eg, connected) consensus nodes 106a, 106b, 106c, and 106d.

[0042] Audit node 102 can be configured to determine whether consensus exists between audit node 102 and its neighboring consensus nodes 106a, 106b, 106c, and 106d by comparing the respective Merkle roots. If the Merkle roots received from neighboring consensus nodes 106a, 106b, 106c, and 106d match the Merkle root generated by audit node 102, then audit node 102 can consider itself synchronized with the rest of the permissioned blockchain network. If the Merkle root generated by audit node 102 differs from the Merkle root received from neighboring consensus nodes 106a, 106b, 106c, and 106d, then audit node 102 may be desynchronized, which may indicate that audit node 102 failed to receive one or more transaction values ​​or may have included unrelated transaction reference values ​​in its list of unconfirmed transactions. In the event that audit node 102 is desynchronized, audit node 102 may perform a recovery process discussed in more detail below. If the Merkle root generated by the audit node 102 matches most of the Merkle roots received from neighboring consensus nodes 106a, 106b, 106c, and 106d, but one or more of the received Merkle roots are different, it can indicate that the consensus nodes 106a, 106b, 106c, and 106d, i.e., the nodes that provided different Merkle roots, are desynchronized, which can cause them to perform a recovery process.

[0043] Once consensus proposals have been exchanged between consensus nodes 106a, 106b, 106c, and 106d, a consensus audit can be performed. The consensus audit can be performed by audit node 102 and each audit node 104a, 104b, 104c, and 104d in the permissioned blockchain network. In an exemplary embodiment, the consensus audit can be performed using the Paxos protocol, which is suitable for use in system 100, so that audit nodes 104a, 104b, 104c, and 104d reach consensus on unconfirmed transactions to add them to the permissioned blockchain. As described below, the consensus audit can be performed using digital signatures generated by audit node 102 and each audit node 104a, 104b, 104c, and 104d, which can be used as proposal numbers in the Paxos protocol.

[0044] To perform a consensus audit, audit node 102 may generate a temporary header for a new block to be added to a permissioned blockchain that includes unconfirmed transactions. The temporary header may include at least a Merkle root generated for the unconfirmed transaction and a hash value of a header of a previous block most recently added to the permissioned blockchain. The hash value of the header of the previous block may be generated by audit node 102 using one or more predetermined hashing algorithms, which may be the same algorithm used by each of audit nodes 104a, 104b, 104c, and 104d when generating the hash value. In some embodiments, the temporary header may also include additional data (e.g., a time slot identifier or other data discussed in more detail below) that may be included in the header of the block added to the permissioned blockchain.

[0045] After generating the temporary block header, the audit node 102 may hash the temporary block header using one or more predetermined hashing algorithms that are the same as the hashing algorithms used to generate the hash value of the block header of the previous block to generate a hash value of 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 audit node 102. The prepare message may include the block hash, a timeslot identifier (if applicable), and may also include a proposal number generated by the audit node 102.

[0046] The proposal number may be a digital signature generated by the audit node 102. In some cases, the audit node 102 may generate the digital signature using an anti-collision algorithm to increase the likelihood that the proposal number generated by the audit node 102 and each of the audit nodes 104a, 104b, 104c, and 104d is unique. For example, the audit node 102 may generate the digital signature using the elliptic curve digital signature algorithm (ECDSA). In such an example, the audit node 102 may generate the digital signature using a public key associated with it. In such an embodiment, 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 before the block hash is generated. In some embodiments, the audit node 102 may also generate a random or pseudo-random number to be included in the prepare message for use as a cryptographic salt, which may also be included in the temporary block header before the block hash is generated.

[0047] Once the prepare message has been generated, the audit node 102 may electronically send the prepare message to each audit node 104a, 104b, 104c, and 104d connected thereto. The audit node 102 may similarly receive the prepare message thus generated from each audit node 104a, 104b, 104c, and 104d. Each prepare message received includes a different digital signature, which serves as a proposal number and is generated using a corresponding associated public key. Upon receiving the prepare message, the audit node 102 may identify the highest (e.g., with respect to the natural ordering of the digital signatures) proposal number. It will be apparent to those skilled in the relevant art that, as discussed herein, the use of the highest proposal number for consensus is merely exemplary, and that any other suitable criteria (e.g., the lowest proposal number, the proposal number closest to a predetermined value, etc.) may be used to determine consensus on a proposal number.

[0048] Once the audit node 102 has identified the highest proposal number, the audit node 102 may generate a prepare response message and send it to the originator of the prepare message including the highest proposal number. In the event that the audit node 102 generates the highest proposal number, the audit node 102 may not generate a prepare response message. The prepare response message may include a digital signature identified as the highest proposal number and, if applicable, a slot identifier associated with the slot in which consensus is being executed. In the event that the audit node 102 has generated (e.g., and distributed) a higher proposal number than neighboring audit nodes 104a, 104b, 104c, and 104d, the audit node 102 may receive prepare response messages from neighboring audit nodes 104a, 104b, 104c, and 104d indicating that the digital signature generated by the audit node 102 is higher.

[0049] When an audit node 102 or another audit node 104a, 104b, 104c, and 104d receives a prepare response message from a majority of audit nodes 104a, 104b, 104c, and 104d, the node may enter a consensus acceptance phase. During the acceptance phase, the audit node 102 (e.g., or another node that has received a majority of prepare response messages) may generate an accept message. The accept message may include the same data as included in the prepare message generated by the node, and thus it will include a digital signature identified as the highest proposal number. The accept message may then be electronically sent to each audit node 104a, 104b, 104c, and 104d that has provided the node with a prepare response message.

[0050] In the event that an audit node 102 (e.g., or other audit nodes 104a, 104b, 104c, and 104d) enters the Accept phase and subsequently receives a Prepare message from a neighboring audit node 104a, 104b, 104c, and 104d that includes a higher proposal number, the audit node 102 generates a Prepare Response message as described above, but the Prepare Response message may also include the block hash, public key, and signature (e.g., if applicable, a random number) previously identified in the Accept message generated thereby. Thus, the audit nodes 104a, 104b, 104c, and 104d with the higher proposal number will receive a Prepare Response message indicating that the audit node 102 and its own proposal number have entered the Accept phase. Due to having the higher proposal number, the audit nodes 104a, 104b, 104c, and 104d will receive Prepare Response messages from the majority of the audit nodes 104a, 104b, 104c, and 104d and will themselves enter the Accept phase. Audit nodes 104a, 104b, 104c, and 104d will generate accept messages to be sent to their neighboring audit nodes 104a, 104b, 104c, and 104d, including audit node 102. Audit node 102, receiving the accept messages from audit nodes 104a, 104b, 104c, and 104d, will acknowledge the higher proposal number and accordingly record it as the highest proposal number received.

[0051] This process may continue until each audit node 104a, 104b, 104c, and 104d has received an acceptance message with the highest proposal number generated by any audit node 104a, 104b, 104c, and 104d. In the case where the number of audit nodes 104a, 104b, 104c, and 104d in a permissioned blockchain network is limited (e.g., limited to 7 or the like), since audit nodes 104a, 104b, 104c, and 104d may only communicate with other audit nodes 104a, 104b, 104c, and 104d to confirm a higher proposal number, consensus audits can be resolved very quickly (on the order of milliseconds or nanoseconds) and efficiently (with a minimal amount of data exchange), thereby propagating the highest proposal number to each audit node with a minimal number of transmissions.

[0052] Once the audit node 102 has received the highest proposal number (generated by itself or received in an acceptance message from another audit node 104a, 104b, 104c, and 104d), the permissioned blockchain network can begin consensus confirmation. For consensus confirmation, the audit node 102 (e.g., and each of the other audit nodes 104a, 104b, 104c, and 104d) can generate a confirmation message. The confirmation message can include the block hash generated and used in the consensus audit, as well as the digital signature accepted as the highest proposal number. If applicable, the confirmation message can also include the public key used in generating the digital signature, if applicable, the nonce included in the acceptance message, and, if applicable, the time slot identifier to which the confirmation message applies. The consensus message can then be electronically sent to each neighboring consensus node 106a, 106b, 106c, and 106d.

[0053] Upon receiving the confirmation message, consensus nodes 106a, 106b, 106c, and 106d generate a block header for a new block to be added to the permissioned blockchain, including each unconfirmed transaction. The block header may include a Merkle root, a slot identifier, and any other necessary data. Consensus nodes 106a, 106b, 106c, and 106d may then hash the block header to verify that the resulting hash value (e.g., a "block hash") matches the block hash included in the confirmation message, thereby verifying that the confirmation message is authentic. A digital signature may be included in the block header, which may be included in a new block generated by consensus nodes 106a, 106b, 106c, and 106d, including the complete block header and the transaction value for each unconfirmed transaction. Consensus nodes 106a, 106b, 106c, and 106d may then write the new block to the permissioned blockchain. Consensus nodes 106a, 106b, 106c, and 106d may also remove the corresponding transaction reference value from its unconfirmed transaction list and remove the Merkle root mapped to the associated time slot from its storage area. Consensus nodes 106a, 106b, 106c, and 106d may rebroadcast the confirmation message to each of its own neighboring consensus nodes 106a, 106b, 106c, and 106d to ensure that the confirmation message is propagated throughout the permissioned blockchain network.

[0054] In embodiments where slot identifiers can be used, audit node 102 and other nodes in the permissioned blockchain network can be configured to simultaneously perform actions related to multiple phases of the consensus process. In such embodiments, the use of slot identifiers can ensure that messages sent to and from a node are associated with the correct corresponding transactions. For example, due to processing time and consensus latency, audit node 102 may have transaction values ​​for four different slots at any given time. Consequently, audit node 102 may have a different list of unconfirmed transactions for each slot. In such an example, consensus confirmation can be performed for the first slot, consensus auditing can be performed for the second slot, consensus proposals can be exchanged for the third slot, and transaction messages can be received for the fourth slot.

[0055] In the event that an audit node 102 or other nodes in a permissioned blockchain network (e.g., audit nodes 104a, 104b, 104c, and 104d or consensus nodes 106a, 106b, 106c, and 106d) may become out of sync ("desynchronized") with the rest of the permissioned blockchain network, the audit node 102 may initiate a recovery process. If the Merkle root generated by the audit node 102 does not match the Merkle roots provided by a majority of neighboring consensus nodes 106a, 106b, 106c, and 106d received during the consensus proposal process, the audit node 102 identifies desynchronization. In this case, the audit node 102 may be missing one or more unconfirmed transactions from its list of unconfirmed transactions, or may include additional unconfirmed transactions. This may occur, for example, if a transaction message received by the audit node 102 includes an incorrect slot identifier, or if a transaction reference value is stored in an incorrect list of unconfirmed transactions. When desynchronized, the audit node 102 can identify synchronized neighboring consensus nodes 106a, 106b, 106c, and 106d (e.g., indicated by their corresponding proposal messages having Merkle roots that match the majority) and can electronically send recovery messages to the consensus nodes 106a, 106b, 106c, and 106d.

[0056] The recovery message may include a slot identifier associated with the time slot for which audit node 102 is not synchronized. The recovery message may also include a Bloom filter. The Bloom filter may be a Bloom filter of transaction reference values ​​included in the list of unconfirmed transactions corresponding to a particular time slot, wherein each transaction reference value is hashed over a specific number of rounds (referred to herein as "hash rounds"), and wherein the size of the Bloom filter bitmap is at least twice the number of unconfirmed transactions in the list of unconfirmed transactions for which the filter is generated. In some embodiments, one or more hash rounds may use different hashing algorithms, wherein the use and order of the hashing algorithms are known to each node in the permissioned blockchain network or may be communicated in the recovery message. In other embodiments, audit node 102 may use the same hashing algorithm for each hash round. Audit node 102 may include the Bloom filter in the recovery message and may also include the number of hash rounds, the size of the Bloom filter, and a count of the number of unconfirmed transactions in the list of unconfirmed transactions corresponding to the time slot being recovered.

[0057] The recovery message can then be electronically sent to neighboring consensus nodes 106a, 106b, 106c, and 106d. Consensus nodes 106a, 106b, 106c, and 106d can receive the recovery message and can determine whether audit node 102 is missing a transaction reference value or whether an irrelevant transaction reference value exists in the audit node's list of unconfirmed transactions. This determination can be made based on the count included in the recovery message and the count of unconfirmed transactions in the consensus node's own slot list.

[0058] In the event that audit node 102 is missing one or more transactions (e.g., the consensus node's count is higher), consensus nodes 106a, 106b, 106c, and 106d can then run each of its unconfirmed transactions through a Bloom filter to determine which transaction reference values ​​are missing from the audit node's list. Using a bitmap twice the size of the number of unconfirmed transactions can provide a very high degree of accuracy in estimating the transaction reference values ​​to include in the Bloom filter. Consensus nodes 106a, 106b, 106c, and 106d can identify a transaction value for each transaction reference value identified as missing from the audit node's list and can return a recovery response message including the transaction value to audit node 102. Audit node 102 receives the recovery response message, generates a transaction reference value for the transaction value, updates its list of unconfirmed transactions, and regenerates the Merkle root for the slot. Audit node 102 can return to synchronization based on the Merkle root generation result, or can continue to desynchronize and repeat the recovery process. For example, a false positive when consensus nodes 106a, 106b, 106c, and 106d use the Bloom filter may result in the audit node 102 still being missing a transaction reference value, which can be identified using the second Bloom filter.

[0059] In the event that the audit node 102 may have one or more unrelated transaction reference values ​​(e.g., a node with a higher count than the consensus nodes 106a, 106b, 106c, and 106d), the consensus nodes 106a, 106b, 106c, and 106d may generate their own Bloom filter for each transaction reference value included in their own list of unconfirmed transactions. The consensus nodes 106a, 106b, 106c, and 106d may reply to the recovery message with a recovery response message that includes a slot identifier, their own Bloom filter, and parameters associated with the new Bloom filter (e.g., count, filter size, and hash rounds). The consensus nodes 106a, 106b, 106c, and 106d may electronically send the recovery response message to the audit node 102. Audit node 102 can then input its transaction reference values ​​into the Bloom filters provided by consensus nodes 106a, 106b, 106c, and 106d to identify which transaction reference values ​​in its list are not in the Bloom filters and can remove those transactions from its list. Audit node 102 can generate a new Merkle root for the time slot, can determine whether audit node 102 is synchronized, and can repeat the recovery process if necessary.

[0060] The use of Bloom filters can enable audit node 102 or another node in a permissioned blockchain network to perform recovery without having to send all blocks or large transaction values ​​from the permissioned blockchain, thereby reducing network traffic and improving network efficiency. Audit node 102 and other nodes can still exchange all transaction values ​​corresponding to unconfirmed time slots, or can be configured to exchange completed blocks or block headers corresponding to time slots in the event that Bloom filter recovery is unsuccessful, in order to synchronize all nodes in the permissioned blockchain network, but this may only be necessary in such cases, thereby reducing network traffic. Additionally, the use of time slots to organize and separate transactions in a permissioned blockchain network can provide a suitable organization and differentiation mechanism, allowing the use of Bloom filters to provide faster recovery while still maintaining a high degree of synchronization. For example, if recovery for an earlier time slot is completed before consensus for a later time slot is confirmed, then desynchronized consensus nodes 106a, 106b, 106c, and 106d can still perform consensus proposals for the later time slot while recovering the earlier time slot.

[0061] The methods and systems discussed herein provide a more efficient transaction consensus mechanism in a permissioned blockchain network. The use of consensus proposals for individual consensus nodes 106a, 106b, 106c, and 106d, consensus auditing by a limited number of auditing nodes 104a, 104b, 104c, and 104d, and consensus confirmation by all consensus nodes 106a, 106b, 106c, and 106d, combined with the use of Bloom filter recovery to desynchronize nodes, enables the permissioned blockchain network to reach consensus in seconds or faster using minimal data message exchanges. This not only improves the speed of reaching consensus, but also increases its efficiency, thereby reducing network traffic and congestion, thereby improving network performance and lowering operational expenses. Consequently, the consensus and recovery mechanisms discussed herein achieve consensus faster and more efficiently than existing consensus mechanisms.

[0062] Audit Node

[0063] Figure 2 An embodiment of an audit node 102 in a system 100 is shown. It will be apparent to those skilled in the relevant art that Figure 2 The embodiment of the audit node 102 shown in is provided for illustration only and is not intended to be exhaustive of all possible configurations of the audit node 102 for performing the functions discussed herein. For example, Figure 11The computer system 1100 shown and discussed in more detail below may be a suitable configuration for an audit node 102. As described above, the audit node 102 may be configured to perform each of the functions of the consensus nodes 106a, 106b, 106c, and 106d. Thus, the consensus nodes 106a, 106b, 106c, and 106d may include components of the audit node 102 for performing the functions associated therewith.

[0064] The audit node 102 may include a receiving device 202. The receiving device 202 may be configured to receive data on one or more networks via one or more network protocols. The receiving device 202 may be configured to receive data from the audit nodes 104a, 104b, 104c, and 104d and other devices and systems via a suitable communication network and corresponding network protocol. In some embodiments, the receiving device 202 may be composed of multiple devices, for example, different receiving devices that receive data via different networks (for example, a first receiving device that receives data via a local area network and a second receiving device that receives data via a permissioned blockchain network). The receiving device 202 may receive an electronically transmitted data signal, wherein the data may be superimposed or otherwise encoded onto the data signal, and the data signal is received by the receiving device 202 and decoded, parsed, read, or otherwise obtained from the data signal. In some cases, the receiving device 202 may include a parsing module that parses the received data signal to obtain the data superimposed thereon. For example, the receiving device 202 may include a parser program configured to receive data signals and transform the received data signals into usable inputs for a processing device to perform functions to implement the methods and systems described herein.

[0065] The receiving device 202 can be configured to receive data signals electronically transmitted by other nodes in the permissioned blockchain network (including application or member nodes, consensus nodes 106a, 106b, 106c, and 106d, audit nodes 104a, 104b, 104c, and 104d, etc.). The data signals received by the receiving device 202 can be superimposed on or otherwise encoded with transaction messages, proposal messages, proposal messages, prepare messages, prepare response messages, accept messages, confirm messages, recover messages, and recover response messages. The receiving device 202 can also be configured to receive data signals superimposed on or otherwise encoded with additional data for performing functions associated with operating as a node in the permissioned blockchain network, such as permission updates, hashing algorithms, public keys, Bloom filter specifications, etc.

[0066] The audit node 102 may also include a communication module 204. The communication module 204 may be configured to transmit data between modules, engines, databases, memories, and other components of the audit node 102 for performing the functions discussed herein. The communication module 204 may be composed of one or more communication types and utilize various communication methods for communication within the computing device. For example, the communication module 204 may include a bus, a pin connector, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the audit node 102 and external components of the audit node 102 (e.g., externally connected databases, display devices, input devices, etc.). The audit node 102 may also include a processing device. The processing device may be configured to perform the functions of the audit node 102 discussed herein, which will be apparent to those skilled in the relevant art. In some embodiments, the processing device may include multiple engines and / or modules specifically configured to perform one or more functions of the processing device (e.g., query module 210, hash module 212, generation module 214, data identification module 218, verification module 220, etc.), and / or the processing device may be composed of the above-mentioned engines and / or modules. As used herein, the term "module" can be software or hardware that is specifically programmed to receive input, perform one or more processes using the input, and provide output. Based on the content of this disclosure, the inputs, outputs, and processes performed by various modules will be apparent to those skilled in the art.

[0067] Audit node 102 may include a transaction database 206. Transaction database 206 may be configured to store a plurality of transaction messages 208 using a suitable data storage format and schema. Transaction database 206 may be a relational database that utilizes a structured query language to store, identify, modify, update, access, and the like structured datasets stored therein. Each transaction message 208 may be a structured dataset configured to store data related to a transaction to be added to a permissioned blockchain. For example, each transaction message 208 may include a slot identifier associated with the slot corresponding to the associated transaction, as well as a transaction value. The transaction value may be a transaction reference value, or a transaction record or other data used by audit node 102 to generate the transaction reference value.

[0068] The transaction database 206 or other data storage in the audit node 102 (e.g., memory 222 discussed in more detail below) can also be configured to store a list of unconfirmed transactions. The list of unconfirmed transactions can be a list associated with a time slot (e.g., associated by a corresponding time slot identifier) ​​that includes a transaction reference value for the transaction to be added to the permissioned blockchain. In some cases, the consensus map can be stored in the transaction database 206 along with the corresponding list of unconfirmed transactions, which can include a Merkle root for the corresponding list of unconfirmed transactions generated by the audit node 102 and received from the consensus nodes 106a, 106b, 106c, and 106d.

[0069] The audit node 102 may include a query module 210. The query module 210 may be configured to perform queries on a database to identify information. The query module 210 may receive one or more data values ​​or query strings and, based thereon, may perform a string query on an indicated database (e.g., the transaction database 206) to identify information stored therein. The query module 210 may then output the identified information to an appropriate engine or module of the audit node 102 as needed. The query module 210 may, for example, perform a query on the transaction database 206 to insert the transaction message 208 when the receiving device 202 receives the transaction message 208. For example, the query module 210 may also be configured to perform queries to update a list of unconfirmed transactions, identify transaction values ​​to include in a new block, and clear a consensus map and unconfirmed transactions corresponding to confirmed time slots.

[0070] Audit node 102 may also include a hash module 212. Hash module 212 may be configured to generate a hash value for data by applying one or more hash algorithms to the data. Hash module 212 may receive data as input, generate a hash value by applying the hash algorithm to the data, and output the generated hash value to another module or engine of audit node 102. In some cases, hash module 212 may also receive a hash algorithm as input. In other cases, hash module 212 may be configured to identify (e.g., by querying memory 222 via query module 210) a hash algorithm to use for generating the hash value. Hash module 212 may be configured to generate hash values ​​for block headers in a permissioned blockchain, generate block hashes for temporary block headers, generate transaction reference values ​​for transaction values, generate Merkle roots for lists of unconfirmed transactions, generate digital signatures for use as proposal numbers, generate hashed transaction reference values ​​for Bloom filters, and generate any other hash values ​​suitable for performing the functions of audit node 102 as discussed herein.

[0071] Audit node 102 may also include a generation module 214. Generation module 214 may be configured to generate data and data messages for performing the functions of audit node 102 as discussed herein. Generation module 214 may receive a request, may generate a data message or data based on the request, and may output the generated data or message to another module or engine of audit node 102. For example, generation module 214 may be configured to generate a proposal message, a prepare message, a prepare response message, an accept message, a confirmation message, a recovery message, and a recovery response message. Generation module 214 may also be configured to generate a temporary block header, a new block header, a new block, and may be configured to write the new block to the permissioned blockchain (e.g., directly or by generating a query and submitting the query to query module 210). Generation module 214 may also be configured to generate a Bloom filter in conjunction with hash module 212 for use in recovering audit node 102 upon desynchronization. In some cases, generation module 214 may be configured to generate a timestamp that may be represented in any suitable format.

[0072] The audit node 102 may also include a data identification module 218. The data identification module 218 may be configured to receive one or more data values ​​as input, may identify data based on the input data values, and may output the identified data to another module or engine of the audit node 102. For example, the data identification module 218 may be configured to identify an order of transaction reference values ​​to be used for Merkle root generation, and to identify an order of proposal numbers and to identify the highest proposal number for consensus auditing (or other suitable consensus criteria). The data identification module 218 may also be configured to input the transaction reference values ​​into a Bloom filter to identify transaction reference values ​​that are not included in the Bloom filter so that they can be removed from the corresponding unconfirmed transaction list (e.g., through a query performed by the query module 210).

[0073] The audit node 102 may also include a verification module 220. The verification module 220 may be configured to receive a data value as input, may verify the input data value, and may output a verification result to another module or engine of the audit node. For example, the verification module 220 may verify data included in a confirmation message received from the audit nodes 104a, 104b, 104c, and 104d or the consensus nodes 106a, 106b, 106c, and 106d, for example, by confirming that a block hash generated by the hash module 212 for the block header matches the block hash included in the confirmation message received by the receiving device 202. The verification module 220 may also be configured to verify equivalence between Merkle roots to identify whether the audit node 102 or adjacent consensus nodes 106a, 106b, 106c, and 106d or the audit nodes 104a, 104b, 104c, and 104d are out of sync.

[0074] The audit node 102 may also include a sending device 216. The sending device 216 may be configured to send data over one or more networks via one or more network protocols. The sending device 216 may be configured to send data to the audit nodes 104a, 104b, 104c, and 104d and other entities via a suitable communication network and corresponding network protocol. In some embodiments, the sending device 216 may be composed of multiple devices, for example, different sending devices that send data over different networks (for example, a first sending device that sends data over a local area network and a second sending device for sending data over a permissioned blockchain network). The sending device 216 may electronically send a data signal superimposed with data that can be parsed by a receiving computing device. In some cases, the sending device 216 may include one or more modules for superimposing, encoding, or otherwise formatting the data into a data signal suitable for transmission.

[0075] The sending device 216 can be configured to electronically send data signals to other nodes in the permissioned blockchain network, such as the audit nodes 104a, 104b, 104c, and 104d, the consensus nodes 106a, 106b, 106c, and 106d, application or member nodes, and the like. The data signals electronically sent by the sending device 216 can be superimposed on or otherwise encoded with data messages used to perform the functions of the audit node 102 discussed herein (e.g., proposal messages, prepare messages, prepare response messages, accept messages, confirm messages, resume messages, and resume response messages). The sending device 216 can also be configured to electronically send the data messages superimposed on or otherwise encoded with other data that can be used to perform the functions of the audit node 102 (e.g., hash algorithms, Bloom filter specifications, public keys, and the like).

[0076] The audit node 102 may also include a memory 222. The memory 222 may be configured to store data used by the audit node 102 to perform the functions discussed herein. The memory 222 may be configured to store data using a suitable data formatting method and pattern, and may be any suitable type of memory, such as a read-only memory, a random access memory, and the like. For example, the memory 222 may include a list of unconfirmed transactions, consensus delay times, consensus maps, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications of processing devices, and other data that may be suitable for use by the audit node in performing the functions disclosed herein, which will be apparent to those skilled in the relevant art. In some embodiments, the memory 222 may include or be composed of a relational database that utilizes a structured query language to store, identify, modify, update, access, and the like structured data sets stored therein.

[0077] Consensus Proposal

[0078] Figure 3 shows the Figure 1 The process 300 for consensus proposals in valid consensus for new transactions in a permissioned blockchain network is shown and discussed above.

[0079] At step 302, audit node 102 may wait to receive a transaction message from an application or member node, consensus nodes 106a, 106b, 106c, and 106d, or other nodes in the permissioned blockchain network configured to submit transactions for inclusion in the permissioned blockchain. At step 304, audit node 102 may identify whether a new transaction message has been received. A new transaction message may be one whose included transaction value and / or corresponding transaction reference value is not already included in the list of unconfirmed transactions. If time slots are available, the transaction message is considered new if the corresponding transaction reference value is not included in the list of unconfirmed transaction reference values ​​corresponding to the time slot.

[0080] If a new transaction message is received, then in step 306, the hash module 212 of the audit node 102 can generate a transaction reference value for the transaction (if applicable), and the query module 210 of the audit node 102 can perform a query to store the transaction reference value in a list of unconfirmed transactions corresponding to the corresponding time slot and store the transaction value for later inclusion in a block. In step 308, the sending device 216 of the audit node 102 can rebroadcast the transaction message to each of its neighboring consensus nodes 106a, 106b, 106c, and 106d. Once the transaction message has been rebroadcasted, or directly after determining in step 304 that the transaction message is not new (e.g., and therefore no longer stored and rebroadcasted), then, in step 310, the audit node 102 can determine whether the consensus delay time has expired. This determination is based on the consensus delay time (e.g., which can be stored in the memory 222 of the audit node 102) and the timestamp. The timestamp may be generated by the generation module 214 , and may be the timestamp of the first receipt of a transaction message for a time slot, the timestamp of the receipt of the latest transaction message to be received for the time slot, or other suitable times.

[0081] If the consensus delay time has not expired, process 300 may return to step 302, where audit node 102 may continue to wait to receive new transaction messages until the consensus delay time has expired. When the consensus delay time expires, then, at step 312, hash module 212 of audit node 102 may generate a Merkle root of a list of unconfirmed transactions, which may include only those unconfirmed transactions associated with a particular time slot, if applicable. The Merkle root may be generated by hashing the paired transaction reference values ​​and then hashing the hash results until the root node of the corresponding Merkle tree is identified. In some instances, data identification module 218 of audit node 102 may identify the order of the list of unconfirmed transactions before generating the Merkle root, which may be a natural order of the transaction reference values, for example, an increasing numerical order.

[0082] At step 314, the generation module 214 of the audit node 102 may generate a proposal message, which may be electronically sent by the sending device 216 of the audit node 102 to each neighboring consensus node 106a, 106b, 106c, and 106d (e.g., including any neighboring audit nodes 104a, 104b, 104c, and 104d that perform the functions of consensus nodes 106a, 106b, 106c, and 106d). The proposal message may include the generated Merkle root and, if applicable, the slot identifier of the associated slot. At step 316, the receiving device 202 of the audit node 102 may receive multiple proposal messages from each neighboring consensus node 106a, 106b, 106c, and 106d, each of which may include the same slot identifier and, if applicable, the Merkle root generated by each consensus node 106a, 106b, 106c, and 106d from its own list of unconfirmed transactions.

[0083] At step 318, the verification module 220 of the audit node 102 may perform a verification to determine whether the Merkle root generated by the generation module 214 matches a majority of the Merkle roots included in the proposal messages received from the neighboring consensus nodes 106a, 106b, 106c, and 106d. If so, the process 300 may be completed, thereby completing the consensus proposal process for the audit node 102. If not, the audit node 102 is desynchronized and the following steps, discussed in more detail below, may be entered. Figure 4A , the recovery process shown in 4B and 5 is to resynchronize.

[0084] Node desynchronization recovery

[0085] Figure 4A and 4B A process for recovering an out-of-sync audit node 102 or other node in a permissioned blockchain network is shown, for example, in Figure 3 Asynchrony is identified in step 318 of process 300 shown in FIG and discussed above.

[0086] At step 402, audit node 102 and neighboring consensus nodes 106a, 106b, 106c, and 106d each receive a transaction message for a transaction to be added to the permissioned blockchain. Each transaction message may include a slot identifier and a transaction value, where, if applicable, the hash module 212 of the corresponding node may generate a transaction reference value based on the transaction value, where the transaction reference value is stored in a list of unconfirmed transactions for the corresponding slot. At step 404, the hash module 212 of each corresponding node uses the list of unconfirmed transactions to generate a Merkle root. In some instances, both nodes may sort the list of unconfirmed transactions before generating the Merkle root.

[0087] At step 406, the audit node 102 and the neighboring consensus nodes 106a, 106b, 106c, and 106d may exchange proposal messages, where each proposal message may include a slot identifier and a Merkle root generated by the corresponding node. At step 408, the verification module 220 of the audit node 102 may detect that the Merkle root generated by the hash module 212 of the audit node 102 is incorrect because the Merkle root generated by the hash module 212 of the audit node 102 does not match the Merkle roots generated by the neighboring consensus nodes 106a, 106b, 106c, and 106d or the majority of the consensus nodes 106a, 106b, 106c, and 106d that are neighboring the audit node 102 providing the proposal message. Therefore, the lack of a match may indicate that the audit node 102 is missing at least one transaction reference value in its list of unconfirmed transactions, or that the list of unconfirmed transactions includes additional transaction reference values ​​that should not be in the list.

[0088] At step 410, the generation module 214 of the audit node 102 may generate a Bloom filter using the list of unconfirmed transactions. The size of the Bloom filter is at least twice the number of unconfirmed transactions in the list for the time slot, and the Bloom filter hash cycle may be generated using one or more hashing algorithms using a predetermined number of hash cycles. At step 412, the generation module 214 may generate a recovery message that includes at least the time slot identifier, the generated Bloom filter, the size of the Bloom filter, the number of hash cycles used in generating the Bloom filter, and the number of unconfirmed transactions in the list of unconfirmed transactions for the node for the time slot. The recovery message may then be electronically sent to the neighboring consensus nodes 106a, 106b, 106c, and 106d via the sending device 216 of the audit node 102. At step 414, the receiving device of the consensus node may receive the recovery message.

[0089] At step 416, consensus nodes 106a, 106b, 106c, and 106d may determine whether a transaction is missing from the node's list of unconfirmed transactions, or whether the node's list includes additional unconfirmed transactions. This determination may be made based on a comparison of the number of unconfirmed transactions included in the recovery message with the number of unconfirmed transactions in the consensus node's own list for the time slot. If consensus nodes 106a, 106b, 106c, and 106d determine that audit node 102 is missing a transaction, consensus nodes 106a, 106b, 106c, and 106d may identify transaction reference values ​​not included in the node's list by applying the transaction reference values ​​in the consensus node's list to the Bloom filter included in the recovery message. Transaction messages whose reference values ​​are not included in the Bloom filter may be included in the recovery response message generated by consensus nodes 106a, 106b, 106c, and 106d. If consensus nodes 106a, 106b, 106c, and 106d determine that audit node 102 has additional transactions, consensus nodes 106a, 106b, 106c, and 106d may use their own lists of unconfirmed transactions to generate their own Bloom filters, which may use the same specifications as the Bloom filters included in the recovery message, or may be different specifications. Consensus nodes 106a, 106b, 106c, and 106d may then generate a recovery response message that includes the new Bloom filter and its specifications.

[0090] At step 418, consensus nodes 106a, 106b, 106c, and 106d may electronically send a recovery response message to audit node 102. At step 420, receiving device 202 of audit node 102 may receive the recovery response message, which may include a time slot identifier and additional transaction message or Bloom filter and specification, if applicable. At step 422, audit node 102 may update its list of unconfirmed transactions accordingly. As discussed in more detail below, audit node 102 may add the transaction reference value of the newly received transaction message to its list of unconfirmed transactions, or may use the Bloom filter provided by consensus nodes 106a, 106b, 106c, and 106d to identify the transaction reference value to remove it from the list of unconfirmed transactions. At step 424, the verification module 220 of the audit node 102 may verify the updated list of unconfirmed transactions by checking the new Merkle root of the unconfirmed transactions generated by the hash module 212 of the audit node 102 with the Merkle roots received from the neighboring consensus nodes 106a, 106b, 106c, and 106d and other neighboring nodes. In the event that the verification may not be successful, the audit node 102 may repeat the process starting from step 410 to further recover its list of unconfirmed transactions.

[0091] Figure 5A process 500 is shown for recovering a desynchronized list of unconfirmed transactions in an audit node 102. For example, the process 500 may be performed in Figure 4A and 4B The process shown and discussed above occurs.

[0092] At step 502, the generation module 214 may generate a Bloom filter from a list of unconfirmed transactions corresponding to a given time slot identifier, which has been determined by the audit node 102 to be out of sync with other consensus nodes 106a, 106b, 106c, and 106d in the permissioned blockchain network. The size of the Bloom filter is at least twice the count of unconfirmed transactions in the list and may be generated by performing a predetermined number of hash cycles using one or more hashing algorithms on the transaction reference values ​​in the list of unconfirmed transactions. The generation module 214 may generate a recovery message that includes the time slot identifier, the Bloom filter, the size of the Bloom filter, the count of unconfirmed transactions in the list of nodes corresponding to the time slot, and the number of hash cycles. If applicable, the recovery message may also include information about the one or more hashing algorithms used in the hashing cycles.

[0093] At step 504, the sending device 216 of the audit node 102 may electronically send the generated recovery message to the neighboring consensus nodes 106a, 106b, 106c, and 106d that provided the correct Merkle root in their proposal message, which may be determined by the Merkle root included in each proposal message. At step 506, the receiving device 202 of the audit node 102 receives a recovery response message from the neighboring consensus nodes 106a, 106b, 106c, and 106d in response to the recovery message. The recovery message may include at least a time slot identifier and additional data. At step 508, the data identification module 218 may identify the type of additional data included in the recovery response message.

[0094] If the recovery response message includes a transaction message, process 500 may proceed to step 510, where a list of unconfirmed transactions for the time slot may be updated based on the transaction message. The hash module 212 of the audit node 102 may generate a transaction reference value for each transaction message by applying one or more hashing algorithms to the transaction value included in each transaction message, and the query module 210 of the audit node 102 may perform a first query on the transaction database 206 to store the transaction message 208 in a data storage associated with the time slot, and perform a second query on the memory 222 or other suitable data storage to add the transaction reference value to the list of unconfirmed transactions.

[0095] If the recovery response message includes a Bloom filter, process 500 may proceed to step 512. At step 512, data identification module 218 or other suitable module or engine of audit node 102 may apply the transaction reference values ​​in its list of unconfirmed transactions to the Bloom filter included in the recovery response message, recording the size of the provided Bloom filter and the number of hash cycles, thereby identifying transaction reference values ​​that are not included in the Bloom filter (e.g., and therefore not included in the consensus node's list of unconfirmed transactions), i.e., incorrect transaction reference values. At step 514, query module 210 of audit node 102 may perform a query on transaction database 206 and other memory 222 of audit node 102 to remove the identified incorrect transaction reference values ​​from the list of unconfirmed transactions and their corresponding transaction messages 208.

[0096] Once the audit node 102 has completed removing or adding transaction reference values ​​and transaction messages based on the recovery response message, at step 516, the hashing module 212 of the audit node 102 may use the updated list of unconfirmed transactions to generate a new Merkle root for the time slot. Where the generation of the Merkle root includes ordering the transaction reference values, the data identification module 218 may update the order of the updated list of transaction reference values ​​to accommodate any changes necessary to add or remove transaction reference values. At step 518, the verification module 220 of the audit node 102 may determine whether the new Merkle root is correct. This determination may be made based on an evaluation of the new Merkle root when compared to the Merkle roots included in proposal messages from neighboring consensus nodes 106a, 106b, 106c, and 106d and / or other neighboring consensus nodes participating in the recovery. If the new Merkle root is correct, process 500 is complete and the audit node 102 is back in sync. If the new Merkle root is incorrect, process 500 may return to step 502 and repeat the above process for the updated list of transaction reference values. In such an instance, process 500 may continue to repeat until the audit node 102 generates the correct Merkle root and is thus back in sync with the permissioned blockchain network.

[0097] Consensus Audit

[0098] Figure 6 A process 600 is shown for performing consensus auditing in a consensus mechanism of a permissioned blockchain network for consensus on new transactions added to the permissioned blockchain.

[0099] At step 602, the generation module 214 of the audit node 102 generates a temporary block header for a potential new block to be added to the permissioned blockchain for a particular set of unconfirmed transactions (e.g., transactions associated with a particular time slot). The temporary block header may include at least a hash value of the header of the most recently added block to the permissioned blockchain and a Merkle root generated for the list of unconfirmed transactions. In some instances, the temporary block header may also include a time slot identifier, a public key associated with the audit node 102, a random number, a version identifier, or other data to be included in the final header for the new block.

[0100] At step 604, the hash module 212 of the audit node 102 may generate a hash block of the temporary block header by applying one or more predetermined hash algorithms to the temporary block header. At step 606, the generation module 214 of the audit node 102 may generate a digital signature as a proposal number for the consensus audit. The digital signature may be generated based on the block hash and may be generated using a public key associated with the audit node 102. If a public key is used, it may be the same public key included in the temporary block header before the hash block was generated.

[0101] At step 608, the generation module 214 of the audit node 102 may generate a prepare message, which the sending device 216 of the audit node 102 may electronically send to the other audit nodes 104a, 104b, 104c, and 104d in the permissioned blockchain network. The prepare message may include at least the block hash and the proposal number, and, if applicable, may also include the public key used to generate the proposal number, the time slot identifier, and the nonce included in the temporary block header. At step 610, the receiving device 202 of the audit node 102 may receive prepare response messages from the other audit nodes 104a, 104b, 104c, and 104d in the permissioned blockchain network. If a prepare response message is received, the prepare response message may include the time slot identifier and the proposal number provided by the audit node 102 that is higher than the audit node's own proposal number, and, if applicable, may also include data associated with a previously accepted proposal, such as the accepted proposal number, block hash, public key, and nonce.

[0102] At step 612, the data identification module 218 of the audit node 102 may determine whether a certain number of audit nodes 104a, 104b, 104c, and 104d in the permissioned blockchain network have responded to the node's prepare message with prepare response messages. If the certain number of audit nodes have responded with prepare response messages, then at step 614, the generation module 214 of the audit node 102 may generate an acceptance message. The acceptance message may include the same data included in the node's prepare message, but the data is formatted or otherwise identified as an acceptance message. At step 616, the sending device 216 of the audit node 102 may electronically send the acceptance message to the other audit nodes 104a, 104b, 104c, and 104d in the permissioned blockchain network.

[0103] If, at step 612, audit node 102 determines that the determined number of audit nodes 104a, 104b, 104c, and 104d have not responded with a prepare response message, then, at step 618, receiving device 202 of audit node 102 may wait to receive an accept message from another audit node 104a, 104b, 104c, and 104d. In this case, audit node 102 will not have generated the highest proposal number and will wait for audit nodes 104a, 104b, 104c, and 104d to recognize it. In this case, process 600 may also include receiving a prepare message from another audit node 104a, 104b, 104c, and 104d including a higher proposal number, and responding to it by audit node 102 with its own prepare response message acknowledging the higher proposal number. In this case, accept messages will be received from audit nodes 104a, 104b, 104c, and 104d to which audit node 102 has sent prepare response messages.

[0104] Once the acceptance message has been generated and distributed by the audit node 102 or received by the audit node 102, the generation module 214 of the audit node 102 may generate a confirmation message at step 620. The confirmation message may be part of the consensus confirmation in the permissioned blockchain network and may include at least the slot identifier corresponding to the slot being confirmed, the block hash, a digital signature generated using the public key for the highest proposal number (if applicable), and the random number included in the acceptance message (if applicable). At step 622, the sending device 216 of the audit node 102 may electronically send the confirmation message to each of its neighboring consensus nodes 106a, 106b, 106c, and 106d, which may in turn rebroadcast the confirmation message to its own neighboring consensus nodes 106a, 106b, 106c, and 106d to propagate the confirmation message throughout the permissioned blockchain network.

[0105] Consensus confirmation

[0106] Figure 7 The process 700 of consensus validation as performed by an audit node 102 or another consensus node 106a, 106b, 106c, and 106d in a permissioned blockchain network is shown for confirming that consensus has been reached and subsequently writing the associated new block to the permissioned blockchain.

[0107] At step 702, the receiving device 202 of the audit node 102 may receive the confirmation message. In the case where the audit node 102 may be audit nodes 104a, 104b, 104c, and 104d, the confirmation message may be received within the audit node 102 as generated by the generating module 214 (e.g., Figure 6 6 and discussed above). The confirmation message may include at least a slot identifier associated with the slot being confirmed, a block hash of the temporary block header of the final new block, a digital signature, a public key used to generate the digital signature, and a random number (if applicable).

[0108] At step 704, the generation module 214 of the audit node 102 may generate a block header for the new block. The block header may include the same data as included in the temporary block header that was hashed to generate the hash block included in the confirmation message, except for the signature and block hash, and except for the Merkle root generated by the audit node 102 during the consensus proposal, which may be the same data included in the confirmation message. At step 706, the hash module 212 may generate a hash value by applying one or more hashing algorithms used to generate the hash block to the generated block header.

[0109] At step 708, the verification module 220 of the audit node 102 may verify the confirmation message. The confirmation message may be verified based on a comparison of the hash value of the block header generated by the audit node 102 at step 706 with the block hash included in the confirmation message. If the hash value does not match the hashed block, the verification is unsuccessful and the consensus confirmation ends, as this indicates that the audit node is using an incorrect Merkle root and is out of sync, that the audit node 102 itself is out of sync and has an incorrect Merkle root, or that the data included in the confirmation message or the audit node 102 has been compromised. If the hash value matches the block hash, verification is successful, and at step 710, the query module 210 of the audit node 102 may execute a query to write a new block corresponding to the time slot to the permissioned blockchain. The new block may include the transaction value and a block header for each unconfirmed transaction associated with the time slot. The block header may be the block header generated at step 704 and also include a digital signature.

[0110] Example Methods for Adding Blocks to a Permissioned Blockchain

[0111] Figure 8 A method 800 is shown of adding a block to a permissioned blockchain after using an efficient consensus mechanism for consensus on the block.

[0112] At step 802, a blockchain consisting of a plurality of blocks is stored in a memory (e.g., memory 222) of a processing server (e.g., audit node 102), wherein the plurality of blocks includes a most recently added block, the most recently added block including at least a block header and one or more transaction values. At step 804, a receiving device (e.g., receiving device 202) of the processing server may receive a plurality of transaction messages from one or more consensus nodes (e.g., consensus nodes 106a, 106b, 106c, and 106d) associated with the blockchain, wherein each transaction message includes at least a transaction value. At step 806, a hash module (e.g., hash module 212) of the processing server may generate a Merkle root of the plurality of transaction messages using a transaction reference value associated with the transaction value included in each of the plurality of transaction messages.

[0113] At step 808, the hash module of the processing server may generate a previous hash value by applying a hash algorithm to the block header included in the most recently added block. At step 810, the generation module of the processing server (e.g., generation module 214) may generate a proposed block header, wherein the proposed block header includes at least the previous hash value and the generated Merkle root. At step 812, the hash module of the processing server may generate a confirmation hash value by applying a hash algorithm to the generated proposed block header.

[0114] At step 814, a proposal number may be generated by a generation module of the processing server, wherein the proposal number is a numerical value of a digital signature generated for the block header of the generated proposal. At step 816, a sending device of the processing server (e.g., sending device 216) may electronically send a prepare message to a plurality of audit nodes associated with the blockchain (e.g., audit nodes 104a, 104b, 104c, and 104d), wherein the prepare message includes at least the generated confirmation hash value and the generated proposal number. At step 818, a receiving device of the processing server may receive response messages from at least a majority of the plurality of audit nodes, wherein each prepare response message includes at least the generated confirmation hash value and the accepted proposal number.

[0115] At step 820, a data identification module (e.g., data identification module 218) of the processing server may identify the agreed proposal number based on the value of the generated proposal number and the value of the accepted proposal number included in each response message, as well as predetermined criteria. At step 822, a sending device of the processing server may electronically send an acceptance message to a plurality of audit nodes, wherein the acceptance message includes at least the generated confirmation hash value and the identified agreed proposal number. At step 824, a sending device of the processing server may electronically send a confirmation message to a plurality of consensus nodes associated with the blockchain, wherein the confirmation message includes at least the generated confirmation hash value and the identified agreed proposal number. At step 826, a query module (e.g., query module 210) may 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 and a new block header, wherein the new block header includes at least the previous hash value, the generated Merkle root, and the agreed proposal number.

[0116] In one embodiment, each of the plurality of transaction messages may further include a specific time slot identifier, a proposed block header, a prepare message, a response message, an accept message, and a confirmation message, and each new block header may include a specific time slot identifier, and the block header included in the most recently added block may include a different time slot identifier. In some embodiments, the transaction reference value associated with the transaction value included in each of the plurality of transaction messages may be the transaction value. In one embodiment, method 800 may further include: generating, by a hash module of the processing server, a transaction reference value associated with the transaction value included in each of the plurality of transaction messages by hashing the corresponding transaction value using a predetermined hash algorithm.

[0117] In some embodiments, method 800 may further include storing a consensus delay time in a memory of the processing server, wherein each of the plurality of transaction messages further includes a common identification value associated with a time, and generating the Merkle root after expiration of the consensus delay time following the time associated with the common identification value. In one embodiment, method 800 may further include, by a query module of the processing server, sorting the transaction reference values ​​associated with the transaction values ​​included in each of the plurality of transaction messages based on a natural ordering before generating the Merkle root. In some embodiments, method 800 may further include, by a sending device of the processing server, electronically sending a proposal message to the plurality of consensus nodes, wherein the proposal message includes at least the generated Merkle root.

[0118] In one embodiment, method 800 may further include: receiving, by a 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 (e.g., verification module 220) of the processing server, that the generated Merkle root is equal to at least most of the proposed Merkle roots included in the received proposal message. In some embodiments, a combination of a random number and a digital signature may be used to further generate the proposal number, the prepare message may further include the random number, each response message may further include an associated random number, and each of the accept message, the confirmation message, and the new block header may further include a random number associated with the agreed proposal number.

[0119] In one embodiment, method 800 may further include storing a public key associated with the processing server in a memory, wherein the digital signature is generated for the proposed block header using the public key, the prepare message also includes the public key, each response message also includes the associated public key used in generating the associated accepted proposal number, and the accept message, confirmation message, and new block header also include the public key associated with the agreed proposal number. In some embodiments, method 800 may further include: sorting, by a query module of the processing server, the generated proposal numbers and the accepted proposal numbers included in each response message based on corresponding numerical values, wherein the agreed proposal number is identified based on the sorting and a predetermined criterion. In another embodiment, the predetermined criterion may be selecting the highest numerical value.

[0120] First Exemplary Method for Recovering Lost or Extra Data Using Bloom Filters

[0121] Figure 9 A method 900 for recovering lost unconfirmed transactions in nodes of an unsynchronized permissioned blockchain network is shown.

[0122] At step 902, a plurality of transaction messages (e.g., transaction message 208) may be stored in a transaction database (e.g., transaction database 206) of a processing server (e.g., audit node 102), wherein each transaction message includes a structured data set associated with a blockchain transaction including at least a transaction value. At step 904, a Bloom filter for the plurality of transaction messages may be generated by a generation module (e.g., generation module 214) of the processing server, wherein the Bloom filter is generated using a predetermined number of hash cycles and a size of the Bloom filter is at least twice the count of the plurality of transaction messages stored in the transaction database.

[0123] At step 906, a recovery message may be generated by a generation module of the processing server, wherein the recovery message includes at least a count of the plurality of transaction messages, a predetermined number of hash cycles, the size, and the generated Bloom filter. At step 908, a sending device of the processing server (e.g., sending device 216) may electronically send the generated recovery message to at least one consensus node (e.g., consensus nodes 106a, 106b, 106c, and 106d).

[0124] At step 910, a receiving device of the processing server (e.g., receiving device 202) may receive a response message from one or more of the at least one consensus node, wherein the response message includes at least one additional transaction message. At step 912, a query module of the processing server (e.g., query module 210) may execute a query on the transaction database to insert the at least one additional transaction message.

[0125] In one embodiment, method 900 may further include: generating, by a hash module (e.g., hash module 212) of the processing server, a Merkle root for the plurality of transaction messages using a transaction reference value associated with a transaction value included in each of the plurality of transaction messages; receiving, by a receiving device of the processing server, a proposal message from each of the at least one consensus node, wherein the proposal message includes at least the proposed Merkle root; and, before electronically transmitting the generated recovery message, verifying, by a verification module (e.g., verification module 220) of the processing server, that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message. In another embodiment, method 900 may further include: generating, by the hash module of the processing server, a new Merkle root for the plurality of transaction messages and the at least one additional transaction message using a transaction reference value associated with a transaction value included in each corresponding transaction message; and verifying, by the verification module of the processing server, that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

[0126] In another embodiment, method 900 may further include: generating, by a hash module of the processing server, a transaction reference value associated with the transaction value included in each of the plurality of transaction messages by hashing the corresponding transaction value using a predetermined hash algorithm. In yet another embodiment, method 900 may further include: sorting, by a query module of the processing server, the transaction reference values ​​associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering before generating the Merkle root.

[0127] In some embodiments, each of the plurality of transaction messages may further include a specific time slot identifier, each of the recovery message and the response message may further include the specific time slot identifier, and each of the at least one additional transaction message may include the specific time slot identifier. In one embodiment, a Bloom filter may be generated using a predetermined hash algorithm for each of the predetermined number of hash cycles.

[0128] Second Exemplary Method for Recovering Lost or Extra Data Using Bloom Filters

[0129] Figure 10 A method 1000 is shown for recovering extra data included in unconfirmed transactions by removing them in a node using a Bloom filter so that the unconfirmed transactions are added to a permissioned blockchain.

[0130] At step 1002, a plurality of transaction messages (e.g., transaction message 208) may be stored in a transaction database (e.g., transaction database 206) of a processing server (e.g., audit node 102), wherein each transaction message includes a structured data set including at least one transaction value associated with a blockchain transaction. At step 1004, a Bloom filter for the plurality of transaction messages may be generated by a generation module (e.g., generation module 214) of the processing server, wherein the Bloom filter is generated using a predetermined number of hash cycles and a size of the Bloom filter is at least twice the count of the plurality of transaction messages stored in the transaction database.

[0131] At step 1006, a recovery message may be generated by a generation module of the processing server, wherein the recovery message includes at least a count of the plurality of transaction messages, a predetermined number of hash cycles, the size, and the generated Bloom filter. At step 1008, a sending device of the processing server (e.g., sending device 216) may electronically send the generated recovery message to at least one consensus node (e.g., consensus nodes 106a, 106b, 106c, and 106d).

[0132] In step 1010, a response message can be received by a receiving device of the processing server (e.g., receiving device 202) from one or more of the at least one consensus node, wherein the response message includes at least the second Bloom filter, the indicated number of hash cycles, the indicated filter size, and the expected number of transaction messages. In step 1012, a data identification module of the processing server (e.g., data identification module 218) can identify at least one transaction message from the plurality of transaction messages not included in the second Bloom filter based on the included transaction value, the indicated number of hash cycles, the indicated filter size, the expected number of transaction messages, and the second Bloom filter. In step 1014, a query module of the processing server (e.g., query module 210) can perform a query on the transaction database to delete the at least one identified transaction message.

[0133] In one embodiment, the number of expected transaction messages may be less than the count of the plurality of transaction messages. In some embodiments, the indicated filter size may be at least twice the number of expected transaction messages. In one embodiment, the count of the plurality of transaction messages updated after executing the query may be equal to the number of expected transaction messages. In some embodiments, each of the plurality of transaction messages may further include a specific time slot identifier, and each of the recovery message and the response message may further include the specific time slot identifier. In one embodiment, a Bloom filter may be generated using a predetermined hashing algorithm for each of a predetermined number of hash cycles.

[0134] In one embodiment, method 1000 may further include: generating, by a hash module (e.g., hash module 212) of the processing server, a Merkle root for the plurality of transaction messages using a transaction reference value associated with a transaction value included in each of the plurality of transaction messages; receiving, by a receiving device of the processing server, a proposal message from each of the at least one consensus node, wherein the proposal message includes at least the proposed Merkle root; and, before electronically transmitting the generated recovery message, verifying, by a verification module (e.g., verification module 220) of the processing server, that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message. In another embodiment, method 1000 may further include: generating, by the hash module of the processing server, a new Merkle root for the plurality of transaction messages after deleting the at least one identified transaction message using the transaction reference value associated with the transaction value included in each corresponding transaction message; and verifying, by the verification module of the processing server, that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

[0135] In another embodiment, method 1000 may further include: generating, by a hash module of the processing server, a transaction reference value associated with the transaction value included in each of the plurality of transaction messages by hashing the corresponding transaction value using a predetermined hash algorithm. In yet another embodiment, method 1000 may further include: sorting, by a query module of the processing server, the transaction reference values ​​associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering before generating the Merkle root.

[0136] Computer system architecture

[0137] Figure 11 A computer system 1100 is shown in which embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code. For example, hardware, software, firmware, a non-transitory computer-readable medium having instructions stored thereon, or a combination thereof may be used to implement the present disclosure in the computer system 1100. Figure 1 Audit node 102, and Figure 1 The audit node 102 may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof may be implemented as a Figure 3 , modules and components of the methods of 4A, 4B and 5-10.

[0138] If programmable logic is used, such logic can be executed on a commercially available processing platform configured by executable software code into a special-purpose computer or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit, etc.). One of ordinary skill in the art will appreciate that various computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, linked or aggregated computers with distributed functionality, and ordinary or microcomputers that can be embedded in almost any device, can be used to practice the embodiments of the disclosed subject matter. For example, the above-described embodiments can be implemented using at least one processor device and memory.

[0139] As discussed herein, a processor unit or device may be a single processor, a plurality of processors, or a combination thereof. A processor device may have one or more processor "cores." As discussed herein, the terms "computer program medium," "non-transitory computer-readable medium," and "computer-usable medium" are generally used to refer to tangible media, such as removable storage unit 1118, removable storage unit 1122, and a hard disk installed in hard disk drive 1112.

[0140] Various embodiments of the present disclosure are described using this exemplary computer system 1100. After reading this specification, it will be apparent to those skilled in the relevant art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations are described as sequential processes, some operations can in fact be performed in parallel, simultaneously, and / or in a distributed environment, and program code can be stored locally or remotely for access by single or multi-processor machines. In addition, in some embodiments, the order of the various operations can be rearranged without departing from the spirit of the disclosed subject matter.

[0141] Processor device 1104 can be a dedicated or general purpose processor device configured to perform the functions disclosed herein. Processor device 804 can be connected to communication infrastructure 1106, for example, a bus, a message queue, a network, a multi-core message transmission scheme, etc. The network can be any network suitable for performing the functions disclosed herein, which may include a local area network (LAN), a wide area network (WAN), a wireless network (such as WiFi), a mobile communication network, a satellite network, the Internet, an optical fiber, a coaxial cable, infrared rays, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. Computer system 1100 may also include a main memory 1108 (for example, a random access memory, a read-only memory, etc.), and may also include a secondary memory 1110. The secondary memory 1110 may include a hard disk drive 1112 and a removable storage drive 1114, for example, a floppy disk drive, a tape drive, an optical disk drive, a flash memory, etc.

[0142] Removable storage drive 1114 can read from and / or write to removable storage unit 1118 in a well-known manner. Removable storage unit 1118 may include removable storage media that can be read from and written to by removable storage drive 1114. For example, if removable storage drive 1114 is a floppy disk drive or a universal serial bus port, removable storage unit 1118 may be a floppy disk or a portable flash drive, respectively. In one embodiment, removable storage unit 1118 may be a non-transitory computer-readable recording medium.

[0143] In some embodiments, secondary memory 1110 may include additional means for allowing computer programs or other instructions to be loaded into computer system 1100, such as a removable storage unit 1122 and interface 1120. Examples of such means may include a program cartridge and cartridge interface (e.g., as found in video game systems), a removable memory chip (e.g., EEPROM, PROM, etc.) and associated socket, and other removable storage units 1122 and interfaces 1120, as will be apparent to those skilled in the art.

[0144] The data stored in the computer system 1100 (e.g., stored in the main memory 1108 and / or the secondary memory 1110) can be stored on any type of suitable computer-readable medium, such as optical storage (e.g., compact disks, digital versatile disks, Blu-ray disks, etc.) or magnetic tape storage (e.g., hard drives). The data can be configured in any type of suitable database configuration (e.g., a relational database, a structured query language (SQL) database, a distributed database, an object database, etc.). Suitable configurations and storage types will be apparent to those skilled in the art.

[0145] The computer system 1100 may also include a communication interface 1124. The communication interface 1124 may be configured to allow software and data to be transmitted between the computer system 1100 and external devices. Exemplary communication interfaces 1124 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transmitted via the communication interface 1124 may be in the form of a signal, which may be electronic, electromagnetic, optical or other signal, as will be apparent to those skilled in the relevant art. The signal may travel via a communication path 1126, which may be configured to carry the signal and may be implemented using wires, cables, optical fibers, telephone lines, cellular phone links, radio frequency links, etc.

[0146] The computer system 1100 may also include a display interface 1102. The display interface 1102 may be configured to allow data to be transferred between the computer system 1100 and an external display 1130. Exemplary display interfaces 1102 may include a High-Definition Multimedia Interface (HDMI), a Digital Video Interface (DVI), a Video Graphics Array (VGA), and the like. The display 1130 may be any suitable type of display for displaying data sent via the display interface 1102 of the computer system 1100, including cathode ray tube (CRT) displays, liquid crystal displays (LCDs), light emitting diode (LED) displays, capacitive touch displays, thin film transistor (TFT) displays, and the like.

[0147] Computer program media and computer usable media may refer to memories, such as main memory 1108 and secondary memory 1110, which may be memory semiconductors (e.g., DRAM, etc.). These computer program products may be means for providing software to the computer system 1100. Computer programs (e.g., computer control logic) may be stored in the main memory 1108 and / or the secondary memory 1110. The computer program may also be received via the communication interface 1124. When the computer program is executed, the computer system 1100 may be enabled to implement the present method discussed herein. In particular, when the computer program is executed, the processor device 1104 may be enabled to implement the methods discussed herein. Figure 3 , 4A, 4B and 5-10. Therefore, the computer program may represent a controller of the computer system 1100. Where software is used to implement the present disclosure, the software may be stored in a computer program product and loaded into the computer system 1100 using the removable storage drive 1114, the interface 1120, and the hard disk drive 1112 or the communication interface 1124.

[0148] The processor device 1104 may include one or more modules or engines configured to perform the functions of the computer system 1100. Each module or engine may be implemented using hardware, and in some examples may also be implemented using software (e.g., software corresponding to program code and / or programs stored in the main memory 1108 or the auxiliary memory 1110). In this example, the program code may be compiled by the processor device 1104 (e.g., by a compilation module or engine) before being executed by the hardware of the computer system 1110. For example, the program code may be source code written in a programming language that is compiled into a lower-level language such as assembly language or machine code for execution by the processor device 1104 and / or any additional hardware components of the computer system 1100. The compilation process may include the use of lexical analysis, preprocessing, parsing, semantic analysis, syntax-directed translation, code generation, code optimization, and any other techniques applicable to translating the program code into a lower-level language suitable for controlling the computer system 1100 to perform the functions disclosed herein. Those skilled in the relevant art will appreciate that this process results in the computer system 1100 becoming a specifically configured computer system 1100 that is specifically programmed to perform the functions described above.

[0149] Among other features, technology consistent with the present disclosure provides a system and method for adding blocks to a permissioned blockchain network using an efficient consensus mechanism and for recovering additional or lost data in nodes in the permissioned blockchain network using Bloom filters. Although various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they are provided for purposes of illustration only and not limitation. This is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations may be made in light of the above teachings or may be acquired from practice of the disclosure without departing from the breadth or scope.

Claims

1. A method for recovering lost data or extra data using a Bloom filter, comprising: generating, by a generation module of a processing server, a Bloom filter for a plurality of transaction messages, wherein the plurality of transaction messages are stored in a transaction database, wherein the Bloom filter is generated using a predetermined number of hashing cycles and a size of the Bloom filter is at least twice the number of the plurality of transaction messages, wherein each transaction message includes a structured data set related to a blockchain transaction, the structured data set including at least a transaction value; generating, by the generation module of the processing server, a recovery message, wherein the recovery message includes at least the number of the plurality of transaction messages, the predetermined number of hash cycles, the size, and the generated Bloom filter; electronically sending, by a sending device of the processing server, the generated recovery message to at least one consensus node of a plurality of consensus nodes, wherein each consensus node of the plurality of consensus nodes is configured to receive and provide the transaction for inclusion in a permissioned blockchain; receiving, by a receiving device of the processing server, a response message from the at least one consensus node, wherein the response message includes at least one additional transaction message; and A query is performed on the transaction database by a query module of the processing server to insert the at least one additional transaction message.

2. The method according to claim 1, further comprising: generating, by a hash module of the processing server, a Merkle root of the plurality of transaction messages using a transaction reference value associated with a transaction value included in each of the plurality of transaction messages; Receiving, by the receiving device of the processing server, a proposal message from the at least one consensus node, wherein the proposal message includes at least a proposed Merkle root; as well as Before electronically sending the generated recovery message, the verification module of the processing server verifies that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message.

3. The method according to claim 2, further comprising: generating, by the hashing module of the processing server, a new Merkle root of the plurality of transaction messages and the at least one additional transaction message using a transaction reference value associated with the transaction value included in each respective transaction message; as well as Verifying, by the verification module of the processing server, that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

4. The method according to claim 2, further comprising: The hash module of the processing server generates a transaction reference value associated with the transaction value included in each of the plurality of transaction messages by hashing the transaction value included in each of the plurality of transaction messages using a predetermined hash algorithm.

5. The method according to claim 2, further comprising: The query module of the processing server sorts the transaction reference values ​​associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering before generating the Merkle root.

6. The method according to claim 1, wherein Each transaction message of the plurality of transaction messages further includes a time slot identifier, Each of the recovery message and the response message further includes the time slot identifier, and The at least one additional transaction message includes the time slot identifier.

7. The method according to claim 1, wherein For each of the predetermined number of hash cycles, the Bloom filter is generated using a predetermined hash algorithm.

8. A method for recovering lost data or extra data using a Bloom filter, comprising: generating, by a generation module of a processing server, a Bloom filter for a plurality of transaction messages, wherein the plurality of transaction messages are stored in a transaction database, wherein the Bloom filter is generated using a predetermined number of hashing cycles and a size of the Bloom filter is at least twice the number of the plurality of transaction messages, wherein each transaction message includes a structured data set related to a blockchain transaction, the structured data set including at least a transaction value; generating, by the generation module of the processing server, a recovery message, wherein the recovery message includes at least the number of the plurality of transaction messages, the predetermined number of hash cycles, the size, and the generated Bloom filter; electronically sending, by a sending device of the processing server, the generated recovery message to at least one consensus node of a plurality of consensus nodes, wherein each consensus node of the plurality of consensus nodes is configured to receive and provide the transaction for inclusion in a permissioned blockchain; receiving, by a receiving device of the processing server, a response message from the at least one consensus node, wherein the response message includes at least the second Bloom filter, the indicated number of hash rounds, the indicated filter size, and the number of expected transaction messages; identifying, by a data identification module of the processing server, at least one transaction message of the plurality of transaction messages not included in the second Bloom filter based on the included transaction value, the indicated number of hash cycles, the indicated filter size, the expected number of transaction messages, and the second Bloom filter; and A query is performed by a query module of the processing server on the transaction database to delete the identified at least one transaction message.

9. The method according to claim 8, wherein The number of the expected transaction messages is less than the number of the plurality of transaction messages.

10. The method according to claim 8, wherein The indicated filter size is at least twice the number of the expected transaction messages.

11. The method according to claim 8, wherein The number of updates of the plurality of transaction messages after executing the query is equal to the number of expected transaction messages.

12. The method according to claim 8, further comprising: generating, by a hash module of the processing server, a Merkle root of the plurality of transaction messages using a transaction reference value associated with a transaction value included in each of the plurality of transaction messages; Receiving, by the receiving device of the processing server, a proposal message from the at least one consensus node, wherein the proposal message includes at least a proposed Merkle root; as well as Before electronically sending the generated recovery message, the verification module of the processing server verifies that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message.

13. The method according to claim 12, further comprising: generating, by the hashing module of the processing server, a new Merkle root of the plurality of transaction messages after deleting the identified at least one transaction message using a transaction reference value associated with the transaction value included in each respective transaction message; as well as Verifying, by the verification module of the processing server, that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

14. The method according to claim 12, further comprising: The hash module of the processing server generates a transaction reference value associated with the transaction value included in each of the plurality of transaction messages by hashing the corresponding transaction value using a predetermined hash algorithm.

15. The method according to claim 12, further comprising: The query module of the processing server sorts the transaction reference values ​​associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering before generating the Merkle root.

16. The method according to claim 8, wherein Each transaction message of the plurality of transaction messages further includes a time slot identifier, and Each of the resume message and the response message further includes the time slot identifier.

17. The method according to claim 8, wherein For each of a predetermined number of hashing cycles, the Bloom filter is generated using a predetermined hashing algorithm.

18. A system for recovering lost data or additional data using a Bloom filter, comprising: Processing Server; The generating module of the processing server is configured to generate a Bloom filter for a plurality of transaction messages, wherein the plurality of transaction messages are stored in a transaction database, wherein the Bloom filter is generated using a predetermined number of hashing cycles and a size of the Bloom filter is at least twice the number of the plurality of transaction messages, wherein each transaction message comprises a structured data set associated with a blockchain transaction, the structured data set comprising at least a transaction value; and a recovery message, wherein the recovery message includes at least the number of the plurality of transaction messages, the predetermined number of hash rounds, the size, and the generated Bloom filter; a sending device of the processing server configured to electronically send the generated recovery message to at least one consensus node of a plurality of consensus nodes, wherein each consensus node of the plurality of consensus nodes is configured to receive and provide the transaction for inclusion in a permissioned blockchain; a receiving device of the processing server, configured to receive a response message from the at least one consensus node, wherein the response message includes at least one additional transaction message; and The query module of the processing server is configured to perform a query on the transaction database to insert the at least one additional transaction message.

19. The system of claim 18, further comprising: a verification module of the processing server; and a hash module of the processing server configured to generate a Merkle root of the plurality of transaction messages using a transaction reference value associated with the transaction value included in each of the plurality of transaction messages, wherein The receiving device of the processing server is further configured to receive a proposal message from the at least one consensus node, wherein the proposal message includes at least a proposed Merkle root; and The verification module of the processing server is configured to verify that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message before electronically sending the generated recovery message.

20. The system of claim 19, wherein: The hashing module of the processing server is further configured to generate a new Merkle root of the plurality of transaction messages and the at least one additional transaction message using a transaction reference value associated with the transaction value included in each respective transaction message, and The verification module of the processing server is further configured to verify that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

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

22. The system of claim 19, wherein: The query module of the processing server is further configured to, before generating the Merkle root, sort the transaction reference values ​​associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering.

23. The system of claim 18, wherein: Each transaction message of the plurality of transaction messages further includes a time slot identifier, Each of the recovery message and the response message further includes the time slot identifier, and The at least one additional transaction message includes the time slot identifier.

24. The system of claim 18, wherein: For each of the predetermined number of hash cycles, the Bloom filter is generated using a predetermined hash algorithm.

25. A system for recovering lost data or additional data using a Bloom filter, comprising: Processing Server; The generating module of the processing server is configured to generate a Bloom filter for a plurality of transaction messages, wherein the plurality of transaction messages are stored in a transaction database, wherein the Bloom filter is generated using a predetermined number of hashing cycles and a size of the Bloom filter is at least twice the number of the plurality of transaction messages, wherein each transaction message comprises a structured data set associated with a blockchain transaction, the structured data set comprising at least a transaction value; and a recovery message, wherein the recovery message includes at least the number of the plurality of transaction messages, the predetermined number of hash rounds, the size, and the generated Bloom filter; a sending device of the processing server configured to electronically send the generated recovery message to at least one consensus node of a plurality of consensus nodes, wherein each consensus node of the plurality of consensus nodes is configured to receive and provide the transaction for inclusion in a permissioned blockchain; a receiving device of the processing server configured to receive a response message from one or more of the at least one consensus node, wherein the response message includes at least the second Bloom filter, the indicated number of hash rounds, the indicated filter size, and the expected number of transaction messages; a data identification module of the processing server configured to identify at least one transaction message of the plurality of transaction messages not included in the second Bloom filter based on the included transaction value, the indicated number of hash cycles, the indicated filter size, the expected number of transaction messages, and the second Bloom filter; and A query module of the processing server is configured to perform a query on the transaction database to delete the identified at least one transaction message.

26. The system of claim 25, wherein: The number of the expected transaction messages is less than the number of the plurality of transaction messages.

27. The system of claim 25, wherein: The indicated filter size is at least twice the number of the expected transaction messages.

28. The system of claim 25, wherein: The number of updates of the plurality of transaction messages after executing the query is equal to the number of expected transaction messages.

29. The system of claim 25, further comprising: a verification module of the processing server; and a hash module of the processing server configured to generate a Merkle root of the plurality of transaction messages using a transaction reference value associated with the transaction value included in each of the plurality of transaction messages, wherein The receiving device of the processing server is further configured to receive a proposal message from each of the at least one consensus node, wherein the proposal message includes at least a proposed Merkle root, and The verification module of the processing server is configured to verify that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message before electronically sending the generated recovery message.

30. The system of claim 29, wherein: The hashing module of the processing server is configured to, after deleting the identified at least one transaction message, generate a new Merkle root of the plurality of transaction messages using a transaction reference value associated with the transaction value included in each corresponding transaction message, and The verification module of the processing server is configured to verify that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

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

32. The system of claim 29, wherein: The query module of the processing server is further configured to, before generating the Merkle root, sort the transaction reference values ​​associated with the transaction value included in each of the plurality of transaction messages based on a natural ordering.

33. The system of claim 25, wherein: Each transaction message of the plurality of transaction messages further includes a time slot identifier, and Each of the resume message and the response message further includes the time slot identifier.

34. The system of claim 25, wherein: For each of the predetermined number of hash cycles, the Bloom filter is generated using a predetermined hash algorithm.

35. A method for recovering lost data or extra data using a Bloom filter, comprising: generating, by a processing server, a Bloom filter for a plurality of data messages, wherein the plurality of data messages are stored in a database, wherein the Bloom filter is generated using a predetermined number of hashing cycles and wherein a size of the Bloom filter is at least twice the number of the plurality of data messages; generating, by the processing server, a recovery message, wherein the recovery message includes at least a number of the plurality of data messages, a predetermined number of hash rounds, the size, and the generated Bloom filter; electronically sending, by a sending device of the processing server, the generated recovery message to at least one node; receiving, by a receiving device of the processing server, a response message from the at least one node, wherein the response message includes at least one additional data message; and A query is executed by the processing server on the database to insert the at least one additional data message.

36. The method according to claim 35, further comprising: generating, by the processing server, a Merkle root of the plurality of data messages using a data reference value associated with a data value included in each of the plurality of data messages; receiving, by the receiving device of the processing server, a proposal message from the at least one node, wherein the proposal message includes at least a proposed Merkle root; as well as Prior to electronically sending the generated recovery message, the processing server verifies that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message.

37. The method of claim 36, further comprising: generating, by the processing server, a new Merkle root for the plurality of data messages and the at least one additional data message using a data reference value associated with the data value included in each respective data message; as well as The new Merkle root is verified by the processing server to be equal to the proposed Merkle root included in each received proposal message.

38. The method of claim 36, further comprising: The data reference value associated with the data value included in each of the plurality of data messages is generated by the processing server by hashing the data value included in each of the plurality of data messages using a predetermined hashing algorithm.

39. The method of claim 36, further comprising: The data reference values ​​associated with the data values ​​included in each of the plurality of data messages are sorted based on a natural ordering by the processing server before generating the Merkle root.

40. The method of claim 35, wherein Each of the plurality of data messages further includes a time slot identifier, Each of the recovery message and the response message further includes the time slot identifier, and The at least one additional data message comprises the time slot identifier.

41. The method of claim 35, wherein: For each of the predetermined number of hash cycles, the Bloom filter is generated using a predetermined hash algorithm.

42. A method for recovering lost data or extra data using a Bloom filter, comprising: generating, by a processing server, a Bloom filter for a plurality of data messages, wherein the plurality of data messages are stored in a database, wherein the Bloom filter is generated using a predetermined number of hashing cycles and a size of the Bloom filter is at least twice the number of the plurality of data messages, wherein each data message includes a structured data set related to blockchain data, the structured data set including at least a data value; generating, by the processing server, a recovery message, wherein the recovery message includes at least a number of the plurality of data messages, a predetermined number of hash rounds, the size, and the generated Bloom filter; electronically sending, by a sending device of the processing server, the generated recovery message to at least one node; receiving, by a receiving device of the processing server, a response message from the at least one node, wherein the response message includes at least the second Bloom filter, the indicated number of hash rounds, the indicated filter size, and the number of expected data messages; identifying, by a data identification module of the processing server, at least one data message of the plurality of data messages not included in the second Bloom filter based on the included data value, the indicated number of hash cycles, the indicated filter size, the expected number of data messages, and the second Bloom filter; and A query is performed by the processing server on the database to delete the identified at least one data message.

43. The method according to claim 42, wherein The expected number of data messages is less than the number of the plurality of data messages.

44. The method of claim 42, wherein: The indicated filter size is at least twice the number of the expected data messages.

45. The method of claim 42, wherein The number of updates of the plurality of data messages after performing the query is equal to the number of expected data messages.

46. ​​The method of claim 42, further comprising: generating, by a hash module of the processing server, a Merkle root of the plurality of data messages using a data reference value associated with a data value included in each of the plurality of data messages; receiving, by the receiving device of the processing server, a proposal message from the at least one node, wherein the proposal message includes at least a proposed Merkle root; and Before electronically sending the generated recovery message, the verification module of the processing server verifies that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message.

47. The method of claim 46, further comprising: generating, by the processing server, a new Merkle root of the plurality of data messages using a data reference value associated with the data value included in each respective data message after deleting the at least one identified data message; as well as Verifying, by the verification module of the processing server, that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

48. The method of claim 46, further comprising: A data reference value associated with the data value included in each of the plurality of data messages is generated by the processing server by hashing the corresponding data value using a predetermined hashing algorithm.

49. The method of claim 46, further comprising: The data reference values ​​associated with the data values ​​included in each of the plurality of data messages are sorted based on a natural ordering by the processing server before generating the Merkle root.

50. The method of claim 42, wherein Each of the plurality of data messages further includes a time slot identifier, and Each of the resume message and the response message further includes the time slot identifier.

51. The method of claim 42, wherein: For each of a predetermined number of hashing cycles, the Bloom filter is generated using a predetermined hashing algorithm.

52. A system for recovering lost data or additional data using a Bloom filter, comprising: Processing Server; The processing server is configured to generate a Bloom filter for a plurality of data messages, wherein the plurality of data messages are stored in a database, wherein the Bloom filter is generated using a predetermined number of hash cycles and a size of the Bloom filter is at least twice the number of the plurality of data messages, wherein each data message comprises a structured data set related to blockchain data, the structured data set comprising at least a data value; and a recovery message, wherein the recovery message includes at least the number of the plurality of data messages, the predetermined number of hash rounds, the size, and the generated Bloom filter; a sending device of the processing server configured to electronically send the generated recovery message to at least one node; a receiving device of the processing server configured to receive a response message from the at least one node, wherein the response message includes at least one additional data message; and The processing server is configured to execute a query on the database to insert the at least one additional data message.

53. The system of claim 52, further comprising: a verification module of the processing server; and a hash module of the processing server configured to generate a Merkle root of the plurality of data messages using a data reference value associated with the data value included in each of the plurality of data messages, wherein The receiving device of the processing server is further configured to receive a proposal message from the at least one node, wherein the proposal message includes at least a proposed Merkle root; and The verification module of the processing server is configured to verify that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message before electronically sending the generated recovery message.

54. The system of claim 53, wherein: The processing server is further configured to generate a new Merkle root for the plurality of data messages and the at least one additional data message using a data reference value associated with the data value included in each respective data message, and The verification module of the processing server is further configured to verify that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

55. The system of claim 53, wherein: The processing server is further configured to generate the data reference value associated with the data value included in each of the plurality of data messages by hashing the corresponding data value using a predetermined hashing algorithm.

56. The system of claim 53, wherein: The processing server is further configured to, before generating the Merkle root, order the data reference values ​​associated with the data values ​​included in each of the plurality of data messages based on a natural ordering.

57. The system of claim 52, wherein: Each of the plurality of data messages further includes a time slot identifier, Each of the recovery message and the response message further includes the time slot identifier, and The at least one additional data message comprises the time slot identifier.

58. The system of claim 52, wherein: For each of the predetermined number of hash cycles, the Bloom filter is generated using a predetermined hash algorithm.

59. A system for recovering lost data or additional data using a Bloom filter, comprising: Processing Server; The processing server is configured to generate a Bloom filter for a plurality of data messages, wherein the plurality of data messages are stored in a database, wherein the Bloom filter is generated using a predetermined number of hashing cycles and a size of the Bloom filter is at least twice the number of the plurality of data messages, wherein each data message comprises a structured data set related to blockchain data, the structured data set comprising at least a data value; and a recovery message, wherein the recovery message includes at least the number of the plurality of data messages, the predetermined number of hash rounds, the size, and the generated Bloom filter; a sending device of the processing server configured to electronically send the generated recovery message to at least one node; a receiving device of the processing server configured to receive a response message from one or more of the at least one node, wherein the response message includes at least the second Bloom filter, the indicated number of hash rounds, the indicated filter size, and the expected number of data messages; a data identification module of the processing server configured to identify at least one data message of the plurality of data messages not included in the second Bloom filter based on the included data value, the indicated number of hash cycles, the indicated filter size, the expected number of data messages, and the second Bloom filter; and The processing server is configured to perform a query on the database to delete the identified at least one data message.

60. The system of claim 59, wherein: The expected number of data messages is less than the number of the plurality of data messages.

61. The system of claim 59, wherein: The indicated filter size is at least twice the number of the expected data messages.

62. The system of claim 59, wherein: The number of updates of the plurality of data messages after performing the query is equal to the number of expected data messages.

63. The system of claim 59, further comprising: a verification module of the processing server; and a hash module of the processing server configured to generate a Merkle root of the plurality of data messages using a data reference value associated with the data value included in each of the plurality of data messages, wherein The receiving device of the processing server is further configured to receive a proposal message from each of the at least one node, wherein the proposal message includes at least a proposed Merkle root, and The verification module of the processing server is configured to verify that the generated Merkle root is not equal to the proposed Merkle root included in each received proposal message before electronically sending the generated recovery message.

64. The system of claim 63, wherein: The processing server is configured to, after deleting the identified at least one data message, generate a new Merkle root of the plurality of data messages using a data reference value associated with the data value included in each corresponding data message, and The verification module of the processing server is configured to verify that the new Merkle root is equal to the proposed Merkle root included in each received proposal message.

65. The system of claim 63, wherein: The processing server is further configured to generate the data reference value associated with the data value included in each of the plurality of data messages by hashing the corresponding data value using a predetermined hashing algorithm.

66. The system of claim 63, wherein: The processing server is further configured to, before generating the Merkle root, order the data reference values ​​associated with the data values ​​included in each of the plurality of data messages based on a natural ordering.

67. The system of claim 59, wherein: Each of the plurality of data messages further includes a time slot identifier, and Each of the resume message and the response message further includes the time slot identifier.

68. The system of claim 59, wherein: For each of the predetermined number of hash cycles, the Bloom filter is generated using a predetermined hash algorithm.

Images