Faster view changes for blockchain

Abstract

An exemplary operation comprises one or more of the following steps: receiving view change messages requesting a view change from a previous primary peer of the blockchain to a primary peer; identifying, based on metadata of the received view change messages, that a change to the state of the blockchain is in progress with the previous primary peer; determining, based on a received view data message, whether the change to the state of the blockchain corresponds to the latest change to the blockchain; and transmitting a new view message containing the change in progress to the state of the blockchain to subsequent peers.

Description

Technology Field

[0001] The present invention relates to the field of decentralized storage systems, particularly decentralized storage systems that enable a faster view change to occur when an update to a decentralized storage system is in progress. Background Technology

[0002] A centralized database stores and maintains data in a single database at one location (e.g., a database server). This location is often a central computer, such as a desktop CPU (Central Processing Unit), a server CPU, or a mainframe computer. The problem to be solved Information stored in a centralized database can generally be accessed from multiple different points. Multiple users or client workstations can work simultaneously on the central database, for example, based on a client / server configuration. Centralized databases are easy to manage, maintain, and control, particularly for security purposes, due to their single location. Within a centralized database, data redundancy is minimized because a single storage location for all data also implies that there is only one primary record for a given dataset. means of solving the problem

[0003] One exemplary embodiment provides a device, the device comprising: a network interface configured to receive view change messages requesting a view change from a previous primary peer of a blockchain to a primary peer; and a processor configured to identify, based on metadata of the received view change messages, whether a change to the state of the blockchain is in process with the previous primary peer, and to determine, based on a received view data message, whether the change to the state of the blockchain corresponds to a recent change to the blockchain, the network interface further configured to transmit a new view message containing the in-process change to the state of the blockchain to following peers.

[0004] Another exemplary embodiment provides a device, said device may include a processor configured to perform one or more of the steps of determining that a current primary peer of a blockchain has become a faulty peer, identifying that a change to the state of said blockchain is in progress with said current primary peer, and generating a view change message including a hash of the change in progress to said blockchain state and a next view number, and a network interface configured to transmit said generated view change message to other peers.

[0005] Another exemplary embodiment provides a method, which may include one or more of the steps of: receiving view change messages requesting a view change from a previous primary peer of a blockchain to a primary peer; identifying, based on metadata of the received view change messages, that a change to the state of the blockchain is in process with the previous primary peer; determining, based on a received view data message, whether the change to the state of the blockchain corresponds to the latest change to the blockchain; and transmitting a new view message containing the in-process change to the state of the blockchain to following peers.

[0006] Another exemplary embodiment provides a device, wherein the device may include a network interface configured to receive, from the primary peer, a pre-preparation message containing proposed data to be added to the blockchain, and one or more of a processor configured to perform one or more of the steps of generating a preparation message containing a hash of the proposed data to be added to the blockchain and a signature of a consensus peer, adding a hash puzzle of the consensus peer to the preparation message, and transmitting the preparation message having the hash puzzle to a plurality of other consensus peers of the blockchain.

[0007] Further exemplary embodiments provide an apparatus, wherein the apparatus may include a network interface configured to receive a view change message comprising a hash of an ongoing change to the state of the blockchain and a next view value, and one or more processors configured to perform one or more of the steps of: generating a view data message comprising signed ready messages from other subsequent peers having evidence of an ongoing change to the state of the blockchain in response to the reception of a predetermined threshold of view change messages, and transmitting the generated view data message comprising the signed ready messages to a primary peer.

[0008] From a first embodiment, the present invention provides an apparatus, wherein the apparatus comprises: a network interface configured to receive view change messages requesting a view change from a previous primary peer of a blockchain to a primary peer; and a processor configured to identify, based on metadata of the received view change messages, whether a change to the state of the blockchain is in process with the previous primary peer, and to determine, based on a received view data message, whether the change to the state of the blockchain corresponds to the latest change to the blockchain, and the network interface further configured to transmit a new view message containing the in-process change to the state of the blockchain to following peers.

[0009] Preferably, the present invention provides a device, wherein the network interface is configured to transmit the new view message in response to the reception of only one view data message.

[0010] Preferably, the present invention provides an apparatus, wherein an ongoing change to the blockchain state comprises a proposed data block.

[0011] Preferably, the present invention provides an apparatus, and the processor is further configured to check whether view change messages have been received from a predetermined threshold of the subsequent peers.

[0012] Preferably, the present invention provides an apparatus, wherein for each view change message, the metadata includes a next view number and a hashed change to the blockchain.

[0013] Preferably, the present invention provides an apparatus, wherein the view data message comprises a plurality of prepare messages received by subsequent peers from other peers.

[0014] Preferably, the present invention provides an apparatus, wherein the processor is configured to check whether a change in progress to the state of the blockchain is included in a predetermined number of the signed prepare messages stored within the view data message.

[0015] In another embodiment, the present invention provides an apparatus, said apparatus may include: a processor configured to perform the steps of determining that a current primary peer of a blockchain has become a faulty peer, identifying that a change to the state of said blockchain is in progress with said current primary peer, and generating a view change message including a hash of the change in progress to said blockchain state and a next view number, and a network interface configured to transmit said generated view change message to other peers.

[0016] Preferably, the present invention provides an apparatus, and the processor is further configured to store, within the view change message, the signatures of other subsequent peers of the blockchain who agree to an ongoing change to the state of the blockchain.

[0017] Preferably, the present invention provides an apparatus in which ongoing changes to the blockchain state and the signatures are collected within a prepare phase of practical Byzantine fault tolerant (pBFT) consensus.

[0018] Preferably, the present invention provides an apparatus, wherein the processor is configured to identify an ongoing change to the blockchain state based on a pre-prepare message received from a primary peer.

[0019] In another embodiment, the present invention provides a method, the method comprising: receiving view change messages requesting a view change from a previous primary peer of a blockchain to a primary peer; identifying, based on metadata of the received view change messages, that a change to the state of the blockchain is in process with the previous primary peer; determining, based on a received view data message, whether the change to the state of the blockchain corresponds to the latest change to the blockchain; and transmitting a new view message containing the in-process change to the state of the blockchain to following peers.

[0020] Preferably, the present invention provides a method, wherein the transmitting step comprises the step of transmitting a new view message in response to receiving a single view data message.

[0021] Preferably, the present invention provides a method, wherein an ongoing change to the state of the blockchain comprises a proposed data block.

[0022] In another embodiment, the present invention provides an apparatus, the apparatus comprising: a network interface further configured to receive, from the primary peer, a pre-preparation message comprising proposed data to be added to the blockchain; and a processor configured to generate a preparation message comprising a hash of the proposed data to be added to the blockchain and a signature of a consensus peer, add a hash puzzle of the consensus peer to the preparation message, and transmit the preparation message having the hash puzzle to a plurality of other consensus peers of the blockchain.

[0023] Preferably, the present invention provides an apparatus, and the processor is further configured to determine whether a predetermined threshold of the other consensus peers agrees on the proposed data to be added to the blockchain based on a readiness message received from the other consensus peers.

[0024] Preferably, the present invention provides an apparatus, wherein the processor is further configured to generate a commit message containing a solution to a hash puzzle added to the preparation message and to transmit the commit message to the plurality of other consensus peers.

[0025] Preferably, the present invention provides an apparatus, wherein the commit message does not include the signature of the consensus peer.

[0026] Preferably, the present invention provides an apparatus, wherein the processor is configured to generate the hash puzzle through the hash of a predefined secret value.

[0027] Preferably, the present invention provides an apparatus, wherein the processor is further configured to receive ready messages from the other consensus peers, and the received ready messages include hash puzzles added by each of the other consensus peers.

[0028] In another embodiment, the present invention provides an apparatus, wherein the apparatus comprises: a network interface configured to receive a view change message including a hash of an ongoing change to the state of the blockchain and a next view value; and a processor configured to perform the steps of generating a view data message including signed ready messages from other subsequent peers having evidence of an ongoing change to the state of the blockchain in response to receiving a predetermined threshold of view change messages, and transmitting the generated view data message including the signed ready messages to a primary peer.

[0029] Preferably, the present invention provides an apparatus, wherein the signed preparation messages are collected within a prepare phase of a Byzantine fault tolerant (BFT) consensus.

[0030] Preferably, the present invention provides an apparatus, wherein the signed ready messages include metadata comprising a view number of a new primary peer and a hash of an ongoing change to the state of the blockchain.

[0031] Preferably, the present invention provides an apparatus, wherein the signed ready messages further comprise a hash puzzle added by the other subsequent peers.

[0032] Preferably, the present invention provides an apparatus, and the processor is further configured to receive an ongoing change to the state of the blockchain from a primary peer. Brief explanation of the drawing

[0033] FIG. 1a is a diagram showing a blockchain network for performing view changes according to exemplary embodiments.

[0034] FIG. 1b is a diagram illustrating a consensus process performed in the blockchain network of FIG. 1a according to exemplary embodiments.

[0035] FIG. 1c is a diagram illustrating a view change process performed in the blockchain network of FIG. 1a according to exemplary embodiments.

[0036] FIG. 2a is a diagram showing an exemplary blockchain architecture configuration according to exemplary embodiments.

[0037] FIG. 2b is a diagram illustrating the blockchain transaction flow between nodes according to exemplary embodiments.

[0038] FIG. 3a is a diagram showing a permitted network according to exemplary embodiments.

[0039] FIG. 3b is a drawing showing different authorized networks according to exemplary embodiments.

[0040] FIG. 3c is a diagram showing an unauthorized network according to exemplary embodiments.

[0041] FIG. 4a is a diagram showing the format of a preparation message and a commit message for blockchain consensus according to exemplary embodiments.

[0042] FIG. 4b is a diagram showing the format of a view change message according to exemplary embodiments.

[0043] FIG. 4c is a diagram illustrating a faster view change process according to exemplary embodiments.

[0044] FIG. 5a is a drawing illustrating a method for changing the view according to exemplary embodiments.

[0045] FIG. 5b is a diagram illustrating a method for generating a view change message according to exemplary embodiments.

[0046] FIG. 5c is a diagram illustrating a method for generating a preparation message according to exemplary embodiments.

[0047] FIG. 5d is a diagram illustrating a method for generating a view data message according to exemplary embodiments.

[0048] FIG. 6a is a drawing illustrating an exemplary system configured to perform one or more of the operations described herein according to exemplary embodiments.

[0049] FIG. 6b is a drawing illustrating another exemplary system configured to perform one or more of the operations described herein according to exemplary embodiments.

[0050] FIG. 6c is a drawing showing another exemplary system configured to utilize smart contracts according to exemplary embodiments.

[0051] FIG. 6d is a drawing showing another exemplary system configured to utilize a blockchain according to exemplary embodiments.

[0052] FIG. 7a is a diagram illustrating the process of adding a new block to a distributed ledger according to exemplary embodiments.

[0053] FIG. 7b is a diagram showing the data contents of a new data block according to exemplary embodiments.

[0054] FIG. 7c is a drawing illustrating a blockchain for digital content according to exemplary embodiments.

[0055] FIG. 7d is a drawing showing a block that can represent the structure of a block in a blockchain according to exemplary embodiments.

[0056] FIG. 8a is a diagram showing an exemplary blockchain that stores machine learning (artificial intelligence) data according to exemplary embodiments.

[0057] FIG. 8b is a diagram illustrating an exemplary quantum security blockchain according to exemplary embodiments.

[0058] FIG. 9 is a drawing illustrating an exemplary system that supports one or more of the exemplary embodiments. Specific details for implementing the invention

[0059] It will be readily understood that the components of the present invention, as generally described and illustrated in the drawings of this specification, can be arranged and designed in a wide variety of configurations. Accordingly, the following detailed description of at least one embodiment of the method, apparatus, non-transient computer-readable medium, and system as shown in the attached drawings is not intended to limit the scope of the claimed application but is merely a representative example of selected embodiments.

[0060] The features, structures, or characteristics of the invention described throughout this specification may be combined or removed in any suitable manner in one or more embodiments. For example, the use of "exemplary embodiments," "some embodiments," or other similar expressions throughout this specification indicates that a specific feature, structure, or characteristic described in relation to an embodiment may be included in at least one embodiment. Accordingly, "exemplary embodiments," "in some embodiments," "in other embodiments," or other similar expressions used throughout this specification do not necessarily refer to embodiments of the same group, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Additionally, any connection between elements in the drawings may allow unidirectional and / or bidirectional communication even if the illustrated connection is a unidirectional or bidirectional arrow. Furthermore, all devices illustrated in the drawings may be different devices. For example, if a mobile device is illustrated as sending information, a wired device may be used to send information.

[0061] Additionally, while the term "message" may be used in the description of the embodiments, the application may be applied to many types of networks and data. Also, while specific types of connections, messages, and signaling may be depicted in the exemplary embodiments, the application is not limited to specific types of connections, messages, and signaling.

[0062] Exemplary embodiments provide methods, systems, components, non-transient computer-readable media, devices, and / or networks for implementing a faster view change process for a permissioned blockchain.

[0063] In one embodiment, the application utilizes a decentralized database (such as a blockchain), which is a distributed storage system comprising multiple nodes communicating with each other. The decentralized database includes an append-only immutable data structure similar to a distributed ledger that can maintain records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records without reaching consensus among the distributed peers. For example, peers may execute a consensus protocol to validate blockchain storage transactions, group storage transactions into blocks, and build a hash chain for the blocks. This process forms a ledger by ordering storage transactions as needed for consistency. In various embodiments, a permissioned and / or permissionless blockchain may be used. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains may include a native cryptocurrency and use consensus based on various protocols, such as Proof of Work (PoW).On the other hand, permissioned blockchain databases provide secure interactions between groups of entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, and information.

[0064] This application may utilize a blockchain running arbitrary programmable logic, referred to as “smart contracts” or “chaincodes,” which is tailored to a distributed storage system. In some cases, specialized chaincodes may exist for administrative functions and parameters, referred to as system chaincodes. The application may further utilize smart contracts, which are trusted distributed applications that leverage the underlying contract between nodes and the tamper-proof properties of the blockchain database, referred to as endorsements or endorsement policies. Blockchain transactions associated with this application may be “endorsed” before being committed to the blockchain, while unendorsed transactions are ignored. Through an endorsement policy, the chaincode may specify an endorser for a transaction in the form of a set of peer nodes required for the endorsement. When a client sends a transaction to peers specified in the endorsement policy, the transaction is executed to validate it. After validation, the transactions enter an ordering phase where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0065] This application can utilize nodes, which are the communicating entities of a blockchain system. "Nodes" can perform logical functions in that multiple nodes of different types can run on the same physical server. Nodes are grouped into trust domains and are associated with logical entities that control the nodes in various ways. Nodes can include various types, such as client or submitting-client nodes; a client or submitting-client node submits a transaction invocation to a guarantor (e.g., a peer) and broadcasts transaction proposals to an ordering service (e.g., an ordering node). Another type of node is a peer node, which receives transactions submitted by clients and commits them to maintain a copy of the state of the blockchain transaction ledger. Although not a requirement, peers can also act as guarantors. An ordering-service-node, or orderer, is a node that executes communication services for all nodes and implements a delivery guarantee, such as broadcasting to each peer node in the system when committing transactions and modifying a world state of the blockchain; this is generally another name for an initial blockchain transaction that includes control and configuration information.

[0066] This application can utilize a ledger, which is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions can occur due to chaincode calls (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, guarantor nodes, peer nodes, etc.). Each participating party (e.g., a peer node) may maintain a copy of the ledger. A transaction can commit a set of asset key-value pairs to the ledger with one or more operands, such as create, update, or delete. The ledger includes a blockchain (also called a chain) used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0067] This application can utilize a chain, which is a transaction log, composed of hash-linked blocks, each containing a sequence of N transactions, where N is equal to or greater than 1. The block header contains not only the hash of the block's transactions but also the hash of the previous block's header. In this way, all transactions in the ledger can be linked together in a sequential cryptographic manner. Therefore, it is impossible to tamper with the ledger data without destroying the hash links. The hash of the most recently added blockchain block represents all previously occurring transactions in the chain, thus ensuring that all peer nodes are in a consistent and trustworthy state. The chain is stored in the peer node file system (e.g., local, connected storage, cloud, etc.) to efficiently support the append-only nature of blockchain workloads.

[0068] Meanwhile, blockchain systems store data in an immutable ledger, provide distributed and decentralized access to the immutable ledger through untrusted participants, and establish consensus requirements for agreement among untrusted participants to ensure that no entity can alter the immutable ledger or invoke smart contracts without the consensus of other entities. A blockchain is formed by a network of participants who agree to add blocks (containing data) to the immutable ledger. Before being added, the block is linked to the previous block of the immutable ledger to form a chain. Due to these immutable and incorruptible characteristics of the blockchain, it can be safe from tampering and hacking. The decentralized nature also provides a unique trustless quality in that parties do not need to establish trust before securely conducting transactions.

[0069] The current state of the immutable ledger represents the latest values ​​of all keys included in the chain transaction log. Since this current state represents the latest key values ​​known to the channel, it is also referred to as the world state. Chaincode invocations execute transactions on the ledger's current state data. To make these chaincode interactions efficient, the latest values ​​of the keys can be stored in a state database. Since the state database can be simply an indexed view of the chain's transaction log, it can be regenerated from the chain at any time. The state database can be automatically restored (or created if necessary) upon peer node startup, before transactions are acknowledged.

[0070] A blockchain network can include many blockchain peers, each holding a copy or replica of the blockchain ledger. Consensus protocols are used by blockchain networks to ensure that the state of the blockchain ledger remains consistent across all blockchain peers. One algorithm commonly used for consensus is Practical Byzantine Fault Tolerance (pBFT). In pBFT consensus, one or more primary peers act as leaders for the remaining peers (referred to here as subsequent peers or consensus peers). Each primary peer (leader), like the subsequent peers, maintains the internal state of the blockchain ledger.

[0071] When a request to store data on the blockchain is received from a client, the primary peer creates a proposal and multicasts it to subsequent peers grouped with the primary peer. Next, the subsequent peers share the proposal with each other to check for consensus on the blockchain proposal. Once consensus is reached, the subsequent peers (and the primary peer) commit the blockchain proposal to the internal ledger and deliver the response to the client.

[0072] A "view" is the period of time during which a given blockchain peer acts as a primary peer. A view change is the process of switching from one primary peer to another. For example, the next primary peer may be a following peer selected in a round-robin fashion, following the order of blockchain peers in an on-chain file. Both primary and following peers can track the next primary peer by storing a view number that identifies the next primary peer within the on-chain file. In addition to moving through a series of views, peers also move through a series of sequence numbers, where the sequence number represents the block number of the next block to be stored in the blockchain.

[0073] To perform a view change, a blockchain peer (subsequent peer) may request a view change when it detects that the primary peer has entered a timeout or that faulty activity has occurred. When more blockchain peers detect faulty activity, they also send out a view change message. Here, the blockchain peer(s) within the group broadcast the view change message to each other. Once enough view change messages are received, the new primary peer initiates a new view.

[0074] A view change message may be a lightweight message containing an indication that a change to the primary peer is requested, without providing the content / state of the blockchain. When a predetermined threshold of view change messages is received between blockchain peers, the blockchain peers send a view data message containing the blockchain's current checkpoint to a new primary peer, thereby enabling the new primary peer to pick up the location where the failed primary peer stopped.

[0075] To ensure that the current checkpoint of the blockchain within the view data message is agreed upon by the consensus of the blockchain peers, the new primary peer must collect 2f + 1 view data messages containing the same checkpoint of the blockchain. In this case, 'f' is the total number of possible faulty nodes in a blockchain network having a total of 'n' nodes, where n = 3f+1. After receiving 2f + 1 view data messages containing the blockchain checkpoint, the new primary peer may broadcast a new view message to all blockchain peers containing the view data messages and instructing subsequent peers to move to the new primary peer.

[0076] As with view change messages, a new primary peer must wait to receive 2f + 1 view data messages before a new view message is sent. This is because view data messages contain the current state of the blockchain and the signatures of the blockchain peers sent in the view data messages. To verify that a sufficient number of blockchain peers agree on the current state of the blockchain, the primary peer must wait until a predetermined threshold (e.g., 2f + 1) of view data messages containing the latest state of the blockchain is received. The number 2f + 1 means that even if 'f' faulty nodes exist, the number of correct / non-faulty data messages will be at least f + 1 (i.e., at least one more than f). Therefore, the primary peer can verify, using 2f + 1 view data messages, whether a majority / quorum of non-faulty peers agrees on the ledger state. The disadvantage of the above view change process is that a new primary peer must wait for 2f + 1 view change messages and likewise wait for 2f + 1 view data messages (including ledger checkpoints). As a result, the view change process takes a significant amount of time.

[0077] Exemplary embodiments overcome these drawbacks and enable a faster view change to occur when an update to the blockchain is in flight. In particular, exemplary embodiments utilize the content of a prepare message used during an in-process update to the blockchain ledger to include signatures collected from other blockchain peers. These signatures can be added to a view change message. The view change message may also be updated to include changes proposed to the blockchain in flight.

[0078] Therefore, the view change message initially transmitted by a blockchain peer to initiate the view change process may include evidence from the majority of blockchain peers that the same update to the blockchain is in progress.

[0079] In this case, when a new primary peer collects 2f+1 view change messages, it can verify that at least f+1 of these view change messages originated from fault-free nodes. Additionally, the new primary peer only needs to wait for a single view data message (instead of 2f+1 view data messages) containing the blockchain's checkpoint / current state before sending a new view message. In this case, while waiting for this single view data message, the new primary peer can verify that the ongoing changes to the blockchain's state identified in the view change messages match the blockchain's current state / checkpoint in the view data message. Consequently, significant time can be saved in the ongoing blockchain process where the view change occurs. Furthermore, only a single checkpoint message needs to be processed, rather than 2f+1.

[0080] To implement improvements to the view change process for ongoing updates to the state of the blockchain, exemplary embodiments introduce changes to both the ready messages used during the pBFT consensus process and the view change messages used during the view change process.

[0081] FIG. 1a illustrates a blockchain network (100) for performing view changes according to exemplary embodiments. Referring to FIG. 1a, the blockchain network (100) comprises a plurality of blockchain peers (112, 114, 116, 118) that share the management of a blockchain (110), which may include both a hash-linked chain of blocks and a state database as illustrated in the example of FIG. 7a, etc. The blockchain network (100) may be a permissioned blockchain that requires authorization to access the blockchain (110). Access to the blockchain (110) is authorized by the blockchain peers (112-118). The blockchain network (100) does not involve centralized management, but is instead managed cooperatively by a group of blockchain peers (112-118) in a decentralized manner. The blockchain (110) is replicated across each of the blockchain peers (112-118). Additionally, consensus is used to verify whether there is consistency between the states of the replicas stored on the blockchain peers (112-118).

[0082] In this example, the blockchain peers (112-118) operate based on a practical Byzantine fault tolerance (pBFT) consensus protocol. In this scenario, the blockchain peers (112-118) identify a primary peer among them that acts as a leader when data is added to the blockchain (110). The primary peer (112) may receive a request from a client (120) to store a new transaction in the blockchain (110). Meanwhile, the remaining blockchain peers can be referred to as "followers" participating with the leader peer. pBFT consensus can operate even in the presence of faulty nodes. In the examples provided here, it is assumed that there may be up to f faulty nodes in a blockchain network containing n nodes, where n is 3f + 1 or more. Therefore, for consensus to be guaranteed among the blockchain peers, at least 2f + 1 nodes must reach consensus. That is, if f nodes are defective, 2f guarantees that at least half of the nodes are not defective. Also, by adding one, it guarantees that there are always more non-defective nodes than defective nodes.

[0083] FIG. 1b illustrates a consensus process (100B) performed by the blockchain network of FIG. 1a according to exemplary embodiments. In this example, a new block is added to the blockchain (110) illustrated in FIG. 1a based on the consensus reached between the blockchain peers (112-118). In this example, blockchain peer (112) is the current primary blockchain peer for the blockchain peers (112-118). However, the primary blockchain peer changes over time. For example, each peer (112-118) may spend time as a primary peer based on a round-robin approach, etc. Also, for convenience of explanation, four blockchain peers with one primary peer are illustrated in this example, but it should be understood that a blockchain network may have many blockchain peers including multiple primary peers simultaneously, and each of these may function as follower peers of various subsets.

[0084] Referring to FIG. 1b, the primary peer (112) may receive a request from a client (120) to store a new transaction in the blockchain (110). This step is omitted in the figure. In the preliminary step (131), the primary peer (112) may order the transactions into blocks and broadcast a list of ordered transactions to other blockchain peers (114, 116, 118).

[0085] In the preparation phase (132), blockchain peers (114, 116, 118) may receive an ordered list of transactions. Each blockchain peer (114, 116, 118) may calculate a hash code for a newly created block containing the hashes of the transactions and a final state of the world to be added to the state database, and broadcast a preparation message containing the final hash to other blockchain peers (114, 116, and 118) in the network. Thus, the blockchain peers may receive the preparation message from the other blockchain peers.

[0086] When blockchain peers receive a predetermined threshold (e.g., 2f+1) of a ready message, in the commit step (133), the blockchain peers may create a commit message and send said commit message to said other blockchain peers. When blockchain peers receive a predetermined threshold of the commit messages, the blockchain peers may commit a block to a local copy of the blockchain (110) containing updates to the chain of blocks and the state database.

[0087] According to various embodiments, the primary peer may change during all views (e.g., pBFT consensus rounds). The primary peer may be replaced using a view change protocol, for example, if a predefined time elapses without the primary peer broadcasting a request to the following peers. If necessary, a majority of honest nodes may vote for the legitimacy of the current leading node and replace the current leading node in line with the next leading node.

[0088] FIG. 1c illustrates a view change process (100C) performed by the blockchain network of FIG. 1a according to exemplary embodiments. In this example, the primary peer (112) is detected to be faulty. For example, a client (120) may submit a request to the primary peer (112), and the primary peer (112) may fail to respond within a predetermined time and may time out. If subsequent blockchain peers (114, 116, 118) suspect that the primary peer (112) is faulty, the blockchain peers (114, 116, 118) may transmit a view change message (141). In the relevant techniques, the view change message may be a heavyweight view change message containing the latest checkpoint of the blockchain ledger. For example, the latest checkpoint may contain the current state of the blockchain. As another example, the view change message may be a lightweight view change message containing only the next view sequence number (i.e., the identifier of the next primary peer).

[0089] When blockchain peers (114, 116, 118) receive a sufficient number of view change messages (e.g., 2f + 1), a blockchain peer may submit a view data message (142). The view data message (142) may be used only when the view change message (141) is a lightweight message. The view data message (142) may be signed and may function as proof for the next step. The view data message (142) includes the latest checkpoint of the blockchain and, if a next proposal (a proposal in progress) exists, includes it. However, the view data message (142) is sent only to the new view primary peer, which is the blockchain peer (114) in this example. After receiving enough view change messages (142) to satisfy a predetermined threshold (e.g., 2f + 1), the new primary peer (114) broadcasts a new view message (143) containing the predetermined threshold of view data messages (142) from other blockchain peers, thereby serving as proof of the validity of the new view.

[0090] FIG. 2a illustrates a blockchain architecture configuration (200) according to exemplary embodiments. As illustrated in FIG. 2a, the blockchain architecture (200) may include specific blockchain elements, for example, a group of blockchain nodes (202). The blockchain nodes (202) may include one or more nodes (204-210) (these four nodes are illustrated only by example). These nodes participate in various activities such as the blockchain transaction addition and verification process (consensus). One or more of the blockchain nodes (204-210) may endorse transactions based on an endorsement policy and provide ordering services to all blockchain nodes of the architecture (200). A blockchain node may initiate blockchain authentication and attempt to record it in the blockchain immutable ledger stored in the blockchain layer (216), and a copy thereof may also be stored in the underpinning physical infrastructure (214). A blockchain configuration includes one or more applications (224) connected to application programming interfaces (APIs) (222) to access and execute stored program / application code (220) (e.g., chaincode, smart contracts, etc.) that can be generated according to a customized application, and allows participants to maintain their state, control their assets, and receive external information in a configuration desired by the participants. This can be installed on all blockchain nodes (204-210) by distributing as a transaction and adding to a distributed ledger.

[0091] A blockchain-based or platform (212) includes various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure, which can be used to receive and store new transactions and to provide access to auditors to access data items. The blockchain layer (216) may expose an interface that provides access to a virtual execution environment necessary to process program code and engage the physical infrastructure (214). Cryptographic trust services (218) can be used to verify transactions, such as asset exchange transactions, and to keep information private.

[0092] The blockchain architecture configuration of FIG. 2a can process and execute program / application code (220) through one or more exposed interfaces and services provided by the blockchain platform (212). The code (220) can control blockchain assets. For example, the code (220) can store and transmit data and can be executed by nodes (204-210) in the form of smart contracts and associated chaincode having conditions or other code elements to be executed. As a non-limiting example, smart contracts may be created to execute reminders, updates, and / or other notifications to which changes, updates, etc. are subject. The smart contracts themselves may be used to identify authorization and access requirements and rules related to the use of the ledger. For example, a smart contract (or chaincode executing the logic of the smart contract) may read blockchain data (226) that can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer (216) to generate results (228) including warnings, determining responsibilities, etc. within complex service scenarios. A physical infrastructure (214) may be used to retrieve all of the data or information described herein.

[0093] Smart contracts can be created using advanced applications and programming languages ​​and then recorded in blocks of a blockchain. Smart contracts may contain executable code that is registered, stored, and / or replicated on the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that can be performed when conditions related to the smart contract are met. The execution of a smart contract can trigger trusted modification(s) to the state of a digital blockchain ledger. The modification(s) to the blockchain ledger triggered by the execution of a smart contract can be automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

[0094] Smart contracts can write data to the blockchain in the format of key-value pairs. Additionally, smart contract code can read values ​​stored in the blockchain and use them for application operations. Smart contract code can write the outputs of various logical operations to the blockchain. The aforementioned code can be used to generate temporary data structures on virtual machines or other computing platforms. Data recorded on the blockchain can be made public and / or kept private by encryption. Temporary data used or generated by the smart contract is stored in memory by the provided execution environment and is deleted once the data required by the blockchain is identified.

[0095] Chaincode can include the interpretation of smart contract code (e.g., logic), along with additional functions. As described herein, chaincode can be program code deployed on a computing network, where it is executed and verified by chain validators during the consensus process. Chaincode receives a hash and retrieves from the blockchain a hash associated with a data template generated by using a previously stored feature extractor. If the hashes of the hash identifier match the hash generated from the stored identifier template data, the chaincode sends an authorization key to the requested service. Chaincode can write to blockchain data associated with cryptographic details.

[0096] FIG. 2b illustrates an example of a blockchain transaction flow (250) between nodes of a blockchain according to exemplary embodiments. Referring to FIG. 2b, the transaction flow may include a transaction proposal (291) sent by an application client node (260) to an endorsement peer node (281). The endorsement peer (281) may execute a chaincode function to verify the client signature and initiate the transaction. The output may include chaincode results, a set of key / value versions read from the chaincode (read set), and a set of keys / values ​​written from the chaincode (write set). The proposal response (292), if accepted, is sent back to the client (260) along with the endorsement signature. The client (260) assembles the endorsements into a transaction payload (293) and broadcasts it to an ordering service node (284). The ordering service node (284) delivers the ordered transactions as blocks to all peers (281-283) of the channel. Before committing to the blockchain, each peer (281-283) can verify the transactions. For example, the peers can check an endorsement policy to ensure that the correct allotment of the specified peers has signed the results and authenticated the signatures for the transaction payload (293).

[0097] Referring again to FIG. 2b, the client node (260) initiates a transaction (291) by constructing and sending a request to the guarantor peer node (281). The client (260) may include an application using a supported software development kit (SDK) that utilizes available APIs to generate a transaction proposal. A proposal is a request to call a chaincode function to read / write data to the ledger (i.e., write new key-value pairs for assets). The SDK may act as a shim to package the transaction proposal into a properly designed format (e.g., Protocol Buffers via Remote Procedure Call (RPC)) and to take the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0098] In response, the endorsement peer node (281) can verify (a) whether the transaction proposal is well formed, (b) whether the transaction has not already been submitted in the past (replay-attack protection), (c) whether the signature is valid, and (d) whether the submitter (in the example, client (260)) is properly authorized to perform the proposed operation on the channel. The endorsement peer node (281) can take the transaction proposal input as arguments to a chaincode function called. Then, the chaincode is executed against the current state database to generate a transaction result containing response values, a read set, and a write set. However, at this point, no update to the ledger is performed. In the response (292), a set of values, along with the signature of the endorsement peer node (281), is passed back to the client (260)'s SDK as the proposal response (292), and the client (260)'s SDK parses the payload for use by the application.

[0099] In response, the client (260) application inspects / verifies the signatures of the endorsing peers and compares the proposal responses to determine if they are identical. If the chaincode has only queried the ledger, the application inspects the query response and generally does not submit the transaction to the ordering node service (284). If the client application intends to submit a transaction to the ordering node service (284) to update the ledger, the application determines whether the specified endorsing policy is satisfied before submission (i.e., whether all peer nodes required for the transaction have endorsed the transaction). Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node must endorse the transaction. The architecture is configured so that even if the application chooses not to inspect the response or passes an unendorsed transaction, the endorsing policy is still enforced by the peers and supported during the commit verification phase.

[0100] After a successful inspection, in step (293), the client (260) aggregates the endorsements into a transaction and broadcasts the transaction proposal and response within the transaction message to the ordering node (284). The transaction may include read / write sets, peer signatures, and channel IDs. The ordering node (284) does not need to inspect the entire contents of the transaction to perform its operation; instead, the ordering node (284) may simply receive transactions from all channels of the network, sort them chronologically by channel, and create blocks of transactions per channel.

[0101] Blocks are transmitted from the ordering node (284) to all peer nodes (281-283) of the channel. Transactions (294) within the block are verified to ensure that all guarantee policies are satisfied and that there have been no changes to the ledger state due to read set variables since the read set was created by the transaction execution. Transactions within the block are tagged as valid or invalid. Additionally, in step (295), each peer node (281-283) adds the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. An event may be triggered to notify the client application that the transaction (call) has been immutably added to the chain and to notify whether the transaction has been verified or invalidated.

[0102] FIG. 3a illustrates an example of a permissioned blockchain network (300) featuring a distributed, decentralized peer-to-peer (P2P) architecture. In this example, a blockchain user (302) can initiate a transaction on the permissioned blockchain (304). In this example, the transaction may be a deploy, invoke, or query, and may be issued directly via an API, etc., through a client-side application using an SDK. Networks may provide access to a regulator (306), such as an auditor. A blockchain network operator (308) manages member permissions, such as registering the regulator (306) as an "auditor" and registering the blockchain user (302) as a "client." While the auditor may be limited to ledger queries only, the client may be granted permission to deploy, invoke, and query specific types of chaincode.

[0103] A blockchain developer (310) can write chaincode and client-side applications. The blockchain developer (310) can deploy chaincode directly to the network through an interface. To include credentials from an existing data source (312) within the chaincode, the developer (310) can access the data using an out-of-band connection. In this example, a blockchain user (302) connects to a permissioned blockchain (304) through a peer node (314). Before proceeding with transactions, the peer node (314) retrieves the user's registration and transaction certificates from a certificate authority (316) that manages user roles and permissions. In some cases, blockchain users must possess these digital certificates to transact on the permissioned blockchain (304). Meanwhile, a user intending to use the chaincode may need to verify their credentials from an existing data source (312). To verify user authentication, the chaincode can use an out-of-band connection for this data through an existing processing platform (318).

[0104] FIG. 3b illustrates another example of a permissioned blockchain network (320) featuring a distributed, decentralized P2P architecture. In this example, a blockchain user (322) can submit a transaction to the permissioned blockchain (324). In this example, the transaction may be a deployment, a call, or a query, and may be issued directly via an API, etc., through a client-side application using an SDK. Networks may provide access to a coordinator (326), such as an auditor. A blockchain network operator (328) manages membership permissions, such as registering the coordinator (326) as an "auditor" and registering the blockchain user (322) as a "client." While the auditor may be limited to ledger queries only, the client may be granted permission to deploy, call, and query specific types of chaincode.

[0105] A blockchain developer (330) writes chaincode and client-side applications. The blockchain developer (330) can deploy chaincode directly to the network through an interface. To include credentials from an existing data source (332) in the chaincode, the developer (330) can access the data using an out-of-band connection. In this example, a blockchain user (322) connects to the network through a peer node (334). Before proceeding with transactions, the peer node (334) retrieves the user's registration and transaction certificates from a certification authority (336). In some cases, blockchain users must possess these digital certificates to transact on a permitted blockchain (324). Meanwhile, a user intending to use the chaincode may need to verify their credentials from an existing data source (332). To verify the user's authentication, the chaincode can use an out-of-band connection to this data through an existing processing platform (338).

[0106] In some embodiments, the blockchain herein may be a permissionless blockchain. Unlike permissioned blockchains that require participation rights, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user can create a private address and begin interacting with the network by submitting transactions and adding entries to the ledger. Additionally, all parties may choose to run nodes on the system and employ a mining protocol that helps verify transactions.

[0107] FIG. 3c illustrates a process (350) of a transaction processed by a permissionless blockchain (352) comprising a plurality of nodes (354). A sender (356) wishes to send a payment or any other form of value (e.g., a certificate, medical records, a contract, goods, services, or other assets that can be encapsulated in a digital record) to a recipient (358) via the permissionless blockchain (352). In one embodiment, the sender device (356) and the recipient device (358) may each have digital wallets (associated with the blockchain (352)) that provide user interface controls and a display of transaction parameters. In response, the transaction is broadcast to the nodes (354) via the blockchain (352). Nodes verify (360) transactions according to network parameters of the blockchain (352), based on rules (which may be pre-defined or dynamically assigned) set by the creators of the permissionless blockchain (352). For example, this may include verifying the identities of the relevant parties. Transactions may be verified immediately, or they may be placed in a queue along with other transactions so that the nodes (354) determine whether the transactions are valid based on a set of network rules.

[0108] In structure (362), valid transactions are formed into blocks and sealed with a lock (hash). This process can be performed by mining nodes among the nodes (354). Mining of nodes can be done using additional software specifically designed for mining and generating blocks for a permissionless blockchain (352). Each block can be identified by a hash (e.g., a 256-bit number, etc.) generated using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the previous block header in the chain, and a group of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure, independent chain of blocks.

[0109] Before blocks are added to the blockchain, they must first be verified. Verification for a permissionless blockchain (352) may include a proof-of-work (PoW), which is a solution to a puzzle derived from the block header. Although not illustrated in the example of FIG. 3c, another process for verifying a block is a proof-of-stake. Unlike a proof-of-work, where an algorithm rewards miners who solve mathematical problems, in a proof-of-stake, the creator of a new block is selected in a deterministic way based on their wealth, also defined as "stake." Then, a similar proof is performed by the selected / chosen node.

[0110] Through mining (364), nodes attempt to solve a block by progressively changing one variable until the solution meets a network-wide target. This generates a PoW and thereby guarantees the correct answer. In other words, a potential solution must prove that computing resources have been drained in solving the problem. In some types of permissionless blockchains, miners may be rewarded with the value of correctly mining a block (e.g., coins, etc.).

[0111] Here, the PoW process, along with chaining blocks, makes blockchain modification extremely difficult because an attacker would have to modify all subsequent blocks to allow modifications to one block. Additionally, as new blocks are mined, the difficulty of modifying blocks increases, and the number of subsequent blocks increases. Through distribution (366), a successfully verified block is distributed through the permissionless blockchain (352), and all nodes (354) add said block to a majority chain, which is an auditable ledger of the permissionless blockchain (352). Additionally, the value of the transaction submitted by the sender (356) is deposited or otherwise transferred to the digital wallet of the recipient device (358).

[0112] FIG. 4a illustrates the format of a ready message (410) and a commit message (420) for blockchain consensus according to exemplary embodiments. For example, the ready message (410) and the commit message (420) may be used to replace traditional ready and commit messages in the pBFT consensus process (100B) illustrated in FIG. 1b. Referring to FIG. 4a, the ready message (410) may include a view number (412) indicating the next primary peer (e.g., from a predefined list, etc.) and a sequence number (413) indicating the block number of the next block to be added in the blockchain. For example, if the most recently stored block in the blockchain is block #15, the sequence number (413) stores a value 16 indicating that block #16 is the next block to be added.

[0113] According to various embodiments, the preparation message (410) may also include the hash of the latest proposal (411) to be added to the blockchain. The relevant technical preparation message does not include the hash of the latest proposal. Here, the latest proposal (411) may represent a block of transaction content / data to be added to the blockchain and currently undergoing consensus among blockchain peers. For example, the transaction proposal (411) may include key-value pairs to be read / write updated as a result of blockchain transactions to be added to the blockchain ledger. By hashing the latest proposal (411), the size of the preparation message (410) is kept small while still providing proof of the current state of the blockchain ledger that is being updated (in progress).

[0114] The preparation message (410) also includes the signature (414) of the blockchain peer that generated the preparation message (410). The signature (414) is on the hash of the latest proposal (411), the view number (412), and the sequence number (413). Thus, the signature (414) confirms that the blockchain peer has the following state of the blockchain. As further described below, the preparation message (410) also includes a hash puzzle (415).

[0115] After a sufficient readiness message (410) is received, the blockchain peer may generate and send a commit message (420). The commit message includes a digest of a blockchain proposal (421) to be added to the blockchain ledger, a view number (422) indicating the next primary peer (e.g., a predefined list), and a sequence number (423) indicating the block number of the next block in the blockchain to be added. Here, the view number (422) and the sequence number (423) correspond to the view number (412) and sequence number (413) of the readiness message (410). The commit message (420) also includes a solution (424) for the hash puzzle (415) provided within the readiness message (410).

[0116] A blockchain peer can update the blockchain when a sufficient number of commit messages (420) are collected by the blockchain peer. For example, when commit messages (420) are received from a quorum of blockchain peers in a group, an update to the blockchain (e.g., identified by the digest (421)) is performed. In this example, the proof of the blockchain update used by the blockchain peer is based on the collected commit messages and a corresponding preparation message containing the blockchain peer's signature proving the change in the blockchain state.

[0117] In exemplary embodiments, the hash puzzle (415) may be used to replace the signature on the commit message (420). Each transmitting blockchain peer sending the ready message (410) also adds its own signature (414).

[0118] In blockchain consensus, the system needs a way to verify that the blockchain peer has also sent a commit message (420). Typically, this is done by signing the commit message. However, the sending blockchain peer has already added a signature (414) to the ready message. Therefore, signing the commit message (420) is not safe because it exposes the signature again. Instead, the sending blockchain peer can sign the ready message (410) with a signature (414) and also add a hash puzzle (415) such as y = Hash(x), where 'x' is a random secret.

[0119] Next, the sending blockchain peer can reveal the solution (424) for the hash puzzle (415) (where the solution = x) within the commit message (420). To verify the hash puzzle (415), the receiving blockchain peer hashes the solution (424) provided in the commit message (420) from the sending blockchain peer to determine if it has reached the same value of the hash puzzle (415) in the ready message (410). If the hashed version of the solution (424) is identical to the hash puzzle (415), the receiving blockchain peer knows that the same sending blockchain peer has sent both the commit message (420) and the ready message (410).

[0120] A new view change message (430) can be constructed as described in the example of FIG. 4b by modifying the preparation message (410) to include the latest proposal sequence (411) identifying an in-flight change to the state of the blockchain, and also including the signature (414) of the sending blockchain peer. Referring to FIG. 4b, the view change message (430) includes a hash proposal (431) of an in-flight change to the state of the blockchain. The hash proposal (431) is used to preserve the amount of data required to represent the change state to the blockchain. Here, the hash proposal (431) may include the hash of a block / transaction of content in progress to be added to the blockchain ledger before the current primary peer experiences a timeout / failure. The view change message (430) also includes metadata (432) containing information regarding the state of the blockchain, such as a view number (next primary peer), a sequence number (next block in the chain), etc.

[0121] Additionally, the view change message (432) also includes the signatures (433, 434, 435) of blockchain peers collected during the preparation phase from the preparation message (410). The signatures (433, 434, 435) correspond to the signature (414) in the preparation message (410). Thus, the view change message (430) can provide evidence of an ongoing change to the blockchain through a hash proposal (431), provide the current state of the blockchain through metadata (432), and provide the number of blockchain peers who agreed to the hash proposal (431) and the state (432) through the signatures (433, 434, 435). A view change message (432) may be configured by each of the blockchain peers in the group illustrated in FIG. 4c (e.g., any one of the blockchain peers (444, 446, and 448)) in response to the detection that the current primary peer (442) is faulty. For example, the faulty primary peer (442) may be detected in response to a timeout in response to a request from a client (450) to add data to the blockchain ledger. In this case, the timeout may occur at a specific point in the process where new data is created but before it is added to the blockchain.

[0122] As additionally illustrated in the process (400C) of FIG. 4c, a new primary peer is selected based on metadata (432) accompanied by a view change message (430). Here, the new primary peer is identified as a blockchain peer (444). Accordingly, subsequent peers (446, 448) generate a view change message (432) and send it to the new primary peer (444) to request a change to the blockchain view. When the new primary peer (444) receives the view change message (430) from a predetermined threshold of the blockchain peers (e.g., 2f + 1), the new primary peer (444) can confirm the change in progress to the blockchain ledger based on the hashed proposal (431) contained in the view change messages. Thus, the new primary peer (444) requires only one view data message (449) to check the latest state of the blockchain.

[0123] In this example, the view data message (449) contains a checkpoint of the blockchain. If the checkpoint of the view data message (449) matches the proposal (431) hashed from the quorum of view change messages, the new primary peer (444) can confirm that the blockchain peer is not "behind" the current / most recent change of the blockchain. Therefore, the new primary peer (444) can send a new view message to the remaining blockchain peers (442, 446, 448) to notify the new primary peer (444) that the view has changed. Thus, instead of waiting for 2f + 1 view data messages, the new primary peer (444) only needs to wait for one view data message (449) to check the state of the blockchain.

[0124] In short, after 2f + 1 view change messages (430) have been collected, the new primary peer (444) learns what the latest proposal sequence is from the hash proposal (431) and metadata (432). Some peers may be behind and may be the first peers that send view data messages to the new primary peer. The new primary peer (444) must wait for one data view message from the updated subsequent peer before it can continue.

[0125] In the example of this specification, the new primary peer only needs to wait for one view data message if a sufficient number of subsequent peers have received 2f + 1 ready messages from other subsequent peers. That is, if 2f + 1 subsequent peers have received 2f + 1 ready messages containing the latest proposal hash and the signatures of the subsequent peers, the view change message can be composed of sufficient proof for the change. However, if a sufficient number of subsequent peers have not received the ready messages (i.e., fewer than 2f + 1), there is insufficient proof for the latest hash proposal being processed. Therefore, the new primary peer must wait for 2f+1 view data messages as in the process (100C) illustrated in FIG. 1c.

[0126] FIG. 5a illustrates a method (500) for performing a view change based on view change messages according to exemplary embodiments. As a non-limiting example, the method (500) may be performed by a program, etc., running on a blockchain peer. Referring to FIG. 5a, in step (502), the method may include the step of receiving view change messages requesting a view change from a previous primary peer to a primary peer in the blockchain. For example, the view change messages may be received from following peers within the blockchain network.

[0127] In step (504), the method may include the step of identifying that a change to the state of the blockchain is in process with the previous primary peer based on the metadata of the received view change messages. For example, the change to the blockchain state may include blockchain transactions stored within a data block to be added to the blockchain. The transactions may include key-value pairs that perform updates, deletions, additions, etc. to values ​​on the blockchain and are stored in the state database of the blockchain ledger.

[0128] In step (506), the method may include a step of determining whether a change to the state of the blockchain corresponds to the latest change to the blockchain based on a received view data message. For example, a change to the state of the blockchain may be identified from a view data message received from a subsequent peer, which includes the state of the blockchain with an in-process change to the blockchain. In step (508), the method may include a step of sending a new view message containing the in-process change to the state of the blockchain to following peers. For example, the sending step may include sending a new view message in response to receiving only a single view data message.

[0129] In some embodiments, the ongoing change to the state of the blockchain may include a proposed data block to be committed. In some embodiments, the identifying step may further include a step of confirming that the view change messages have been received from a predetermined threshold of the subsequent peers. In some embodiments, for each view change message, metadata may include a next view number and a hashed change to the blockchain. In some embodiments, the view data message may include a plurality of ready messages broadcast by the leading peer and received by subsequent peers. In some embodiments, the confirming step may include a step of confirming whether the ongoing change to the state of the blockchain is included in a predetermined number of ready messages stored within the view data message.

[0130] In some embodiments, the change in progress may be a change to the state of the blockchain that has not yet been committed to peers receiving view change and view data messages. However, in some cases, the change may have already been committed. By collecting messages identifying the change in progress, a peer can ensure that no other change has been committed to the blockchain when the blockchain peer that has already committed the change in progress is unavailable.

[0131] FIG. 5b illustrates a method (510) for generating a view change message according to exemplary embodiments. For example, the method (510) may be performed by a program running on a blockchain peer, etc. Referring to FIG. 5b, in step (512), the method may include a step of determining that the current primary peer of the blockchain has become a defective peer. For example, the blockchain peer may detect that the current primary peer has timed out, etc., while a consensus process is being performed among a plurality of blockchain peers of the blockchain network.

[0132] In step (514), the method may include the step of identifying that a change to the state of the blockchain is currently in progress with the primary peer. For example, the peer may have received a preparatory message from the current primary peer containing the change in progress to the state of the blockchain. In step (516), the method may include the step of generating a view change message containing the hash of the change in progress to the state of the blockchain and the next view number. Additionally, in step (518), the method may include the step of transmitting the view change message to a new primary peer.

[0133] In some embodiments, the method may further include the step of storing, within the view change message, the signatures of other subsequent peers of the blockchain who agree to the ongoing change to the state of the blockchain. In some embodiments, the ongoing change to the state of the blockchain and the signatures are collected during the preparation phase of the Byzantine fault tolerant (BFT) consensus. For example, the ongoing change to the state of the blockchain includes a new block to be added to the blockchain.

[0134] FIG. 5c illustrates a method (520) for generating a preparation message according to exemplary embodiments. Referring to FIG. 5c, in step (522), the method may include receiving a preliminary preparation message from a primary peer that includes proposed data to be added to the blockchain. In step (524), the method may include generating a preparation message that includes a hash of the proposed data to be added to the blockchain and a signature of a consensus peer. In step (526), ​​the method may include adding a hash puzzle of the consensus peer to the preparation message. In step (528), the method may include transmitting the preparation message having the hash puzzle to a plurality of other consensus peers of the blockchain.

[0135] In some embodiments, the method may further include the step of determining whether a predetermined threshold of the other consensus peers agrees to the proposed data to be added to the blockchain based on the readiness messages received from the other consensus peers. In some embodiments, the method may further include the step of generating a commit message containing a solution for a hash puzzle added to the readiness message, and the step of transmitting the commit message to the plurality of other consensus peers. In some embodiments, the commit message does not include the signature of the consensus peers. In some embodiments, the method may include the step of generating the hash puzzle through a hash of a predefined secret value. In some embodiments, the method may further include the step of receiving readiness messages from the other consensus peers, wherein the received readiness messages include hash puzzles added by each of the other consensus peers.

[0136] FIG. 5d illustrates a method (530) for generating a view data message according to exemplary embodiments. Referring to FIG. 5d, in step (532), the method may include receiving a view change message containing a hash of an ongoing change to the state of the blockchain and a next view value. In response to receiving a predetermined threshold of view change messages, in step (534), the method may include generating a view data message containing signed ready messages from other subsequent peers having evidence of an ongoing change to the state of the blockchain. In step (536), the method may include transmitting the generated view data message containing the signed ready messages to a primary peer.

[0137] In some embodiments, the method may further include the step of collecting the signed ready message during the ready phase of the Byzantine fault tolerant (BFT) consensus. In some embodiments, the signed ready message may include metadata including the hash of the ongoing change to the blockchain state and the view number of the new primary peer. In some embodiments, the signed ready message may further include hash puzzles added by other subsequent peers. In some embodiments, the method further includes the step of receiving the ongoing change to the blockchain state from the primary peer before the primary peer becomes faulty.

[0138] FIG. 6a illustrates an exemplary system (600) comprising a physical substructure (610) configured to perform various operations according to exemplary embodiments. Referring to FIG. 6a, the physical substructure (610) includes a module (612) and a module (614). The module (614) includes a blockchain (620) and a smart contract (630) (which may reside in the blockchain (620)), which can execute any one of the operation steps (608) included in any one of the exemplary embodiments (within the module (612)). The steps / operations (608) may include one or more of the described or illustrated embodiments and may represent output or recorded information that is recorded or read from one or more smart contracts (630) and / or blockchains (620). The physical substructure (610), module (612), and module (614) may include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, module (612) and module (614) may be the same module.

[0139] FIG. 6b illustrates another exemplary system (640) configured to perform various operations according to exemplary embodiments. Referring to FIG. 6b, the system (640) includes a module (612) and a module (614). The module (614) includes a blockchain (620) and a smart contract (630) (which may reside in the blockchain (620)), which can execute any one of the operation steps (608) included in any one of the exemplary embodiments (within the module (612)). The steps / operations (608) may include one or more of the described or illustrated embodiments and may represent output or recorded information that is written or read from one or more smart contracts (630) and / or blockchains (620). The physical infrastructure (610), the module (612), and the module (614) may include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, module (612) and module (614) may be the same module.

[0140] FIG. 6c illustrates an exemplary system configured to utilize a smart contract configuration between contracting parties according to exemplary embodiments, and an intermediary server configured to enforce smart contract conditions on a blockchain. Referring to FIG. 6c, the configuration (650) may represent a communication session, asset transfer session, or process or procedure driven by a smart contract (630) that explicitly identifies one or more user devices (652 and / or 656). The execution, operations, and results of the smart contract execution may be managed by a server (654). The contents of the smart contract (630) may require digital signatures by one or more of the subjects (652, 656) who are parties to the smart contract transaction. The results of the smart contract execution may be recorded on the blockchain (620) as blockchain transactions. The smart contract (630) resides on a blockchain (620) that may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0141] FIG. 6d illustrates a system (660) including a blockchain according to exemplary embodiments. Referring to the example in FIG. 6d, an application programming interface (API) gateway (662) provides a common interface for accessing blockchain logic (e.g., smart contracts (630) or other chaincode) and data (e.g., a distributed ledger, etc.). In this example, the API gateway (662) is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more subjects (652 and 656) to a blockchain peer (i.e., a server (654)). Here, the server (654) is a blockchain network peer component that holds a copy of the world state and is a distributed ledger that enables clients (652 and 656) to query data regarding the world state and submit transactions to the blockchain network, wherein, according to the contract (630) and endorsement policy, the endorsement peers will execute the smart contracts (630).

[0142] The above embodiments may be implemented as hardware, as a computer program executed by a processor, as firmware, or as a combination thereof. A computer program may be implemented on a computer-readable medium, such as a storage medium. For example, a computer program may be random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, a hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

[0143] An exemplary storage medium may be connected to a processor so that the processor can read and write information from the storage medium. Alternatively, the storage medium may be integrated into the processor. The processor and the storage medium may reside in an ordered integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may exist as separate components.

[0144] FIG. 7a illustrates a process (700) in which a new block is added to a distributed ledger (720) according to exemplary embodiments, and FIG. 7b illustrates the contents of a new data block structure (730) for a blockchain according to exemplary embodiments. Referring to FIG. 7a, clients (not shown) may submit transactions to blockchain nodes (711, 712, 713). Clients may receive instructions from any source to perform an activity on the blockchain (720). For example, clients may be applications acting on behalf of a requester, such as a device, person, or entity proposing transactions to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, 713) may maintain copies of the state of the blockchain network and the distributed ledger (720). Various types of blockchain nodes / peers may exist in the blockchain network, including guarantor peers that simulate and guarantee transactions proposed by clients, and commit peers that verify guarantors, validate transactions, and commit transactions to the distributed ledger (720). In this example, the blockchain nodes (711, 712, 713) may act as guarantor nodes, committer nodes, or both.

[0145] A distributed ledger (720) includes immutable, sequenced records in blocks and a state database (724) (current world state) that maintains the current state of the blockchain (722). One distributed ledger (720) may exist per channel, and each peer maintains its own copy of the distributed ledger (720) for each channel to which it is a member. The blockchain (722) is a log of transactions structured as hash-link blocks, each block containing a sequence of N transactions. The blocks may include various components as illustrated in FIG. 7b. Links between blocks (indicated by arrows in FIG. 7a) can be created by adding the hash of the previous block header into the block header of the current block. In this way, all transactions in the blockchain (722) are sequenced and cryptographically linked to each other, so as to prevent tampering with the blockchain data without destroying the hash-links. Additionally, due to the links, the latest block of the blockchain (722) represents all transactions that occurred prior to it. The blockchain (722) can be stored in a peer file system (local or attached storage) that supports an append-only blockchain workload.

[0146] The current state of the blockchain (722) and the distributed ledger (722) can be stored in a state database (724). Here, the current state data represents the latest values ​​for all keys included in the chain transaction log of the blockchain (722). Chaincode calls execute transactions against the current state of the state database (724). To make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database (724). The state database (724) may contain an indexed view of the transaction log of the blockchain (722), and thus it can be regenerated from the chain at any time. The state database (724) can be automatically restored (or created if necessary) at peer start before transactions are accepted.

[0147] Endorsement nodes receive transactions from clients and endorse transactions based on simulated results. Endorsement nodes hold smart contracts that simulate transaction proposals. When an endorsement node endorses a transaction, it generates a transaction endorsement, which is a signed response from the endorsement node to the client application, indicating the endorsement of the simulated transaction. The method of endorsing a transaction depends on an endorsement policy that can be specified within the chaincode. An example of an endorsement policy is "the majority of endorsement peers must endorse the transaction." Endorsement policies may differ for each channel. Endorsed transactions are forwarded by the client application to the ordering service (710).

[0148] The ordering service (710) accepts guaranteed transactions, orders them into a block, and delivers said blocks to committing peers. For example, the ordering service (710) may initiate a new block when a transaction threshold is reached, when a timer times out, or when other conditions are reached. In the example of FIG. 7a, the blockchain node (712) is a committing peer that receives a new data block (730) to store in the blockchain (720). The first block in said blockchain is called the genesis block, and it may include information about said blockchain, information about said blockchain members, data stored in said blockchain, etc.

[0149] The ordering service (710) may be composed of a cluster of orderers. The ordering service (710) does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service (710) may accept guaranteed transactions and specify the order in which these transactions are committed to the distributed ledger (720). The architecture of the blockchain network may be designed so that a specific implementation of 'ordering' (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0150] Transactions are recorded in the distributed ledger (720) in a consistent order. The order of the transactions is established to ensure that they are valid when updates to the state database (724) are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through the solving or mining of cryptographic puzzles, in this example, the parties to the distributed ledger (720) can select the ordering mechanism best suited for the network.

[0151] When the ordering service (710) initializes a new data block (730), the new data block (730) may be broadcast to committing peers (e.g., blockchain nodes (711, 712, and 713)). In response, each committing peer verifies the transactions within the new data block (730) by checking to ensure that the read set and write set still match the current world state of the state database (724). Specifically, the committing peer can determine whether the read data that existed when the guarantors simulated the transaction is identical to the current world state in the state database (724). When the committing peer verifies the transaction, the transaction is written to the blockchain (722) of the distributed ledger (720), and the state database (724) is updated with the write data from the read-write set. If a transaction fails, that is, if the committing peer discovers that the read-write set does not match the current world state of the state database (724), the transaction aligned in one block is still included in the block but is marked as invalid and the state database (724) is not updated.

[0152] Referring to FIG. 7b, a new data block (730) (also referred to as a data block) stored in the blockchain (722) of the distributed ledger (720) may include multiple data segments such as a block header (740), block data (750), and block metadata (760). It should be understood that various illustrated blocks and their contents, such as the new data block (730) and its contents illustrated in FIG. 7b, are merely examples and are not intended to limit the scope of exemplary embodiments. The new data block (730) may store transaction information of N transaction(s) (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data (750).

[0153] A new data block (730) may include a link to a previous block within a block header (740) (e.g., on the blockchain (722) of FIG. 7a). In particular, the block header (740) may include the hash of the previous block. The block header (740) may also include a unique block number, the hash of the block data (750) of the new data block (730), etc. The block number of the new data block (730) may be unique and may be assigned in various orders, such as an incremental / sequential order starting from 0.

[0154] Block metadata (760) may store multiple fields of metadata (e.g., as a byte array). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter identifying valid and invalid transactions within the block, and the last offset persisted of an ordering service that ordered the block. The signature, the last constituent block, and the orderer metadata may be added by the ordering service (710). Meanwhile, a committer of the block (such as a blockchain node (712)) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter may include a byte array of the same size as the number of transactions in the block data (750) and a verification code identifying whether the transaction was valid or invalid.

[0155] FIG. 7c illustrates an embodiment of a blockchain (770) for digital content according to the embodiments described herein. Digital content may include one or more files and associated information. The files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable additional exclusive features of the blockchain function as a safeguard to protect the integrity, validity, and authenticity of the digital content, which may be appropriately used in legal proceedings where admissibility rules apply, or in other settings where evidence is considered, or where the display and use of digital information is of interest in a different way. In this case, the digital content may be referred to as digital evidence.

[0156] Blockchains can be formed in various ways. In one embodiment, digital content is contained within the blockchain itself and can be accessed from the blockchain itself. For example, each block of the blockchain may store the hash value of reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and the associated digital content may be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block of the blockchain, and the hash value of each block can be used as a basis for referencing the previous block. This can be exemplified as follows.

[0157] In one embodiment, digital content may not be included in the blockchain. For example, the blockchain may store the encrypted hashes of each block's content without digital content. The digital content may be stored in a different storage area or memory address in relation to the hash value of the original file. The different storage area may be the same storage device used to store the blockchain, another storage area, or a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest and then looking up that hash value in the storage area where it is stored in correspondence with the actual digital content. This operation may be performed, for example, in a database gatekeeper. This can be exemplified as follows.

[0158] In the exemplary embodiment of FIG. 7c, the blockchain (770) comprises a plurality of blocks (7781, 7782, … 778) cryptographically linked in an ordered sequence, N ≥ 1. N Includes ). Blocks (7781, 7782, … 778 N The encryption used to link ) may be one of multiple keyed or keyless hash functions. In one embodiment, blocks (7781, 7782, … 778 N) is the subject to a hash function that generates n-bit alphanumeric outputs (where n is 256 or another number) from inputs based on information within the blocks. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secured Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, nonce-based algorithms, and non-collision-preventing PRF algorithms. In another embodiment, blocks (7781, 7782, … 778 N ) can be cryptographically linked by hash functions and other functions. For the purpose of illustration, the following description refers to a hash function, e.g., SHA-2.

[0159] Each block in the blockchain (7781, 7782, … 778 N ) includes a header, a file version, and a value. The header and the value differ from block to block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. The file version may be the original file or another version of the original file, as described below.

[0160] The first block (7781) of the blockchain is called the genesis block and includes a header (7721), an original file (7741), and an initial value (7761). The hashing scheme used for the genesis block and all subsequent blocks may vary. For example, all information in the first block (7781) may be hashed at once, or each or part of the information in the first block (7781) may be hashed separately, and then the separately hashed parts may be hashed.

[0161] The header (7721) may include one or more initial parameters, for example, a version number, timestamp, nonce, root information, difficulty, consensus protocol, duration, media format, source, descriptive keywords and / or the original file (7741) and / or other information associated with the blockchain. The header (7721) may be generated automatically (e.g. by blockchain network management software) or manually generated by a blockchain participant. Other blocks of the blockchain (7782 through 778 N Unlike the header within the ) header (7721) within the genesis block, it does not refer to the previous block simply because there is no previous block.

[0162] The source file (7741) within the genesis block may be, for example, data captured by a device with or without processing before being included in the blockchain. The source file (7741) is received from a device, media source, or node through an interface of the system. The source file (7741) is associated with metadata, which may be generated, for example, manually or automatically by a user, device, and / or system processor. The metadata may be included in the first block (7781) in relation to the source file (7741).

[0163] The value (7761) in the genesis block is an initial value generated based on one or more unique attributes of the original file (7741). In one embodiment, one or more unique attributes may include a hash value for the original file (7741), metadata for the original file (7741), and other information related to said file. In one implementation, the initial value (7761) may be based on the following unique attributes:

[0164] Other blocks in the blockchain (7782 to 778 N) also has headers, files, and values. However, unlike the first block (7721), the headers of the other blocks (7722 to 772) N Each of the remaining blocks contains the hash value of the previous block. The hash value of the previous block may be the hash of the previous block header or the hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, an auditable and immutable chain of custody can be established by tracing from the Nth block to the genesis block (and related source file) on a block-by-block basis, as indicated by the arrow (780).

[0165] Headers within other blocks (from 7722 to 772 N Each of these may also include other information, for example, version number, timestamp, nonce, root information, difficulty, consensus protocol and / or related files and / or other parameters or information generally associated with the blockchain.

[0166] Files in other blocks (7742 to 774 N ) may be, for example, identical to the original file or a modified version of the original file within the genesis block, depending on the type of processing performed. The type of processing performed may vary from block to block. Processing may include all modifications to the file within the preceding block, such as, for example, redacting information, changing the content of information, removing information from the file, adding information to files, or appending.

[0167] Additionally, or alternatively, processing may include simply copying a file from a previous block, changing the storage location of a file, analyzing a file from one or more preceding blocks, moving a file from one storage or memory location to another, or performing actions regarding a file in the blockchain and / or its associated metadata. Processing involving analyzing a file may include, for example, adding, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0168] Other blocks within other blocks (7762 to 776 N In each case, the values ​​are unique and differ as a result of the processing performed. For example, a value within any block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value was assigned. Therefore, the values ​​in the blocks provide an indication of what processing was performed in those blocks and also allow tracing back to the original file through the blockchain. This tracing verifies the chain-of-custody of the file through the entire blockchain.

[0169] For example, consider a case where parts of a file within a previous block are redacted, blocked out, or pixelated to protect the identity of the person indicated in the file. In this case, the block containing the modified file will include metadata related to the modified file, such as how the modification was performed, the person who performed the modification, and the timestamps where the modification(s) occurred. The metadata may be hashed to form the aforementioned values. Since the metadata for the block differs from the information hashed to form the values ​​in the previous block, the values ​​are distinct and can be recovered upon decryption.

[0170] In one embodiment, the value of a previous block may be updated to form the value of the current block when any or more of the following occur (e.g., a new hash value is calculated). In this exemplary embodiment, the new hash value may be calculated by hashing all or part of the information mentioned below.

[0171] FIG. 7d illustrates an example of a block that can represent the structure of blocks in a blockchain (790) according to one embodiment. Block i Silver, header(772 i ), file(774 i ) and value(776 i Includes ).

[0172] Header(772 i ) is the previous block (Block i-1It includes the hash value of ) and additional reference information, which may be, for example, any one of the types of information discussed herein (e.g., header information including references, attributes, parameters, etc.). Of course, with the exception of the genesis block, all blocks reference the hash of the previous block. The hash value of the previous block may be the hash of the header within the previous block containing files and metadata, or the hash of all or part of the information within the previous block.

[0173] File (774 i ) includes a sequence of multiple data such as Data 1, Data 2, …, Data N. The data is tagged with metadata Metadata 1, Metadata 2, …, Metadata N, and the metadata describes the content and / or characteristics associated with the data. For example, the metadata for each data may include a timestamp for the data, information for processing the data, keywords indicating people or other content described in the data, and / or other features that may help establish the validity and content of the entire file, particularly, for example, use as digital evidence as described in relation to the embodiments discussed below. In addition to the metadata, each data includes references REF1, REF2, …, REF to prevent tampering, file gaps, and sequential referencing through the file. N You can tag previous data using .

[0174] Once metadata is assigned to data (e.g., via a smart contract), the metadata cannot be altered without changing the hash, and any change to the hash can be easily identified for invalidation. Therefore, the metadata generates a data log of information that can be accessed for use by participants in the blockchain.

[0175] Value (776 i) is a hash value or another value calculated based on one of the types of information previously discussed. For example, for any given block (Blocki), the value for said block may be updated to reflect processing performed on said block, e.g., a new hash value, a new storage location, new metadata for the associated file, control or access, identifier or other action, or transfer of information to be added. Although said values ​​within each block are shown as being separated from metadata for the data of the file and header, said values ​​may be based on this metadata, in part or wholly, in other embodiments.

[0176] Once the blockchain (770) is formed at some point, the immutable chain of custody for the file can be obtained by querying the blockchain for the transaction history of values ​​across the blocks. This query, or tracking procedure, may begin by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continue decrypting the values ​​of other blocks until the genesis block is reached and the original file is recovered. The decryption may include decrypting the headers, files, and associated metadata in each block.

[0177] Decryption is performed based on the type of encryption that occurred in each block. This may involve the use of private keys, public keys, or public-private key pairs. For example, when asymmetric encryption is used, blockchain participants or processors on the network may generate a public-private key pair using a predetermined algorithm. The public and private keys are related to each other through a mathematical relationship. The public key can be publicly distributed to serve as an address for receiving messages from other users, such as an IP address or a home address. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. This allows the recipient to be confident that only the sender could have sent this message.

[0178] Generating a key pair may be similar to creating an account on the blockchain, but there is actually no need to register anywhere. Additionally, every transaction executed on the blockchain is digitally signed by the sender using a private key. This signature guarantees that only the account owner can track and process files on the blockchain (provided they are within the scope of authority determined by the smart contract).

[0179] FIGS. 8a and 8b illustrate additional examples of use cases for blockchain that can be integrated and used herein. In particular, FIG. 8a illustrates an example (800) of a blockchain (810) that stores machine learning (artificial intelligence) data. Machine learning relies on vast amounts of historical data (or training data) to build predictive models for accurate predictions of new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to find unearthed patterns.

[0180] In the example of FIG. 8a, the host platform (820) builds and deploys a machine learning model for predictive monitoring of an asset (830). Here, the host platform (820) may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The asset (830) may be any type of asset (e.g., machines or equipment, etc.) such as an aircraft, a locomotive, a turbine, medical machinery and equipment, oil and gas equipment, boats, vessels, vehicles, etc. As another example, the assets (830) may be intangible assets such as stocks, currencies, digital coins, insurance, etc.

[0181] A blockchain (810) can be used to significantly improve both the training process (802) of a machine learning model and the prediction process (804) based on the trained machine learning model. For example, in step (802), rather than requiring a data scientist / engineer or other user to collect data, historical data can be stored on the blockchain (810) by the asset (830) itself (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform (820) when performing prediction model training. For example, using smart contracts, data can be reliably transferred directly from the original location to the blockchain (810). By ensuring the security and ownership of the collected data using the blockchain (810), smart contracts can send the data of the assets directly to the individual using the data to build the machine learning model. This allows for data sharing among the assets (830).

[0182] The collected data can be stored on the blockchain (810) according to a consensus mechanism. The consensus mechanism brings the data being recorded (to authorized nodes) to ensure that the data being recorded is verified and accurate. The recorded data is timestamped, cryptographically signed, and cannot be altered. Therefore, it is auditable, transparent, and secure. In certain cases (e.g., supply chain, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase both the frequency and accuracy of the recorded data.

[0183] Additionally, the training of the machine learning model regarding the collected data may undergo rounds of refinement and testing by the host platform (820). Each round may be based on additional data or data not previously considered to help expand knowledge about the machine learning model. In step (802), the different training and testing steps (and associated data) may be stored in the blockchain (810). Each refinement regarding the machine learning model (e.g., changes to variables, weights, etc.) may be stored in the blockchain (810). This provides a verifiable proof of how the model was trained and what data was used to train the model. Additionally, when the host platform (820) finally achieves the trained model, the final model may be stored in the blockchain (810).

[0184] After the above model is trained, it can be deployed in a live environment to make predictions / decisions based on the execution of the final trained machine learning model. For example, in step (804), the machine learning model can be used for state-based maintenance (CBM) on assets such as aircraft, wind turbines, medical machines, etc. In this example, data fed back from the asset (830) can be input into the machine learning model to make event predictions such as failure events, error codes, etc. Decisions made by running the machine learning model on the host platform (820) can be stored on the blockchain (810) to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict a future breakdown / failure of a part of the asset (830) and generate a warning or notification to replace that part. The data behind this decision can be stored by the host platform (820) of the blockchain (810). In one embodiment, the features and / or measures described herein may occur in or in connection with the blockchain (810).

[0185] New transactions for the blockchain can be aggregated into a new block and added to the existing hash value. This is then encrypted to generate a new hash for the new block. As they are encrypted, they are added to the next list of transactions, and so on. As a result, a chain of blocks is formed, with each block containing the hash values ​​of all previous blocks. The computers storing these blocks periodically compare their hash values ​​to ensure that they are all in agreement. Any computers that do not agree discard the records causing the problem. While this approach is effective for ensuring the tamper-proof nature of the blockchain, it is not perfect.

[0186] One way to play this system is for a dishonest user to alter the list of transactions to their advantage while leaving the hash unchanged. This can be done through brute force—in other words, by altering the record, encrypting the result, and checking if the hash value is the same. If the hash values ​​do not match, the process continues until a matching hash is found. The security of blockchains is based on the belief that ordinary computers can only perform this type of brute-force attack over completely unrealistic timescales, such as the age of the universe. In contrast, quantum computers are much faster (1,000 times faster) and consequently pose a much greater threat.

[0187] FIG. 8b illustrates an example (850) of a quantum-secure blockchain (852) that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can verify each other's identities using QKD. This transmits information using quantum particles, such as photons, which cannot be copied by an eavesdropper without destroying them. In this way, the sender and receiver can verify each other's identities through the blockchain.

[0188] In the example of FIG. 8b, there are four users (854, 856, 858, and 860). Each pair of users can share a secret key (862) (i.e., QKD) between them. In this example, since there are four nodes, there are six pairs of nodes, and therefore QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CDSix different secret keys (862) including are used. Each pair can generate a QKD by transmitting information using quantum particles, such as photons, which cannot be copied without being destroyed by an eavesdropper. In this way, a pair of users can verify each other's identities.

[0189] The operation of the blockchain (852) is based on two procedures: (i) the creation of transactions, and (ii) the construction of blocks that aggregate the new transactions. New transactions can be created similarly to existing blockchain networks. Each transaction may include information regarding the sender, recipient, time of creation, amount (or value) to be transferred, a list of reference transactions justifying that the sender holds funds for the operation, etc. Then, this transaction record is transmitted to all other nodes, where it is entered into the pool of unconfirmed transactions. Here, two parties (i.e., a pair of users among users (854-860)) authenticate the transaction by providing a shared secret key (862) (QKD). This quantum signature can be attached to every transaction, making it very difficult to tamper with. Each node checks its entries against a local copy of the blockchain (852) to verify that each transaction has sufficient funds. However, the transactions are not yet confirmed.

[0190] Instead of performing the conventional mining process for blocks, blocks can be generated in a decentralized manner using a broadcast protocol. Over a predetermined period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to all unconfirmed transactions to thereby achieve Byzantine consensus regarding the correct version of the transaction. For example, each node may have a private value (transaction data of a specific node). In the first round, nodes transmit their private values ​​to one another. In subsequent rounds, nodes transmit the information they received from other nodes in the previous round. Here, honest nodes can generate a complete set of transactions within a new block. This new block can be added to the blockchain (852). In one embodiment, the features and / or actions described and / or depicted herein may occur on or against the blockchain (852).

[0191] FIG. 9 illustrates an exemplary system (900) that supports one or more of the exemplary embodiments described and / or illustrated herein. The system (900) includes a computer system / server (902) which operates with a number of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments and / or configurations that may be suitable for use with the computer system / server (902) include personal computer systems, server computer systems, thin clients, thick clients, portable or laptop devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including said systems or devices.

[0192] A computer system / server (902) may be described in the general context of computer system executable commands, such as program modules, that are executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. The computer system / server (902) may be executed in distributed cloud computing environments where tasks are performed by remote processing devices connected via a network of communications. In a distributed cloud computing environment, program modules may be located on both local and remote computer system storage media, including memory storage devices.

[0193] As illustrated in FIG. 9, the computer system / server (902) of the cloud computing node (900) is illustrated in the form of a general-purpose computing device. The components of the computer system / server (902) may include, but are not limited to, one or more processors or processing units (904), system memory (906), and a bus connecting various system components including the system memory (906) to the processor (904).

[0194] The above bus represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor using various bus architectures, or a local bus. For example, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0195] The computer system / server (902) generally includes various computer system readable media. These media may be any available media accessible by the computer system / server (902) and include both volatile and non-volatile media, and removable and non-removable media. In one embodiment, system memory (906) implements the flow of other drawings. System memory (906) may include computer system readable media in the form of volatile memory, such as random access memory (RAM) (910) and / or cache memory (912). The computer system / server (902) may further include other removable / non-removable, volatile / non-volatile computer system storage media. As merely an example, the storage system (914) may be provided for reading and writing from non-removable, non-volatile magnetic media (not shown, but generally referred to as a "hard drive"). Although not illustrated, a magnetic disk drive for reading and writing on a removable non-volatile magnetic disk (e.g., "floppy disk") and an optical disk drive for reading or writing on a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such cases, each may be connected to a bus through one or more data media interfaces. As further illustrated and described below, the memory (906) may include at least one program product having a set of program modules (e.g., at least one) configured to perform the functions of various embodiments of the application.

[0196] A program / utility (916) having a set (at least one) of program modules (918) may be stored, for example, in memory (906), and may also store, but is not limited to, an operating system, one or more applications, other program modules, and program data. Each operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. The program modules (918) generally perform the functions and / or methods of various embodiments of the application as described herein.

[0197] As understood by those skilled in the art, embodiments of the present application may be implemented as a system, method, or computer program product. Accordingly, the features of the present application may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware features that may all generally be referred to as "circuit," "module," or "system." Additionally, embodiments of the present application may take the form of a computer program product implemented on one or more computer-readable media(s) in which computer-readable program code is implemented.

[0198] The computer system / server (902) may also communicate with one or more external devices (920), such as a keyboard, a pointing device, a display (922), etc.; one or more devices that enable a user to interact with the computer system / server (902); and / or any device (e.g., a network card, a modem, etc.) that enables the computer system / server (902) to communicate with one or more other computing devices. Such communication may occur through an I / O interface (924). Additionally, the computer system / server (902) may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), through a network adapter (926). As illustrated, the network adapter (926) communicates with other components of the computer system / server (902) via a bus. It should be understood that, although not illustrated, other hardware and / or software components may be used with the computer system / server (902). Examples include, but are not limited to, microcode, device drivers, redundancy devices, external disk drive arrays, RAID systems, tape drives, and data storage systems.

[0199] Although at least one exemplary embodiment of the system, method, and non-transient computer-readable medium is illustrated in the accompanying drawings and described in the detailed description above, it will be understood that the present application is not limited to the disclosed embodiments and that numerous rearrangements, modifications, and substitutions are possible as described and defined by the following claims. For example, the system functions of the various drawings may be performed by one or more modules or components described herein, or may include a pair of transmitters, receivers, or both in a distributed architecture. For example, all or part of the functions performed by individual modules may be performed by one or more of these modules. Additionally, the functions described herein may be performed inside or outside the modules or components in relation to various events at various times. Furthermore, information transmitted between various modules may be transmitted between modules via at least one of a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or a plurality of protocols. Additionally, messages transmitted or received by any modules may be transmitted or received directly and / or through one or more of the other modules.

[0200] Those skilled in the art will recognize that the “System” may be implemented as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or other suitable computing device, or a combination of such devices. Presenting the functions described above as being performed by the “System” is not intended to limit the scope of this application in any way, but is intended to provide an example of one of many embodiments. In practice, the methods, systems, and devices disclosed herein may be implemented in local and distributed forms consistent with computing technology.

[0201] It should be noted that some of the system functions described herein are presented as modules to more specifically emphasize implementation independence. For example, a module may be implemented as a hardware circuit comprising custom Very Large-Scale Integration (VLSI) circuits or off-the-shelf semiconductors such as gate arrays, logic chips, transistors, or other discrete components. A module may also be implemented as a programmable hardware device such as a field-programmable gate array, programmable array logic, programmable logic devices, graphics processing devices, etc.

[0202] The module may also be implemented at least partially in software for execution by various types of processors. An identified unit of executable code may comprise one or more physical or logical blocks of computer instructions that may be composed, for example, of objects, procedures, or functions. Nevertheless, the executable files of the identified module may include heterogeneous instructions stored in different locations that, while not physically located together, constitute the module when logically combined and achieve the purpose specified for the module. Additionally, the modules may be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash device, RAM, tape, or any other medium used for storing data.

[0203] In practice, modules of executable code can be a single instruction or multiple instructions, and may be distributed across various different code segments, between different programs, or across multiple memory devices. Similarly, computational data may be identified and described here within modules, implemented in any appropriate form, and organized within any appropriate type of data structure. Computational data may be collected as a single data set or distributed across various locations, including other storage devices, and may exist at least partially as merely electronic signals in a system or network.

[0204] As generally described and illustrated in the drawings of this specification, it will be readily understood that the components of an application can be arranged and designed in a wide variety of different configurations. Accordingly, the detailed description of the embodiments is not intended to limit the scope of the application as claimed, but merely represents selected embodiments of the application.

[0205] A person skilled in the art will readily understand that the above embodiments may be implemented in a different order of steps and / or with hardware elements of a configuration different from that disclosed. Accordingly, although the application has been described based on these preferred embodiments, it will be apparent to a person skilled in the art that specific modifications, variations, and alternative configurations will be apparent.

[0206] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely examples and that the scope of the present application should be defined only by the appended claims, taking into account the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

Claim 1 A device comprising: a network interface configured to receive view change messages requesting a view change from a previous primary peer of a blockchain to a primary peer; and a processor configured to identify, based on metadata of the received view change messages, whether a change to the state of the blockchain is in process with the previous primary peer, and to determine, based on a received view data message, whether the change to the state of the blockchain corresponds to the latest change to the blockchain, wherein the network interface is also configured to transmit a new view message containing the in-process change to the state of the blockchain to following peers. Claim 2 A device according to claim 1, wherein the network interface is configured to transmit the new view message in response to the reception of only one view data message. Claim 3 In claim 1, the ongoing change to the blockchain state is a device including a proposed data block. Claim 4 In claim 1, the processor is also configured to check whether view change messages have been received from the subsequent peers of a predetermined threshold number. Claim 5 In claim 1, for each view change message, the device comprises metadata including a next view number and a hashed change to the blockchain. Claim 6 A device according to claim 1, wherein the view data message comprises a plurality of prepare messages received by subsequent peers from other peers. Claim 7 In claim 6, the device configured such that the processor determines whether an ongoing change to the state of the blockchain is included in a predetermined number of the signed prepare messages stored within the view data message. Claim 8 A device comprising, in claim 1, a processor also configured to identify that a change to the state of the blockchain is currently in progress with a primary peer and to generate a view change message including a next view number and a hash of the change in progress to the state of the blockchain. Claim 9 In claim 8, the processor is also configured to store, within the view change message, the signatures of other subsequent peers of the blockchain agreeing to an ongoing change to the state of the blockchain. Claim 10 In claim 9, the device in which ongoing changes to the blockchain state and the signatures are collected within a prepare phase of practical Byzantine fault tolerant (pBFT) consensus. Claim 11 In claim 8, the device configured such that the processor identifies an ongoing change to the blockchain state based on a pre-prepare message received from the current primary peer. Claim 12 The apparatus according to claim 1, wherein the network interface is also configured to receive, from the primary peer, a pre-preparation message containing proposed data to be added to the blockchain; and the processor is also configured to generate a preparation message containing a hash of the proposed data to be added to the blockchain and a signature of a consensus peer, add a hash puzzle of the consensus peer to the preparation message, and transmit the preparation message having the hash puzzle to a plurality of other consensus peers of the blockchain. Claim 13 In paragraph 12, the processor is also configured to determine whether a predetermined threshold number of the other consensus peers agree to the proposed data to be added to the blockchain based on a readiness message received from the other consensus peers. Claim 14 In paragraph 12, the device is configured such that the processor also generates a commit message containing a solution to a hash puzzle added to the preparation message and transmits the commit message to the plurality of other consensus peers. Claim 15 In paragraph 14, the device in which the commit message does not include the signature of the consensus peer. Claim 16 In claim 12, the device is configured such that the processor generates the hash puzzle through the hash of a predefined secret value. Claim 17 In paragraph 12, the processor is also configured to receive ready messages from the other consensus peers, and the received ready messages include hash puzzles added by each of the other consensus peers. Claim 18 A method of a primary peer, comprising: receiving view change messages requesting a view change from a previous primary peer of the blockchain to the primary peer; identifying, based on metadata of the received view change messages, that a change to the state of the blockchain is in process with the previous primary peer; determining, based on a received view data message, whether the change to the state of the blockchain corresponds to the latest change to the blockchain; and transmitting a new view message containing the in-process change to the state of the blockchain to following peers. Claim 19 In paragraph 18, the above-mentioned transmitting step comprises the step of transmitting a new view message in response to receiving only one view data message. Claim 20 In paragraph 18, the ongoing change to the state of the blockchain comprises a proposed data block.

Images