Computing system, method, non-transitory computer-readable medium, and computer program for determining a sequential order of blocks in a DAG-structured blockchain

Abstract

Exemplary operations may include one or more of receiving a chain of blocks from a blockchain that includes a directed acyclic graph (DAG) format in which blocks are independently hash-linked to multiple blocks; identifying temporal relationships between blocks in the chain of blocks based on the structure of the chain of blocks in the DAG format; determining a sequential linear order of the chain of blocks in the DAG format based on the identified temporal relationships; and storing the sequential linear order of the chain of blocks.

Description

Technical Field

[0001] This application generally relates to a system for storing data via a blockchain, and more particularly to a consensus protocol for determining the sequential order of blocks from a blockchain ledger in the form of a directed acyclic graph.

Background Art

[0002] A centralized database stores and maintains data in a single database (e.g., a database server) at one location. Due to its single location, a centralized database is particularly easy to manage, maintain, and control, especially in terms of security. However, a centralized database has significant drawbacks. For example, a centralized database has a single point of failure. When a hardware failure occurs, all the data in the database is lost and the work of all users is interrupted. Furthermore, a centralized database may highly depend on network connections. Therefore, the slower the connection, the longer the time required for each database access. Additionally, a centralized database has limited access to data because there is only one copy of the data being worked on at any given time. Moreover, since the database storage system has little data redundancy, it is very difficult to retrieve unexpectedly lost data other than through manual operations from backup storage.

[0003] In recent years, organizations have been paying attention to blockchain as an improved storage system that outperforms traditional databases. Blockchain provides data redundancy, has no central authority, and provides multiple access nodes, etc. Traditional blockchains store data blocks in a linear sequence where each block is hash-linked to the previous block. To add a new block to the sequence, it is necessary to execute a consensus protocol to verify the integrity of the ledger. In a permissionless blockchain, the consensus protocol can be "proof of work", while in a permissioned blockchain, the consensus protocol can be an endorsement / voting process. These processes generally take time. To increase the speed of the process of adding blocks, the blockchain can implement a directed acyclic graph (DAG) format. This can be achieved by enabling blocks to be added without being hindered by extra calculations (such as proof of work or voting / endorsement). However, the resulting blockchain is a tangle ribbon with blocks randomly woven in, and it may be difficult to obtain the order of consensus from it.

[0004] Therefore, what is needed is a solution that improves the consensus protocol of DAG-based blockchains and overcomes these drawbacks and limitations. SUMMARY OF THE INVENTION

[0005] One exemplary embodiment provides a system including one or more processors configured to perform one or more of receiving a chain of blocks from a blockchain including a directed acyclic graph (DAG) format in which blocks are hash-linked independently to multiple blocks, identifying temporal relationships between blocks in the chain of blocks based on the structure of the chain of blocks in the DAG format, and determining a sequential linear order of the chain of blocks in the DAG format based on the identified temporal relationships, and a storage configured to store the sequential linear order of the chain of blocks.

[0006] Another exemplary embodiment provides a method including one or more of receiving a chain of blocks from a blockchain including a directed acyclic graph (DAG) format in which blocks are hash-linked independently to multiple blocks, identifying temporal relationships between blocks in the chain of blocks based on the structure of the chain of blocks in the DAG format, determining a sequential linear order of the chain of blocks in the DAG format based on the identified temporal relationships, and storing the sequential linear order of the chain of blocks.

[0007] Yet another exemplary embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of receiving a chain of blocks from a blockchain including a directed acyclic graph (DAG) format in which blocks are hash-linked independently to multiple blocks, identifying temporal relationships between blocks in the chain of blocks based on the structure of the chain of blocks in the DAG format, determining a sequential linear order of the chain of blocks in the DAG format based on the identified temporal relationships, and storing the sequential linear order of the chain of blocks.

[0008] In a first aspect, the present invention provides a computing system comprising a processor configured to receive a chain of blocks from a blockchain including a directed acyclic graph (DAG) format in which blocks are hash-linked independently to a plurality of other blocks, identify temporal relationships between blocks in the chain of blocks based on the structure of the chain of blocks in DAG format, and determine a sequential linear order of the chain of blocks in DAG format based on the identified temporal relationships, and a storage configured to store the sequential linear order of the chain of blocks.

[0009] Preferably, the present invention provides a computing system, wherein the processor is further configured to perform a blockchain consensus process at a plurality of peer nodes based on the sequential linear order of the chain of blocks.

[0010] Preferably, the present invention provides a computing system, wherein the chain of blocks in DAG format includes a plurality of subsets of a linear chain of blocks of a plurality of peers, and the plurality of subsets of the linear chain of blocks include interconnections therebetween.

[0011] Preferably, the present invention provides a computing system, wherein the processor is configured to generate a DAG-formatted graph including nodes corresponding to blocks having edges corresponding to hash links therebetween, and identify temporal relationships based on the structure of the edges between the nodes on the graph.

[0012] Preferably, the present invention provides a computing system, wherein the processor is configured to transform the parent relationship on the graph by adding an edge from a child node to a node linked to the parent node of the child node and removing the edge between the child node and the parent node.

[0013] Preferably, the present invention provides a computing system configured such that a processor transforms cyclical nodes on a graph by aggregating nodes having the same relative temporal relationships into a single cycle node that includes the aggregated nodes.

[0014] Preferably, the present invention further provides a computing system configured such that a processor creates an order among the aggregated nodes included within a single cycle node based on a predetermined protocol.

[0015] Preferably, the present invention provides a computing system configured such that a processor identifies two different paths between pairs of nodes on a graph and removes the shorter path between the pairs of nodes out of the two different paths.

[0016] In a second aspect, the present invention provides a method that includes receiving a chain of blocks from a blockchain that includes a directed acyclic graph (DAG) format in which blocks are hash-linked independently to a plurality of blocks, identifying temporal relationships between blocks within the chain of blocks based on the structure of the chain of blocks in DAG format, determining a sequential linear order of the chain of blocks in DAG format based on the identified temporal relationships, and storing the sequential linear order of the chain of blocks.

[0017] Preferably, the present invention provides the method of claim 9, further including performing a blockchain consensus process at a plurality of peer nodes based on the sequential linear order of the chain of blocks.

[0018] Preferably, the present invention provides a method in which a chain of blocks in DAG format includes a plurality of subsets of a linear chain of blocks of a plurality of peers, and the plurality of subsets of the linear chain of blocks include interconnections therebetween.

[0019] Preferably, the present invention provides a method in which identifying includes generating a DAG-form graph including nodes corresponding to blocks having an edge corresponding to a hash link therebetween, and identifying temporal relationships includes identifying temporal relationships based on the structure of edges between nodes on the graph.

[0020] Preferably, the present invention provides a method in which identifying includes transforming the parent relationship on the graph by adding an edge from a child node to a node linked to the parent node of the child node and removing the edge between the child node and the parent node.

[0021] Preferably, the present invention provides a method in which identifying includes transforming cyclic nodes on the graph by aggregating nodes having the same relative temporal relationship into a single cyclic node including the aggregated nodes.

[0022] Preferably, the present invention provides a method in which transforming cyclic nodes further includes creating an order among the aggregated nodes included within a single cyclic node based on a predetermined protocol.

[0023] Preferably, the present invention provides a method in which identifying includes identifying two different paths between pairs of nodes on the graph and removing the shorter of the two different paths between the pair of nodes.

[0024] From a third aspect, the present invention is a non-transitory computer-readable medium that, when read by a processor, includes instructions that cause the processor to execute a method, the method comprising: receiving a chain of blocks from a blockchain including a directed acyclic graph (DAG) format in which blocks are independently hash-linked to a plurality of blocks; identifying a temporal relationship between blocks in the chain of blocks based on the structure of the chain of blocks in DAG format; determining a sequential linear order of the chain of blocks in DAG format based on the identified temporal relationship; and storing the sequential linear order of the chain of blocks.

[0025] Preferably, the present invention further provides a non-transitory computer-readable medium that further includes performing a blockchain consensus process at a plurality of peer nodes based on the sequential linear order of the chain of blocks.

[0026] Preferably, the present invention provides a non-transitory computer-readable medium in which the chain of blocks in DAG format includes a plurality of subsets of a linear chain of blocks of a plurality of peers, and the plurality of subsets of the linear chain of blocks include interconnections therebetween.

[0027] Preferably, the present invention includes generating a graph in DAG format including nodes corresponding to blocks having edges corresponding to hash links therebetween in identifying, and identifying the temporal relationship includes identifying the temporal relationship based on the structure of the edges between the nodes on the graph. BRIEF DESCRIPTION OF THE DRAWINGS

[0028]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3A

Figure 3B

Figure 3C

Figure 4A

Figure 4B

Figure 4C

Figure 4D

Figure 4E

Figure 5

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 7A

Figure 7B

Figure 7C

Figure 7D

Figure 8A

Figure 8B

Figure 9

[0029] It will be readily understood that the components of the present invention generally described herein and illustrated in the figures can be arranged and designed in a variety of different configurations. Accordingly, the following detailed description of at least one embodiment of the method, apparatus, non-transitory computer-readable medium, and system shown in the accompanying drawings is not intended to limit the scope of the present application as claimed, but represents the selected embodiments only.

[0030] The features, structures, or characteristics of the invention described throughout this specification can be combined or removed in any suitable manner in one or more embodiments. For example, the use throughout this specification of phrases such as "example embodiments," "some embodiments," or other similar terms indicates the fact that the particular features, structures, or characteristics described in connection with those embodiments can be included in at least one embodiment. Thus, the appearances throughout this specification of phrases such as "example embodiments," "in some embodiments," "in other embodiments," or other similar terms do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics can be combined or removed in any suitable manner in one or more embodiments. Further, in the figures, any connection between elements can support one-way or two-way communication, whether the shown connection is a one-way or two-way arrow. Also, any blade shown in the figures can be a different device. For example, if a mobile device is shown sending information, information can also be sent using a wired device.

[0031] Furthermore, although the term "message" may be used in the description of embodiments, this application can be applied to many types of networks and data. Further, although certain types of connections, messages, and signaling may be shown in example embodiments, this application is not limited to those specific types of connections, messages, and signaling.

[0032] Example embodiments provide a method, system, component, non-transitory computer-readable medium, device, or network, or a combination thereof, for providing a security layer for constructing a blockchain network (also referred to herein as a blockchain).

[0033] In one embodiment, the system deploys and configures a decentralized database (such as a blockchain), which is a distributed storage system that includes a plurality of nodes that communicate with each other. The decentralized database includes an append-only and immutable data structure similar to a distributed ledger that can maintain records among untrusted parties. 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 unless consensus is obtained among the distributed peers. For example, a peer can execute a consensus protocol to verify storage transactions of a blockchain, group the storage transactions into blocks, and construct a hash chain for the blocks. Through this process, the ledger is formed by ordering the storage transactions as necessary to maintain consistency. In various embodiments, a permissioned blockchain or a permissionless blockchain or both can be used. In a public blockchain or a permissionless blockchain, anyone can participate without having a specific identity. A public blockchain can include native cryptocurrencies and can use consensus based on various protocols such as Proof of Work (PoW). On the other hand, a permissioned blockchain database provides secure interactions among groups of entities that share a common purpose but do not fully trust each other, such as enterprises that exchange funds, goods, information, etc.

[0034] A blockchain can operate any programmable logic, called "smart contracts" or "chaincode", adapted to a decentralized storage scheme. Optionally, there may be a dedicated chaincode for administrative functions and parameters, called system chaincode. This application can further utilize smart contracts, which are reliable decentralized applications that take advantage of the tamper-proof characteristics of the blockchain database and the underlying agreement between nodes called endorsement or endorsement policy. Blockchain transactions associated with this application can be "endorsed" before being committed to the blockchain, but those that are not endorsed are ignored. The endorsement policy enables the chaincode to specify an endorser for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed to verify it. After verification, the transaction enters an ordering phase, where an ordered sequence of endorsed transactions grouped into blocks is generated using a consensus protocol.

[0035] A blockchain can include nodes configured therein, which are communication entities of the blockchain system. A "node" can execute a logical function in the sense that multiple different types of nodes can operate on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control those nodes in various ways. Nodes can include different types such as clients or submitting client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., ordering nodes). Another type of node is a peer node that can receive transactions submitted by clients, commit the transactions, and maintain the state and a copy of the ledger of blockchain transactions. A peer can also act as an endorser, but that is not a mandatory requirement. An ordering service node or orderer is a node that executes a communication service for all nodes, commits transactions, and implements delivery guarantees such as broadcasting to each of the peer nodes in the system when modifying the world state of the blockchain, which is an alias for the initial blockchain transaction including normal control and configuration information.

[0036] A blockchain can include a ledger that is an ordered, tamper-resistant record of all state transitions of the blockchain. State transitions can result from chaincode calls (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each of the participating parties (such as peer nodes) can maintain a copy of the ledger. A transaction can result in a set of key-value pairs of assets committed to the ledger as one or more operations such as create, update, delete, etc. The ledger includes a blockchain (also called a chain) that is used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0037] (The) chain of a blockchain is a transaction log structured as hash-linked blocks, where each block contains N transaction sequences, where N is equal to or greater than 1. The block header includes the hash of the block's transactions, as well as the hash of the header of the previous block. As another example, in a DAG structure, a block includes the hash of the header of the parent block and the hash of the header of the source block. In this way, all transactions on the ledger can be ordered and cryptographically linked to each other. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the block within the most recently added blockchain represents all transactions that have occurred on the chain previously, making it possible to ensure that all peer nodes are in a consistent and trustworthy state. The chain can be stored in the file system of the peer nodes (i.e., local attached storage, cloud, etc.), efficiently supporting the append-only nature of the blockchain workload.

[0038] The immutable ledger current state represents the latest value for all keys included in the chain's transaction log. The current state, which represents the latest known key values for the channel, is sometimes referred to as the world state. Chaincode calls execute transactions against the ledger's current state data. To efficiently enable these chaincode interactions, the latest key values can be stored in a state database. The state database may simply be an indexed view into the chain's transaction log and can thus be regenerated from the chain at any time. The state database can be automatically restored (or, if necessary, generated) upon peer node startup and before transactions are accepted.

[0039] Exemplary embodiments are directed to a consensus protocol for a blockchain having a directed acyclic graph (DAG) format. In particular, the protocol can untangle DAG-formatted blocks and generate a sequential linear ordering of blocks that can be used for consensus among peer nodes within a blockchain network. However, rather than relying on timestamps (which are vulnerable to forgery), this protocol analyzes the DAG's structure to resolve implicit, redundant, and arbitrary relationships within the graph.

[0040] This approach is distinctive in that it can convert the DAG structure of blocks into a linear structure by examining only the structure of the DAG. Blocks are hash-linked to each other as in a conventional blockchain. However, in a DAG structure, by including the hashes of multiple blocks in the block header, a block can be directly / independently linked to more multiple blocks. The system described herein can convert the DAG block structure into a corresponding graph (referred to herein as an ordered graph) in which blocks are represented by nodes and links are represented by edges between nodes. Through the ordered graph, the conversion for nodes can be performed based on various conversions.

[0041] Exemplary embodiments can add blocks to the blockchain much faster than a conventional blockchain where blocks are in a continuous linear order from the start. This is achieved by enabling multiple peer nodes to add blocks in parallel without any hindrance. Having no hindrance means that no extra "proof-of-work" calculations that slow down the process (such as in a conventional blockchain like Bitcoin) are added to the process. Further, there is no need for a computer to "vote" on the addition. Instead, a set of computers operating in parallel "gossip", meaning they perform random pairwise connections in parallel among themselves. With each such connection, one block is created and added to the DAG of blocks. This process is much faster than relying on a proof-of-work or endorsement protocol, but ultimately, the "ribbon" of blocks is woven in a completely random way, making it difficult to determine the chronological order in which the blocks were created. This order is called the "consensus total order" and specifies the order of transactions (stored in the blocks) at the core of the blockchain.

[0042] Another approach to dealing with the process of untangling blocks in a DAG structure is to use the timestamps of each block to understand the chronological order. However, timestamps can be easily created, forged, manipulated, etc. illegally. Therefore, timestamps cannot be fully trusted unless an additional / complicated process of identifying a "good" set of timestamps is implemented. In contrast, exemplary embodiments identify the sequential order of blocks using only the structure of the DAG itself, which cannot be forged.

[0043] For example, a peer node can store the DAG chain of blocks. When receiving a consensus request, the peer node can convert the latest structure of the DAG into an ordered graph where blocks are represented by nodes and hash links are represented by edges between nodes. Note that the ordered graph can contain cycles and is not a DAG. The peer node can perform a transformation (e.g., addition or removal of edges) on the ordered graph that preserves the corresponding temporal relationships between blocks / nodes, but this also systematically reduces the number of edges between nodes. A block in the DAG can contain two edges (one to a parent node and one to an interrelated node / source) to two other blocks. However, in the full consensus order, only one edge remains between those two states. A transformation can be performed on the ordered graph structure such that the order of its nodes is converted into a linear structure that represents the temporal / linear order of the corresponding blocks of each node in the DAG. Further, once this is established, the nodes that are in the correct order at that point can be removed from the ordered graph as they no longer serve a purpose. Removing the ordered nodes prevents the ordered graph from growing larger than necessary.

[0044] Some of the advantages of the exemplary embodiments include improving the processing speed of the blockchain. In particular, the addition of new blocks to the blockchain (DAG) can be separated from the process of determining the total order of consensus of the blocks (i.e., by transforming the order graph). In particular, blocks can be added quickly as needed (by multiple different peers at once), and the ordering process can be performed separately and in parallel using a static analysis of the structure of the order graph. This combination is much faster than requiring a proof-of-work or endorsement protocol before a block can be added to the blockchain.

[0045] Peer nodes can execute the consensus protocol throughout the process of managing the blockchain. Peer nodes are performing different jobs such as accepting transactions, bundling transactions into blocks, and reaching a consensus (i.e., agreement) with other peers that are doing the same thing in parallel about how to order the blocks that everyone is creating. That consensus requires the execution of the consensus protocol. In practice / implementation, something happens only when a new block is added to the DAG and then it directly results in a new corresponding block in the order graph. When the block of the new order graph performs a transformation, that transformation is applied and the order graph is changed. As a result of the change, if there are no nodes preceding that node (i.e., nothing that comes before it in time) and only one node coming after it, that node can be removed from the order graph, and its position in the sequence of removed nodes becomes its position in the total consensus order (this is directly transformed into the position of the block in the DAG that the node represents in the total consensus order).

[0046] As described above, blockchains can generally be classified into two types, namely, permissionless and permissioned. Bitcoin and Ethereum, the first widely used blockchains, are both permissionless, which means that there is no central authority managing the peer-to-peer network that maintains the blockchain, and in fact, almost any peer can join the network and participate in its maintenance at any time. In contrast, in a permissioned blockchain, usually, the number of peers maintaining the blockchain is very limited, perhaps about a dozen, and it is owned and operated by specific known parties, and "permission" to maintain the blockchain is given by some central authority. These two types of blockchains tend to have very different methods for forming consensus, and as a result, their performance profiles also vary greatly. However, the consensus protocols of both types of networks require significant overhead work before a new block is stored in the ledger.

[0047] A third approach for determining consensus in a blockchain, applicable to both permissionless and permissioned blockchains, is to separate the extension of the blockchain from the determination of consensus. This idea is to achieve higher performance by allowing parallel addition of blocks to the "chain" with little or no artificial time delay or constraints. In this example, consensus can be determined concurrently and slightly post hoc by statically analyzing the relationships between blocks. This is facilitated by adopting a data structure slightly different from a pure blockchain for organizing the blocks, namely, a generalized directed acyclic graph (DAG). FIG. 1A shows a blockchain ledger 120 in DAG format according to an exemplary embodiment.

[0048] Referring to FIG. 1A, the blockchain network 100 includes a plurality of peer nodes 111-114 represented by peers A, B, C, and D, respectively. Using the consensus protocol described herein, the chain of DAG-formatted blocks on the blockchain ledger 120A can be untangled. The DAG protocol still uses cryptographic checksums to link blocks together, as in conventional blockchains, but can incorporate links to two or more blocks, not just the link to the immediately preceding block. For example, a new block can be appended to the "outermost" blocks of the DAG, creating a stable and immutable "core" of blocks that facilitates static analysis. In the example of FIG. 1A, each peer adds its own blocks to the DAG. In this example, peer 114 (also called peer D) adds four blocks, including D1, D2, D3, and D4, to the blockchain ledger 120A. Similarly, peer 113 (peer C) adds blocks C1, C2, and C3, peer 112 (peer B) adds blocks B1, B2, and B3, and peer 111 (peer A) adds blocks A1, A2, and A3.

[0049] Peers 111-114 can add new blocks to the DAG with very little overhead, typically no proof-of-work and no voting among peers 111-114. As a non-limiting example, in the "simplest" algorithm, peers 111-114 can append the addition and propagate it to other peers among peers 111-114. This configuration enables the simultaneous parallel expansion of the DAG by multiple peers, achieving much higher performance. Here, static analysis can be used to process the stable part of the DAG during its "leisure time" and classify the expansion order to generate a consensus total order. This approach has some latency (in seconds), but enables very high performance.

[0050] Instead of a continuous chain of blocks, by using a DAG without restrictions on the blockchain ledger 120A, peers 111 to 114 can effectively attach blocks at the locations considered optimal. Also, the DAG provides a path to a very high, potentially even theoretically maximum, scalability performance. However, this approach has two significant drawbacks. The first drawback is that the DAG created in this way can have a very complex set of block relationships. The second, more serious drawback is that ledgers utilizing such a structure may be more vulnerable to attacks. The more complex the DAG becomes, the more difficult it is to perform static analysis. This can increase the waiting time when calculating the consensus order from the DAG. Also, although not particularly a problem with the algorithm itself, the correct implementation of a complex static analysis algorithm is also a very difficult task. Finally, as the complexity increases, the likelihood of unexpected problems occurring in terms of security also increases.

[0051] One such problem is that, due to the lack of any kind of adjustment enforcement among peers expanding the DAG, malicious peers may collaborate among themselves without being noticed. The danger is that peers cooperate in the expansion of a part of the DAG for their own interests (for example, to perpetuate "double spend"). In an unrestricted DAG, since this expansion does not need to be immediately propagated to the remaining peers, it can be maliciously curated and introduced when the impact is maximized (that is, propagated to the rest of the peer-to-peer network). Attempts to mitigate these types of attacks have profound implications for the design and operation of the DAG, effectively converting some non-centralized (i.e., permissionless) ledgers into centralized (i.e., permissioned) ledgers. Limiting the expansion of the DAG while allowing free expansion by making the DAG contain more structure helps to address these problems.

[0052] Figure 1B shows another perspective of the blockchain ledger 120B where blocks are arranged corresponding to the peers that added the corresponding blocks to the blockchain ledger 120B. As shown in Figure 1B, the gossip DAG records the random connections made among the set of peers A - D participating in the gossip protocol (i.e., each peer randomly selects another peer and then contacts them to synchronize their respective data sets). The blocks of the gossip DAG contain the transactions placed there by the peer creating the block. The connections between peers are secure and the data exchanged (i.e., the blocks) are signed. The DAG may appear to be composed of parallel sets of conventional blockchains, as if one blockchain was organized to be "owned" by each of the peers A - D.

[0053] Here, peer C owns a "chain" consisting of blocks C1, C2, and C3, while peer A owns a chain consisting of blocks A1, A2, and A3. Each of the blocks within a particular peer's chain has a link to the block immediately preceding it within that chain. This block is called its parent, while the block is the child in that relationship. Not all blocks have a parent. For example, the blocks corresponding to nodes D1, C1, B1, and A1 of the blockchain ledger 120B do not have a parent block.

[0054] Each block typically has a different link to a block in the chain of a different peer. The link block of another chain is called the source block. A block can only be the parent of one other block, but can also be the source block of more than one, for example, block B2 in blockchain ledger 120B is the parent of block B3 and the source block of blocks A3 and C3. As described above, blocks in the gossip DAG are created when one peer contacts another peer. For example, block D2 was created when peer A contacted peer D. When the connection is made, peer A can send the cryptographic hash value of block A1 (source block) to peer D. Next, peer D creates block D2 and includes in block D2 the cryptographic hash values for block A1 and block D1 (parent block).

[0055] When two peers communicate, they can exchange blocks of the DAG that are missing from the other peer. This can be achieved by the initiating peer sending an instance of a block count vector (BCV) that summarizes the maximum index of the blocks belonging to each peer. The receiving peer compares the values with its own and responds with all the blocks it has that the other does not have and its BCV value, and if possible, with the appropriate missing blocks. As an example, the very first BCV sent during the first synchronization from peer A to peer B summarizes the view of peer A of the gossip DAG, which is that peer A has a single block (A1, the just-created genesis block described below) and as far as it knows, the other three peers have zero ("0") blocks (true). In addition to the BCV, peer A can also proactively send block A1, which is the source block, to peer B. Generally, it should be noted that it is possible but rare for the receiving peer to already have the source block, which is the case when it has received two consecutive contacts from the same peer without contacting that peer in between two exchanges.

[0056] When Peer B receives BCV and Block A1 from Peer A, it adds Block A1 to its collection and then creates Block B1. Next, Peer B creates its own BCV, summarizes the view of the gossip DAG, and compares it with what it received from Peer A. The difference between the two BCVs (basically vector subtraction) identifies the blocks that Peer B has in the gossip DAG but Peer A does not (answer: Block B1). In this example, Peer B replies to Peer A with its BCV and Block B1. When Peer A receives the response from Peer B, Peer A integrates any blocks it receives from Peer B (in this case only Block B1), and then recalculates the BCV with the new blocks. It then prepares a response, the purpose of which is to provide Peer B with any gossip DAG blocks that Peer A has but Peer B does not. Again, this is revealed by calculating the difference between the two BCV vectors, but in this case there is no difference, so there are no blocks to send to Peer B. The absence of blocks to transfer does not affect Peer A's actions, and Peer A still sends a response to Peer B in a state where there are no blocks. After the completion of that response, the gossip exchange between the two peers is complete.

[0057] The blockchain consensus algorithm described in this specification utilizes the characteristics of the gossip DAG, with some customizations. For example, all blocks within the gossip DAG can trace a path to a single genesis block (A1). This block is created as part of an initialization process by a designated single peer (Peer A). On the other hand, after initialization, other peers still do not refer to any other blocks. Gossip starts from the peer that created the genesis block, and only that peer randomly contacts another peer. That peer creates a new block referring to the genesis block as the source along the gossip protocol, leaving the parent reference empty (since there is no parent block to refer to). After synchronization, the second peer now has its own block and can involve the first peer in the start of gossip connections to other peers. By contacting each peer and then creating a new block that functions as the source block, other peers can be involved in the gossip.

[0058] Since the path to the genesis block can be directly extracted from the structure of the gossip DAG, the actual first block, i.e., the one that comes before all other blocks in the consensus total order, is required. Note that the actual time when the block was created is not part of the ordering process. In other words, the protocol here does not require timestamp information. At first glance, the gossip DAG appears random and unstructured. This is a relatively accurate assessment, as the blocks and their interconnecting edges are created randomly and do not follow a specific pattern, except that each new block always refers to the latest blocks of both its parent peer and the source peer. This one characteristic enables the extraction of a semantically consistent temporal order of the blocks within the gossip DAG directly from its structure. This is achieved by recognizing the entire range of relative temporal relationships encoded in the gossip DAG structure and using it to generate a total ordering of all blocks that is consistent with those relative relationships.

[0059] There are four types of relative temporal order relationships encoded in the gossip DAG: explicit, implicit, arbitrary, and redundant. An explicit relationship is one that is directly represented by an edge from one block to another. For example, in FIG. 1B, block D2 is temporally after blocks D1 and A1 because there are directed edges from block D2 to each of the other two blocks.

[0060] Implicit temporal relationships are, of course, more subtle. The most obvious are transitive temporal relationships. For example, if block A has an edge to block B and block B has an edge to block C (i.e., A→B→C), there is an implicit relationship between block A and block C (block A was created after block C). As an example, in FIG. 1B, there is an implicit temporal relationship between block D3 and block D1. The gossip DAG also includes another type of implicit temporal relationship related to the dual role played by blocks that function as both parents and sources. This relationship is further explained with reference to FIGS. 4A - 4E when discussing the parent transform.

[0061] An arbitrary temporal relationship between two blocks in the gossip DAG is one where no explicit or implicit temporal order is represented. These arbitrary relationships allow a certain degree of flexibility that can be used to simplify the relationships and are useful when determining the total order of the blocks. Arbitrary temporal relationships are difficult to directly identify in the gossip DAG and usually need to have their implicit relationships made explicit by transformations in the order graph before they become more obvious.

[0062] A redundant temporal relationship exists when there is more than one path between blocks. For example, block A has an edge to block B, block B has an edge to block C, and furthermore, block A also has an (redundant) edge to block C (i.e., A→B→C&A→C). In this example, the redundant edge between A and C can be removed. Compared to a total order, the gossip DAG has approximately exactly twice as many edges (since each first block of each peer has no parent block, there is only one edge each that is not removed, so it is not exactly twice). In particular, new blocks refer to a parent block within the chain of the same peer and a source block within the chain of another peer. Therefore, when creating a sequential order of blocks, it is necessary to remove approximately half of the edges before creating a consensus total order.

[0063] A solution to the problem of efficiently extracting a consensus total order for a set of transactions from the recorded gossip protocol exchanges between a set of collaborating peers is to use the gossip DAG of blocks to create a record of the gossip connections made, and then use a second modifiable graph (referred to herein as an order graph) to transform the structure of that record into a linear one while preserving the semantics of the temporal relationships contained therein.

[0064] FIG. 1C shows a process of converting the blockchain ledger 120B of the DAG-formatted blocks on the blockchain of FIG. 1B into an ordered graph 130A according to an exemplary embodiment. In this example, the ordered graph 130A replaces nodes with blocks. Further, the links between blocks are represented by edges. The ordered graph 130A is essentially a DAG-formatted clone of the blocks on the blockchain ledger 120B. However, unlike the positions of the blocks on the blockchain, the ordered graph 130A can be manipulated to perform conversions. The ordered graph 130A is a modifiable graph, and its content is extracted from the gossip DAG, the set of transformation accessories, and a method of continuously making the structure of the ordered graph 130A more linear until the nodes of the second graph form a linear sequence as shown in the ordered graph 130B shown in FIG. 1D, where the consensus total order of the blocks in the gossip DAG corresponds.

[0065] The process of extracting the total order from the gossip DAG is similar to pulling a single thread from a randomly woven ribbon, where the ribbon is the gossip DAG and the thread is the consensus total order in the ordered graph 130B as shown in FIG. 1D. As will be further described below with respect to FIGS. 4A - 4E, multiple transformations are performed on the ordered graph, and an "untangling pipeline" is created where the blocks and edges of the gossip DAG enter at one end at creation and the total order exits from the other end.

[0066] The form of this pipeline is that of a second derived graph called an ordered graph, which consists of nodes (not blocks) that function as proxies for blocks within the gossip DAG. One "end" of the ordered graph tracks the expansion of the gossip DAG by creating new nodes and appropriate edges each time a new block is added to the gossip DAG. The other "end" of the ordered graph is a linear sequence of nodes arranged in a consensus total order that matches the temporal relationships of the gossip DAG. In between, the ordered graph undergoes a systematic transformation that maintains temporal relationships, making implicit relationships explicit, leveraging any relationships, and removing redundancy.

[0067] In practice, the consensus total order is not maintained as a complete list as shown to appear intact from the ordered graph 130B. Instead, once the nodes are arranged in total order, since the positions of the corresponding blocks within the gossip DAG are determined, the corresponding nodes of the ordered graph are no longer needed. Therefore, they can be discarded. As a result, in practice, the ordered graph will contain only a small number of nodes relative to the number of blocks in the DAG, since nodes are removed once they are arranged in the consensus total order.

[0068] The gossip protocol can occur between peers that are essentially "permissioned blockchains". The gossip DAG can be thought of as a parallel set of blockchains, one for each peer, with (random) interconnectivity between them. Each of these parallel blockchains is exclusively extended by one of each of the peers, but each peer has all copies of the parallel blockchains (which is what constitutes the gossip DAG). A block is created by a peer with its exclusive modification when another peer makes a (random) connection to that block. At that time, the peer selects a set of transactions that the peer has put in its cache to create the block, puts two hash values in the block header, one is the hash value for the block that advances this block in the peer's exclusive blockchain (that hash value effectively chains the block), and the other is the hash value sent to it from a peer that has (randomly) communicated with it. That hash value is that of the most recent block in the sender peer's exclusive blockchain. In this way, a peer cannot create a block until another peer communicates with that peer.

[0069] This process can be "bootstrapped" by designating one of the peers as the "starting peer", which means creating the first block (genesis block) by itself without communicating, and then randomly selecting one of the other peers to communicate with and providing the hash value of the genesis block in that process. The other peer can create a block and, if necessary, add any transactions to that block (including not adding any at all), and can store a null hash value (because there is no hash value) for the previous block in the exclusive blockchain and the hash value of the received genesis block. At this point, both peers can repeat this process, but a peer that still does not have a block in its exclusive blockchain may have to wait to communicate because it cannot provide a hash value to any other peer that can communicate until it creates its first block.

[0070] Whenever two peers communicate with each other, they also exchange as much gossip DAG as necessary so that both have the same set of blocks. In this way, the gossip DAG propagates among peers. It is clear that each peer has its own evolving copy of the gossip DAG and its own evolving copy of the ordered graph. Although it may not be obvious, the DAG is extended in parallel with the addition of new blocks that are not instantaneously propagated to all peers, so each peer is expected to have a slightly incomplete version of the gossip DAG at any given point in time.

[0071] Figure 2 shows a blockchain architecture configuration 200 according to an exemplary embodiment. Referring to FIG. 2, the blockchain architecture 200 can include certain blockchain elements, such as a group of blockchain nodes 202. The blockchain node 202 can include one or more nodes 204-210 (these four nodes are shown as merely examples). These nodes participate in a number of activities such as the addition and verification process (consensus) of blockchain transactions. One or more of the blockchain nodes 204-210 can endorse a transaction based on an endorsement policy and provide an ordering service to all blockchain nodes within the architecture 200. The blockchain node can initiate blockchain authentication and attempt to write to the immutable blockchain ledger stored in the blockchain layer 216, and a copy thereof can also be stored on the underlying physical infrastructure 214. The blockchain configuration can include one or more applications 224 linked to an application program interface (API) 222 to access and execute the stored program / application code 220 (e.g., chain code, smart contract, etc.), which may be created according to a customization configuration required by the participants, maintain its own state, control its own assets, and can also receive external information. This can be deployed as a transaction and installed on all blockchain nodes 204-210 via append to the distributed ledger.

[0072] The blockchain-based or platform 212 can include various layers of blockchain data, services (such as cryptographic trust services, virtual execution environments, etc.), and the underlying physical computer infrastructure, and these layers can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 can expose an interface that processes program code and provides access to the virtual execution environment necessary to participate in the physical infrastructure 214. The cryptographic trust service 218 can be used to verify transactions such as asset exchange transactions and keep information private.

[0073] The blockchain architecture configuration of FIG. 2 can process and execute program / application code 220 via one or more exposed interfaces and provided services by the blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transfer data and can also be executed by nodes 204-210 in the form of chain code associated with smart contracts and the conditions or other code elements for their execution. By way of non-limiting example, smart contracts can be created to execute reminders, updates, or changes, other notifications such as updates, or combinations thereof. Smart contracts can use themselves to specify authorization and access requirements and the rules associated with the use of ledgers. For example, the read set 226 can be processed by one or more processing entities (such as virtual machines) included within the blockchain layer 216. The write set 228 can include the results of processing the read set 226 via one or more smart contracts. The physical infrastructure 214 can be utilized to retrieve any of the data or information described herein.

[0074] Smart contracts can be created by high-level applications and programming languages and then written into the blocks within a blockchain. A smart contract can include executable code that is registered, stored, or replicated, or a combination thereof, by a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that can be executed in response to conditions associated with the smart contract being met. The execution of a smart contract can trigger a reliable modification to the state of the digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of a smart contract can be automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

[0075] Smart contracts can write data to a blockchain in the form of key-value pairs. Further, the code of a smart contract can read values stored in the blockchain and use them in application operations. The code of a smart contract can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures within a virtual machine or other computing platform. The data written to the blockchain can be made public, or encrypted and made private, or a combination thereof. Temporary data used / generated by a smart contract is held in memory by a given execution environment and then deleted when the data required by the blockchain is identified.

[0076] The chain code can include the code interpretation of the smart contract along with additional functions. As described herein, the chain code can be program code deployed on a computing network that is executed and verified together by a chain validator during the consensus process. The chain code receives a hash and retrieves from the blockchain a hash associated with a data template created by using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chain code sends an authentication key to the requested service. The chain code can write to the blockchain data associated with the details of the encryption.

[0077] FIG. 3A shows an example of a permissioned blockchain network 300 featuring a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 302 can initiate a transaction for the permissioned blockchain 304. In this example, the transaction can be a deployment, a call, or a query, and can be issued directly through a client-side application using the SDK, such as via an API. The network can provide access to a regulator 306, such as an auditor. The blockchain network operator 308 manages the permission of members, such as registering the regulator 306 as an "auditor" and registering the blockchain user 302 as a "client". The auditor may be restricted to only querying the ledger, while the client may be granted the right to deploy, call, and query a specific type of chain code.

[0078] Blockchain developers 310 can write chain codes and client-side applications. Blockchain developers 310 can directly deploy chain codes to the network through an interface. To include credentials from a conventional data source 312 within the chain code, developers 310 can use out-of-band connections to access the data. In this example, blockchain user 302 connects to a permissioned blockchain 304 through peer node 314. Peer node 314 retrieves the user's registration and transaction certificates from a certification authority 316 that manages the user's roles and permissions before proceeding with any transaction. In some cases, the blockchain user may have to possess these digital certificates to conduct transactions on the permissioned blockchain 304. On the other hand, users attempting to utilize the chain code may be required to verify their authentication information on the conventional data source 312. To confirm the user's authorization, the chain code can use an out-of-band connection to this data through a conventional processing platform 318.

[0079] Figure 3B shows another example of a permissioned blockchain network 320 characterized by a distributed, non - centralized peer - to - peer architecture. In this example, blockchain users 322 can submit transactions to a permissioned blockchain 324. In this example, the transactions can be deployments, calls, or queries and can be issued directly, such as via an API, through a client - side application that utilizes an SDK. The network can provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering the regulator 326 as an "auditor" and registering the blockchain users 322 as "clients". The auditor may be restricted to only ledger queries, while the client may be granted the right to deploy, call, and query specific types of chaincode.

[0080] Blockchain developers 330 write chaincode and client - side applications. Blockchain developers 330 can directly deploy chaincode to the network via an interface. To include authentication information from a conventional data source 332 in the chaincode, developers 330 can access the data using an off - band connection. In this example, blockchain users 322 connect to the network through peer nodes 334. Peer nodes 334 retrieve user registration and transaction certificates from a certificate authority 336 before proceeding with any transaction. In some cases, the blockchain user may have to possess these digital certificates to conduct transactions on the permissioned blockchain 324. On the other hand, a user attempting to utilize the chaincode may be required to verify that authentication information on a conventional data source 332. To confirm user authorization, the chaincode can use an off - band connection to this data through a conventional processing platform 338.

[0081] In some embodiments, the blockchain herein can be a permissionless blockchain. In contrast to a permissioned blockchain that requires permission to participate, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user can create a personal address and start interacting with the network by submitting a transaction, and thus adding an entry to the ledger. Further, all parties have the option of running nodes on the system and adopting a mining protocol to assist in verifying transactions.

[0082] Figure 3C shows a process 350 in which a transaction is processed by a permissionless blockchain 352 that includes a plurality of nodes 354. A sender 356 wishes to send a payment or some other form of value (e.g., a certificate, a medical record, a contract, a good, a service, or some other asset that can be encapsulated in a digital record) to a recipient 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the recipient device 358 can have a digital wallet (associated with the blockchain 352) that provides user interface control and display of transaction parameters. In response, the transaction is broadcast to the nodes 354 across the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes verify 360 the transaction based on rules established by the creator of the permissionless blockchain 352 (which may be pre-defined or dynamically assigned). For example, this can include verifying the identities of the parties involved. The transaction can be verified immediately or queued with other transactions, and the nodes 354 can determine whether the transaction is valid based on a set of network rules.

[0083] In structuring 362, valid transactions are formed into blocks and sealed with a lock (hash). This process can be executed by the mining nodes within node 354. The mining nodes can utilize additional software dedicated to the mining and creation of blocks for the permissionless blockchain 352. Each block can be identified by a hash (e.g., a 256-bit number, etc.) created using an algorithm for which consensus has been obtained by the network. Each block can include a header, a pointer or reference to the hash of the header of the previous block 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 and independent chain of blocks.

[0084] Before a block can be added to the blockchain, the block must be verified. Verification for the permissionless blockchain 352 can include a proof-of-work (PoW) which is a solution to a puzzle obtained from the block's header. Although not shown in the example of Figure 3C, another process for verifying a block is proof-of-stake. Unlike proof-of-work where the algorithm rewards the miner for solving a mathematical problem, in proof-of-stake, the creator of a new block is selected in a deterministic manner according to the wealth, also defined as "stake". Then, a similar proof is performed by the selected node.

[0085] In mining 364, the node attempts to solve the block by making incremental changes to one variable until the solution meets the network-wide target. This creates the PoW, thereby guaranteeing the correct answer. In other words, the potential solution must prove that computing resources were consumed in solving the problem. In some types of permissionless blockchains, rewards (e.g., coins, etc.) can be given to the miner for correctly mining the block.

[0086] Here, in the PoW process, compared with the block chain, it is extremely difficult to modify the blockchain because for an attacker to accept the modification of one block, all subsequent blocks must be modified. Further, when a new block is mined, the difficulty of modifying the block increases, and the number of subsequent blocks also increases. In Distribution 366, the properly verified blocks are distributed through the permissionless blockchain 352, and all nodes 354 add the blocks to the majority of chains that are an auditable ledger of the permissionless blockchain 352. Further, the value of the transaction submitted by the sender 356 is deposited into the digital wallet of the recipient device 358 or transferred in some other way.

[0087] FIG. 4A shows an order graph 400A corresponding to the order graph 130A shown in FIGS. 1C and 1D. The conversions described with respect to FIGS. 4B-4E show how the order graph 400A shown in FIG. 4A becomes an order graph 400E having a continuous linear order as shown in FIG. 4E. The conversion is based on the structure of the order graph 400A including nodes 402 and edges 404 representing blocks and hash links between blocks within the DAG blockchain, respectively.

[0088] The order graph can be modified by applying three conversions that preserve the relative temporal order, including a parent conversion, a cycle conversion, and a path conversion. The parent conversion serves to make implicit relationships explicit. The cycle conversion serves to remove any order relationships caused by the gossip protocol (e.g., to identify which block should be placed first when two peers communicate with each other simultaneously and two blocks are created, etc.). Similar to the cycle conversion, the path conversion serves to remove any temporal relationships arising from unrelated but parallel paths within the graph. Also, the path conversion serves to remove redundant edges by identifying and removing multiple paths between nodes.

[0089] Figure 4B shows a process 410 for performing a parent transformation on nodes within an ordered graph 400A according to an exemplary embodiment to create a modified ordered graph 400B. In a gossip DAG, the relationships between blocks created as a result of the gossip protocol are explicitly represented. For example, a block created to record a gossip connection to a certain peer has an edge to its parent block (created for a previous connection to this peer) and an edge to its source block (owned by the starting peer). Referring to FIGS. 4A and 4B, one block can function as both a parent block and a source block. For example, block B2 within ordered graph 400A is the parent of block B3 and the source of blocks C3 and A3. In this case, the parent block B2 is (obviously) older than the other nodes that reference it. However, there is a temporal relationship that is not represented in the gossip DAG between the child block (B3) and each of the blocks (C3 and A3) that have the parent block (B2) of that child block as a source block.

[0090] A block that is a source block can be the source block for not just one, but many separate gossip connections. However, it becomes a parent block only when another peer starts a connection to the peer of the parent block. This connection creates the child block of that parent. Once the child block is created, the parent block is no longer the source node for future connections, and the newly created child block replaces it in that role. That is, all child blocks are implicitly created after the blocks that use the parent block as a source block (i.e., block B3 is created after blocks C3 and A3).

[0091] The parent transformation shown in FIG. 4B modifies the order graph to make this implicit temporal relationship explicit. Here, the parent transformation can add the edges 414 from each child node to each other node that refers to the child node's parent node as its source node. To avoid introducing redundancy, the parent transformation also modifies the order graph by removing the edges 412 from the child nodes to their parent nodes, since their temporal relationship (the child comes after the parent) is still implicitly transitively represented in the order graph by the path from the child, through the new edge, to the node that uses the parent as its source, and then to the parent node. FIG. 4B shows a parent transformation where child node C has a relationship with parent node P and node X has a relationship with parent node P (P is its source node). In the parent transformation, the edge 412 from node C to node P is removed and replaced with an edge 414 from node C to node X. Further, the result of applying the parent transformation to the original order graph 400A shown in FIG. 4A is shown in the modified order graph 400B shown in FIG. 4B. Here, the newly added horizontal edges are represented by dashed lines, and the edges between pairs of parent and child nodes such as between D2 and D1, between C3 and C2, between B3 and B2, between A3 and A2, and between A2 and A1 are removed. When making changes to the original order graph 400A, the parent transformation creates / makes explicit a cycle (i.e., a loop) between nodes C3 and B3. Further, although less obvious in the tangle of edges, there is another cycle created by the parent transformation that links nodes D2, C2, B2, and A2.

[0092] Figure 4C shows a process 420 for creating a modified ordered graph 400C by performing cycle conversion on nodes in the ordered graph 400B according to an exemplary embodiment. The gossip DAG, which is a directed acyclic graph, of course does not include any cycles, and even if new nodes and edges are created in the ordered graph in accordance with the expansion of the gossip DAG, cycles are not directly introduced into the ordered graph. However, the ordered graph can have cycles created as part of the conversion process. The cycles in the ordered graph are brought about by the application of the aforementioned parent conversion, which makes implicit temporal relationships explicit. The knowledge underlying the formation of the cycle is to capture the parallel creation of blocks in the DAG brought about by peers performing simultaneous connections. By applying the parent conversion, new edges are created between nodes in the ordered graph that have the same relative relationship as the parent / source node, thus manifesting periodic temporal dependencies.

[0093] Referring to Figure 4C, a cycle is composed of a set of nodes where the relative order is arbitrary, and occurs when two peers simultaneously start a gossip connection with each other (i.e., A → B & B → A), or when more than two peers start a gossip connection in a "circular manner". An example of the latter scenario with a cycle of four nodes, i.e., A → B → C → D → A, is shown in Figure 4C. The nodes in a cycle in the ordered graph are essentially temporally equal, which means that their order is arbitrary with respect to each other. The cycle conversion addresses this situation by "removing" the nodes in the cycle from the ordered graph and aggregating them to be replaced by a single cycle node 422. The edges in the ordered graph to any one of the nodes in the cycle are now changed to refer to the new cycle node 422.

[0094] The new cycle nodes 422 maintain references to the nodes forming the cycle and are thus available later when the positions of the cycle nodes are determined in a total order. At that point, the nodes within the cycle are deterministically placed in a relative order with respect to each other and then, in that order, replace the cycle nodes in the total order. This example is shown in FIG. 4C, where nodes C3 and B3 are converted to cycle node 424 and nodes D2, C2, B2, and A2 are converted to cycle node 426, creating a modified ordered graph 400C. Before finally resolving the order of the nodes encapsulated by these cycle nodes 424 and 426, the peers can perform additional conversions until the redundant paths to cycle nodes 424 and 426 are removed. At that point, the nodes encapsulated by cycle nodes 424 and 426 can be placed in relative order and then inserted into the consensus total order, as further explained with respect to FIG. 4E.

[0095] FIG. 4D shows a process 430 for performing path conversions on the nodes in ordered graph 400C to create a modified ordered graph 400D, according to an exemplary embodiment. Path conversion serves to remove both redundant temporal relationships and any arbitrary temporal relationships from the ordered graph. A redundant temporal relationship is one that explicitly specifies the temporal order between two nodes X and Z (i.e., by having an edge from X to Z) and is also transitively represented by a longer path that exists within the ordered graph between nodes X and Z (the longer path is retained because it contains the most temporal relationship information). An arbitrary temporal relationship is represented by a parallel path between nodes that results from the randomness of the connections made by the gossip peers. In the example of FIG. 4D, there are two redundant paths between nodes X and Z. Specifically, there is a path through edge 431 and a second path through edge 432, 433, and node Y.

[0096] In this example, the edge 431 from node X to node Z indicates that node X is temporally after node Z. Similarly, the edge 433 from node Y to node Z indicates that node Y is also temporally after node Z, and the edge 432 from node X to node Y indicates that node X is temporally after node Y. The edge 431 from node X to node Z can be removed without losing the information that temporally X is after Z (i.e., X→Y→Z). This transformation is basically half of the parent transformation that removes redundant edges between a parent node and a child node, and the other half adds edges between the child node and the nodes that reference its parent as their source node, so it should be familiar. The parent transformation can be "simplified" by leaving the edges from child to parent intact so that the path transformation will remove them later, but simply removing the ordered graph rather than reprocessing it with the path transformation to rediscover redundancy is an obvious optimization.

[0097] In the process 430 of FIG. 4D, a path transformation can be applied to remove all redundant paths shown in the ordered graph 400C to create a modified ordered graph 400D. In particular, after the cycle transformation, the ordered graph 400C had a significant number of redundant relationships that the path transformation directly removed. For example, the edge of the cycle node 426→A1 is redundant due to the path of the cycle node 426→B1→A1, and thus can be removed. At the same time, the cycle node 426→B1 is also redundant due to the path of the cycle node 426→C1→B1, and thus can be removed. Not only that, the edge between the cycle nodes 426→C1 is also redundant due to the path of the cycle node 426→D1→C1, and can be removed in the same way. As a result, a single edge remains from the non-redundant cycle node 426→D1, retaining the path of the cycle node 426→D1→C1→B1→A1 that materializes all the temporal relationships between those nodes. Similar transformations can be performed on the cycle node 424 and other redundant paths, resulting in a modified ordered graph 400D.

[0098] The result of the sequential graph 400D is a linear sequence of nodes starting from node D4 and continuing to node A1, which is almost the consensus total order. The only remaining step is to resolve the order of the nodes within the two cycle nodes 424 and 426. For example, since all of the nodes D2, C2, B2, A2 within cycle node 426 come after node D1 and before node D3, the system can arbitrarily sort them in ascending relative checksum number order (the smallest first) and return the nodes to their places within cycle node 426. The same can be done for the nodes C3 and B3 within cycle node 424. The result is shown in Figure 4E, and as a result, a modified sequential graph 400E representing the consensus total order is obtained.

[0099] The algorithm for arbitrarily ordering the nodes within a cycle can, by default, simply be specified to "sort" the blocks by their hash values. This is arbitrary, difficult to operate, and reproducible by different peers to obtain exactly the same result, but other techniques can also be used. In some embodiments, the algorithm used can be selected at configuration time before any peer is executed (and all peers have the same configuration). One way to do this is to use a programming framework that supports "dependency injection". The idea is to execute a bit of initialization code from the framework at the start of code execution, examine the current configuration, and then create an instance of the selected algorithm. Then, using special techniques, the code that uses the algorithm is modified to obtain a reference to the algorithm selected by the configuration and created by the framework. This is called dependency injection because the "dependency" (the algorithm) is "injected" into the code that uses it. This is a very flexible and powerful technique.

[0100] Although not shown in FIGS. 4A - 4E, in some cases, the gossip protocol can create independent parallel time dependencies, which means that a sequence of blocks that has no relationship between the collections of blocks can exist in the gossip DAG, and thus the order of the sequence is arbitrary. This is basically an extended version of the scenario of a simultaneous parallel gossip connection that ultimately results in a cycle in the ordered graph, except that in this case, it results in independent parallel paths in the ordered graph.

[0101] Parallel paths in the ordered graph represent redundancy and need to be resolved to determine the final consensus total order. Parallel paths can also represent temporal equivalence, which means that blocks are created "simultaneously" in the gossip DAG. Blocks on two different parallel paths have no edges between them, so there is no way to directly associate them for the relative position of the consensus total order, and they need to be considered temporally equivalent. This is the same situation as when a block within a cycle cannot choose one of the previous blocks.

[0102] One way to process parallel paths is to actively detect (i.e., search for) them in the ordered graph and then, in the simplest case, remove a single edge representing the shortest path or, as is done for cycles, extract the nodes / paths and replace them with a single aggregated node. However, this consumes significant processing cycles to traverse the different paths that may exist in the ordered graph to find paths that happen to be parallel, and the solution can become complex if there are parallel paths. Another more efficient approach is to leave the parallel paths in the ordered graph until the point at which the blocks are emitted from the graph in a consensus total order. At that point, due to the nature of the parallel paths, it simplifies and becomes clear which blocks are temporally equivalent and which are not. Blocks that are at the same (indeterminate) temporal position can be extracted and replaced with a single aggregated block (as is done for cycles). When that aggregated block is emitted from the ordered graph, the blocks it represents are placed in the consensus total order in the same way as the aggregated cycle blocks.

[0103] The process of emitting a block from the ordered graph as the next block in the consensus total order starts with a designated consensus candidate that is a single block having only the edges entering it in the ordered graph, which means that all other blocks come after it in the consensus temporal order. A block can be emitted from the ordered graph when there is only a single block in the ordered graph that has an edge to it. That block then becomes the new consensus candidate. If there are parallel paths in the ordered graph, there will be consensus candidates with multiple input edges. At this point, the parallel paths can be resolved.

[0104] Solutions can be achieved by acting based on simple observations. For example, blocks having an edge to a consensus candidate can be divided into two groups: those having only one single edge (the one to the consensus candidate) and those having more than one edge. Blocks having edges to more than one block also have more than one path to the consensus candidate block (by following those other edges). Among those edges, the edge directly incident to the consensus candidate must be the shortest (length 1), so it is redundant (a longer path is preferred) and can be removed from the order graph. Blocks within the former group, i.e., blocks having only a single edge incident to the consensus candidate, are temporally equivalent blocks. These blocks are extracted from the order graph and aggregated in the same way as the blocks within the cycle were used.

[0105] Once the extraction and replacement are complete and all edges in the order graph are updated to reflect the changes, at that point, only a single block, i.e., the new aggregated block, follows the consensus candidate block, and it can be released from the graph. Then, next, the new aggregated block becomes the new consensus candidate block, and this process is repeated.

[0106] Figure 5 shows a method 500 for determining a consensus order from a blockchain in DAG format according to an exemplary embodiment. Referring to Figure 5, at 510, the method can include receiving a chain of blocks from a blockchain that includes a directed acyclic graph (DAG) format in which blocks are hash-linked independently to multiple blocks. Each block can be linked to a parent block. Further, a block can also be linked to other blocks that are not parents within the blockchain having a DAG format. Here, a block includes the hash value of the parent block and the hash values of other blocks, whereby the block can be independently linked to multiple other blocks within the chain. To manipulate the order of the blocks, the system can convert the blocks arranged in DAG format into a corresponding graph of nodes connected by edges to represent the linked relationships between the corresponding blocks. In some embodiments, the chain of blocks in DAG format can include multiple subsets of a linear chain of blocks of multiple peers, and the multiple subsets of the linear chain of blocks include the interconnections between them.

[0107] At 520, the method can include identifying the temporal relationships between blocks within the chain of blocks based on the structure of the chain of blocks in DAG format. For example, the temporal relationships can be determined based on structural transformations within the graph of nodes based on the implicit relationships between the nodes. The implicit relationships can be detected from the structure of the nodes themselves rather than relying on timestamps that lack consistency and are vulnerable to forgery. The DAG graph of nodes can be converted into a linear graph of nodes based on various transformations including parent transformations, cycle transformations, and path transformations.

[0108] In some embodiments, identifying can include cloning the blockchain of blocks or, alternatively, converting the blockchain of blocks into a chain of nodes on a DAG-form graph having edges between the nodes representing hash links between the blocks. In this example, identifying the temporal relationship can include identifying the temporal relationship based on the structure of the edges between the nodes on the graph. In some embodiments, identifying can include transforming the parent relationship on the graph by adding the edges from the child nodes to the nodes linked to the parent nodes of the child nodes and removing the edges between the child nodes and their parent nodes.

[0109] In some embodiments, identifying can include transforming cyclical nodes (having edges that create a complete loop) on the graph by aggregating nodes having the same relative temporal relationship into a single cycle node that encompasses the aggregated nodes. In some embodiments, transforming the cycle node can include creating an order among the aggregated nodes encompassed within the single cycle node based on a predefined protocol. In some embodiments, identifying can include identifying two different paths between a pair of nodes on the graph and removing the shorter of the two different paths between the pair of nodes.

[0110] At 530, the method can include determining a sequential linear order of a chain of blocks in DAG form based on the identified temporal relationships, and at 540, the method can include storing the sequential linear order of the chain of blocks. Thus, the method can untangle the DAG form into a linear form as in a conventional block sequence on a blockchain. In some embodiments, the method can further include performing a blockchain consensus process at a plurality of peer nodes based on the sequential linear order of the chain of blocks. For example, a blockchain node performing method 500 can perform a consensus process and provide the linear order of the chain of blocks to verify that the blockchain node is part of the blockchain and that its ledger is complete.

[0111] FIG. 6A shows an exemplary system 600 including a physical infrastructure 610 configured to execute various operations according to an exemplary embodiment. Referring to FIG. 6A, the physical infrastructure 610 includes a module 612 and a module 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on blockchain 620) and can execute any of the operational steps 608 (within module 612) included in any of the exemplary embodiments. Steps / operations 608 can include one or more of the embodiments described or illustrated and can represent output read / written or information written between one or more smart contracts 630 or blockchain 620 or both. The physical infrastructure 610, module 612, and module 614 can include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Further, module 612 and module 614 can be the same module.

[0112] Figure 6B shows another exemplary system 640 configured to perform various operations according to an exemplary embodiment. Referring to Figure 6B, system 640 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which may reside on blockchain 620) and can perform any of the operation steps 608 (within module 612) included in any of the exemplary embodiments. Step / operation 608 can include one or more of the embodiments described or shown and can represent an output or written information that is read and written between one or more smart contracts 630 or blockchain 620 or both. Physical infrastructure 610, module 612, and module 614 can include one or more computers, servers, processors, memories, or wireless communication devices or combinations thereof. Further, module 612 and module 614 can be the same module.

[0113] Figure 6C shows an exemplary system configured to utilize a smart contract configuration between contracting parties and a mediation server configured to enforce smart contract terms on a blockchain. Referring to Figure 6C, configuration 650 can represent a process or procedure driven by a communication session, an asset transfer session, or a smart contract 630 that explicitly identifies one or more user devices 652 or 656 or both. The execution, operation, and results of smart contract execution can be managed by server 654. The content of smart contract 630 may require digital signatures by one or more of entities 652 and 656 that are parties to the smart contract transaction. The results of smart contract execution can be written to blockchain 620 as a blockchain transaction. Smart contract 630 resides on blockchain 620, and blockchain 620 can reside on one or more computers, servers, processors, memories, or wireless communication devices or combinations thereof.

[0114] FIG. 6D shows a system 660 including a blockchain according to an exemplary embodiment. Referring to the example of FIG. 6D, an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contract 630 or other chain code) and data (e.g., 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 entities 652 and 656 to a blockchain peer (i.e., server 654). Here, the server 654 not only holds a copy of the world state and a distributed ledger that enables clients 652 and 656 to query the data of the world state, but also submits transactions to a blockchain network where endorsement peers execute the smart contract 630 according to the smart contract 630 and the endorsement policy, and is a blockchain network peer component.

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

[0116] An exemplary storage medium can be coupled to a processor such that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integral with the processor. The processor and the storage medium may be present within an application specific integrated circuit (ASIC). Alternatively, the processor and the storage medium may exist as separate components.

[0117] FIG. 7A shows a process 700 in which a new block is added to a distributed ledger 720, according to an exemplary embodiment, and FIG. 7B shows the contents of a new data block structure 730 for a blockchain, according to an exemplary embodiment. Referring to FIG. 7A, a client (not shown) can submit a transaction to a blockchain node 711, 712, or 713 or a combination thereof. The client may be instructions received from any source for performing activities on the blockchain 720. As an example, the client may be an application that acts on behalf of a requester, such as a device, person, or entity, to propose a transaction to the blockchain. Different types of blockchain nodes / peers, including an endorse peer that simulates and endorses a transaction proposed by the client and a commit peer that confirms the endorsement, verifies the transaction, and commits the transaction to the distributed ledger 720, may exist within the blockchain network. In this example, the blockchain nodes 711, 712, and 713 can serve as an endorse node, a commit node, or both.

[0118] The distributed ledger 720 includes a blockchain that stores immutable and ordered records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. For each channel, there may be one distributed ledger 720, and each peer holds its own copy of the distributed ledger 720 for each channel of which it is a member. The blockchain 722 is a transaction log structured as a hash-linked block where each block contains a sequence of N transactions. The block can contain various components as shown in FIG. 7B. The link of the block (indicated by the arrow in FIG. 7A) can be generated by adding the hash of the header of the parent block and the hash of the header of the source block into the block header of the current block. In the example of FIG. 7A, the relationship of the parent block is represented by "P", and the relationship of the source block is represented by "S". In this example, all transactions on the blockchain 722 are ordered and cryptographically linked to each other in a DAG structure, preventing the blockchain data from being tampered with without breaking the hash link. Further, due to the link, the latest block in the blockchain 722 represents all transactions that came before it. The blockchain 722 may be stored on a peer file system (local or attached storage) that supports an append-only blockchain workload.

[0119] The current state of the blockchain 722 and the distributed ledger 720 can be stored in the state database 724. Here, the current state data represents the latest values of all keys that have been included in the chain transaction log of the blockchain 722. Chain code calls execute transactions against the current state in the state database 724. To make the interaction of these chain codes extremely efficient, the latest values of all keys are stored in the state database 724. The state database 724 can include an indexed view into the transaction log of the blockchain 722 and can thus be regenerated from the chain at any time. The state database 724 can be automatically recovered (generated if necessary) when the peer starts up and before transactions are accepted.

[0120] The endorsing node receives transactions from the client and endorses the transactions based on the simulated results. The endorsing node holds smart contracts that simulate the proposal of transactions. When the endorsing node endorses a transaction, the endorsing node creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The way to endorse a transaction is determined by an endorsement policy that can be specified within the chain code. An example of an endorsement policy is "a majority of the endorsing peers must endorse the transaction". Different channels can have different endorsement policies. The endorsed transactions are transferred by the client application to the ordering service 710.

[0121] The ordering service 710 accepts the endorsed transactions, orders them into blocks, and distributes the blocks to the commit peers. For example, the ordering service 710 can start a new block when a threshold of transactions is reached, when a timer times out, or under another condition. In the example of FIG. 7A, the blockchain node 712 is a commit peer that has received a new data block 730 for storage on the blockchain 720. The first block in the blockchain may be called the genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0122] The ordering service 710 can be composed of a cluster of orderers. The ordering service 710 does not process transactions or smart contracts, nor does it maintain a shared ledger. Rather, the ordering service 710 accepts the endorsed transactions and can specify the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network can be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0123] Transactions are written to the distributed ledger 720 in a consistent order. The order of the transactions is established to ensure that updates to the state database 724 are valid when committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering is done by solving a cryptographic puzzle, i.e., mining, in this example, the parties involved in the distributed ledger 720 can choose the ordering mechanism that best suits their network.

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

[0125] Referring to FIG. 7B, a new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 can include a plurality of data segments such as a block header 740, block data 750, and block metadata 760. It should be understood that the various blocks and their contents shown in FIG. 7B, such as the new data block 730 and its contents, are merely illustrative and are not intended to limit the scope of the exemplary embodiments. The new data block 730 can store transaction information of N transactions (for example, 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750. The new data block 730 can also include links to the parent block and source block of the DAG structure within the block header 740. In particular, the block header 740 can include the hash of the header of the parent block and the hash of the header of the source block. The block header 740 can 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 can be unique and can be assigned in various orders, such as incremental order / sequential order starting from zero.

[0126] The block data 750 can store the transaction information of each transaction recorded in the new data block 730. For example, the transaction data can include the type, version, timestamp of the transaction, the channel ID of the distributed ledger 720, the transaction ID, the epoch, the visibility of the payload, the chain code path (deploy tx), the chain code name, the chain code version, the input (chain code and function), the identity of the client (creator) such as the public key and certificate, the signature of the client, the identity of the endorser (if any), the signature of the endorser (if any), the proposal hash, the chain code event, the response status, the namespace, the read set (such as a list of keys and versions read by the transaction), the write set (such as a list of keys and values), the start key, the end key, the list of keys, the Merkel tree query summary, and one or more of the like. The transaction data can be stored for each of the N transactions.

[0127] The block metadata 760 can store multiple fields of metadata (such as in the form of a byte array, etc.). The metadata fields can include the signature for block creation, the reference to the last configuration block, the transaction filter that identifies the valid and invalid transactions within the block, the last offset of the ordering service that has survived for ordering the block, and the like. The signature, the last configuration block, and the orderer metadata can be added by the ordering service 710. On the other hand, the block committer (such as the blockchain node 712) can add validity / invalidity information based on the endorsement policy, verification of the read / write sets, etc. The transaction filter can include a byte array of a size equal to the number of transactions in the block data 750, and a verification code that identifies whether the transaction was valid or invalid.

[0128] FIG. 7C shows an embodiment of a blockchain 770 for digital content according to the embodiments described herein. The digital content can include one or more files and related information. The files can include media, images, videos, audio, text, links, graphics, movies, web pages, documents, or other forms of digital content. The immutable append-only aspect of the blockchain serves as a safeguard to protect the integrity, validity, and authenticity of the digital content, such that legal procedures where admissibility rules apply, or evidence, are taken into account, or the presentation and use of digital information are suitable for use in other settings where they are otherwise of concern. In this case, the digital content may be referred to as digital evidence.

[0129] The blockchain can be formed in various ways. In one embodiment, the digital content is included within and can be accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of reference information (e.g., headers, values, etc.) along with the associated digital content. Next, the hash value and the associated digital content can be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block within the blockchain, and the hash value of each block can be used as a reference for referring to the previous block. This can be explained as follows.: Block 1 Block 2.......Block N Parent Hash Value 1 Parent Hash Value 2 Parent Hash Value N Source Hash Value 1 Source Hash Value 2 Source Hash Value N Digital Content 1 Digital Content 2 Digital Content N

[0130] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain can store the encrypted hash of the content of each block without having any digital content. The digital content can be stored in another storage area or memory address in association with the hash value of the original file. The other storage area may be the same as the storage device used to store the blockchain, or it may be a different storage area, or even a separate relational database. The digital content of each block can be referenced or accessed by obtaining or querying the hash value of the block of interest and then searching for the value in the storage area where the actual digital content is stored correspondingly. This operation can be performed, for example, by a database gatekeeper. This can be explained as follows.: Blockchain Storage area Hash value of Block 1 Hash value of Block 1...Content ·· ·· ·· Hash value of Block N Hash value of Block N...Content

[0131] In the exemplary embodiment of FIG. 7C, the blockchain 770 includes a number of blocks 778 cryptographically linked in an ordered sequence when N≥1 1 , 778 2 ,..·778 N . The blocks 778 1 , 778 2 ,...778 N . The encryption used to link the blocks 778 1 , 778 2 ,...778 NA hash function that generates an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information within the block is applied. Examples of such hash functions include, but are not limited to, SHA-type (where SHA represents Secured Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, block 778 1 , 778 2 ,... 778 N can be cryptographically linked by a function different from the hash function. For purposes of explanation, the following description is made with reference to a hash function, for example, SHA-2.

[0132] Blocks 778 1 , 778 2 ,... 778 N each contain a header, a version of the file, and a value. The header and the value are different for each block as a result of the hashing in the blockchain. In one embodiment, the value may be contained within the header. As will be explained in more detail below, the version of the file may be the original file or a different version of the original file.

[0133] The first block 778 1 in the blockchain is called the genesis block and contains header 772 1 , original file 774 1 , and initial value 776 1 . The hash scheme used for the genesis block and actually used for all subsequent blocks may be different. For example, all the information within the first block 778 1 may be hashed together and at once, or the first block 778 1Each or part of the information inside may be hashed separately, and then the hash of the separately hashed part may be performed.

[0134] Header 772 1 can include one or more initial parameters, for example, version number, timestamp, nonce, root information, difficulty, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 774 1 and / or other information associated with the blockchain. Header 772 1 can be automatically generated (e.g., by blockchain network management software) or manually generated by blockchain participants. Other blocks within the blockchain 778 2 ~778 N Unlike the header in other blocks, the header 772 in the genesis block 1 simply does not refer to the previous block because there is no previous block.

[0135] The original file 774 in the genesis block 1 can be, for example, the data as captured by the device regardless of the presence of previous processing included in the blockchain. The original file 774 1 is received from a device, media source, or node through the system interface. The original file 774 1 is associated with metadata that can be generated either manually or automatically by, for example, a user, device, or system processor, or a combination thereof. The metadata is related to the original file 774 1 and can be included in the first block 778 1 in relation to it.

[0136] The value 776 in the genesis block 1 is the original file 774 1is an initial value generated based on one or more unique attributes. In one embodiment, the one or more unique attributes are the hash value of the original file 774 1 , the metadata about the original file 774 1 , and other information related to the file. In one implementation, the initial value 776 1 can be based on the following unique attributes: 1) The SHA-2 computed hash value for the original file 2) The device ID of the source 3) The start timestamp for the original file 4) The initial storage location of the original file 5) The blockchain network member ID for the software currently controlling the original file and related metadata

[0137] Other blocks 778 within the blockchain 2 ~778 N also have headers, files, and values. However, unlike the first block 772 1 , the headers 772 within the other blocks 2 ~772 N each contain the hash values of the parent block and source block of the DAG structure. The hash value may be only the hash of the header of that block, or the hash value of the entire block. As indicated by the arrow 780, by including the hash values of the parent block and source block within each of the remaining blocks, it is possible to trace from the Nth block to the genesis block (and related original file) block by block, establishing an auditable and immutable chain-of-custody.

[0138] Also, the headers 772 within the other blocks 2 ~772 NEach can also include other information, such as version numbers, timestamps, nonces, root information, difficulty, consensus protocols, and / or other parameters or information generally associated with corresponding files and / or the blockchain.

[0139] File 774 in other blocks 2 ~774 N May be equal to the original file or a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed can vary from block to block. Processing can include any modification of the file in the preceding block, such as editing the information, changing its content in other ways, removing the information, or adding or appending information to the file.

[0140] Additionally or alternatively, processing can include simply copying a file from a preceding 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 an action on the files of the blockchain or its associated metadata or both. Processing that includes analyzing a file can include, for example, appending, including, or otherwise associating various analyses, statistics, or other information related to the file.

[0141] Other block 776 in other blocks 2 ~776 NEach of the values is a unique value and all different as a result of the processes performed. For example, the value of any one block corresponds to an updated version of the values within the previous block. That update is reflected in the hash of the block to which the value is assigned. Thus, the value of a block indicates what processing was done within that block and also makes it possible to trace back through the blockchain to the original file. This tracing confirms the chain-of-custody of the file across the entire blockchain.

[0142] For example, consider the case where a portion of the file in the previous block has been edited, blocked, or pixelated in order to protect the identity of the person shown in the file. In this case, the block containing the edited file includes metadata associated with the edited file, such as how the edit was made, who made the edit, the timestamp of the edit, etc. The metadata can be hashed to form a value. Since the metadata of a block is different from the information hashed to form the value of the previous block, the values are different from each other and can be restored when decoded.

[0143] In one embodiment, if any one or more of the following occur, the value of the previous block can be updated (e.g., a new hash value is calculated) to form the value of the current block. The new hash value can be calculated in this exemplary embodiment by hashing all or a portion of the information described below. a) A new SHA-2 computed hash value when the file has been processed in some way (e.g., the file has been edited, copied, changed, accessed, or some other action has been taken) b) A new storage location for the file c) New metadata associated with the file d) Transfer of access or control of the file from one blockchain participant to another

[0144] FIG. 7D shows an embodiment of a block that can represent the structure of a block within the blockchain 790 according to one embodiment. The block, i.e., the block i includes a header 772 i , a file 774 i , and a value 776 i .

[0145] The header 772 i includes the hash value of the block that is the parent block i-1 , and additional reference information that can be the source block and any type of information described herein (e.g., header information including references, characteristics, parameters, etc.). Of course, all blocks, except for the genesis block and possibly some of the first blocks added after the genesis block, can reference the hash of the parent block and the source block of the DAG structure. The hash value can be only the hash of the header within the previous block, or can also be the hash of all or part of the information of the previous block including the file and metadata.

[0146] The file 774 i sequentially includes a plurality of data such as data 1, data 2,..., data N. The data is tagged with metadata 1, metadata 2,..., metadata N that describes the content or characteristics or both associated with the data. For example, as will be described in connection with embodiments hereinafter, the metadata for each data can include information indicating a timestamp for the data, information for processing the data, keywords indicating a person or other content shown in the data, and / or other features that can help establish the validity and content of the entire file, particularly for use as digital evidence. In addition to the metadata, each data can be tagged with references REF 1 , REF 2 ,..., REF N to prevent tampering, gaps within the file, and continuous references to the file.

[0147] Once metadata is assigned to data (e.g., by a smart contract), the metadata cannot be changed unless there is a change in the hash that can be easily identified for invalidation. Thus, the metadata creates a data log of information that can be accessed for use by participants in the blockchain.

[0148] Value 776 i is a hash value or other value calculated based on any of the types of information described above. For example, for any given block, the value for that block can be updated to reflect the processing performed on that block, e.g., a new hash value, a new storage location, new metadata for a related file, a transfer of control or access, an identifier, or other actions or information added. Although the value for each block is shown to be separate from the metadata for the data of the file and header, in other embodiments, the value can be based, in part or in whole, on this metadata. i Once the blockchain 770 is formed, at any point in time, an immutable chain of custody for a file can be obtained by querying the blockchain about the transaction history of the values across the blocks. This query, or tracing procedure, can start 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 restored. Decryption can also include decrypting the header and file, as well as related metadata, in each block.

[0149]

[0150] ​Decryption is performed based on the type of encryption performed on each block. This can include the use of a secret key, a public key, or a pair of public and secret keys. For example, when asymmetric encryption is used, a blockchain participant or a processor within the network can generate a pair of public and secret keys using a predetermined algorithm. The public key and the secret key are related to each other by some mathematical relationship. The public key can be publicly distributed so as to function as an address for receiving messages from other users, such as an IP address or a home address. The secret key is kept secret and is used to digitally sign messages sent to other blockchain participants. Since the signature is included in the message, the recipient can verify it using the sender's public key. In this way, the recipient can be confident that only the sender could have sent this message.

[0151] The generation of the key pair may be similar to creating an account on the blockchain, but it does not actually need to be registered anywhere. Also, all transactions executed on the blockchain are digitally signed by the sender using their secret key. This signature guarantees that only the owner of the account can track and process the blockchain files (within the scope of permission determined by the smart contract).

[0152] Figures 8A and 8B show additional examples of use cases of a blockchain that can be incorporated and used in this specification. In particular, Figure 8A shows an example 800 of a blockchain 810 that stores machine learning (artificial intelligence) data. Machine learning relies on a vast amount of historical data (or training data) to build a prediction model for accurate prediction of new data. Machine learning software (such as a neural network, etc.) can often search through millions of records to discover non-intuitive patterns.

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

[0154] Using the blockchain 810, both the training process 802 of the machine learning model and the prediction process 804 based on the trained machine learning model can be significantly improved. For example, in 802, instead of requiring a data scientist / engineer, or other users to collect data, historical data can be stored on the blockchain 810 by the asset 830 itself (or via an intermediary not shown). This can significantly reduce the collection time required by the host platform 820 when training the prediction model. For example, using a smart contract, data can be directly and securely transferred from its source to the blockchain 810 in a straight line. By ensuring the security and ownership of the data collected using the blockchain 810, the smart contract can directly transmit data from the asset to the individual who uses the data to build the machine learning model. This enables the sharing of data among the assets 830.

[0155] The collected data can be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism involves engaging (with the permitted nodes) to ensure that the data to be recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Thus, it is auditable, transparent, and secure. By adding IoT devices that write directly to the blockchain, in certain scenarios (i.e., supply chain, health management, logistics, etc.), both the frequency and accuracy of the data to be recorded can be increased.

[0156] Furthermore, the training of the machine learning model on the collected data can be iterated with improvements and tests by the host platform 820. Each iteration can be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. At 802, different training and test steps (and the associated data) can be stored on the blockchain 810 by the host platform 820. Each improvement to the machine learning model (e.g., changes to variables, weights, etc.) can be stored on 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 realizes the trained model, the resulting model can be stored on the blockchain 810.

[0157] After the model is trained, it can be deployed to a live environment where predictions / decisions can be made based on the execution of the finally trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and health devices. In this example, the data fed back from asset 830 can be input into the machine learning model and used to make event predictions such as failure events, error codes, etc. To provide auditable / verifiable evidence, the decisions made by the execution of the machine learning model on host platform 820 can be stored on blockchain 810. As a non-limiting example, the machine learning model can predict future outages / failures of parts of asset 830 and create warnings or notifications for replacing those parts. The data behind this decision can be stored on blockchain 810 by host platform 820. In one embodiment, the features or actions or both described or shown or both in this specification can be performed on or with respect to blockchain 810.

[0158] New transactions on the blockchain are gathered into new blocks and can be added to the existing hash values. Next, this is encrypted to create a new hash for the new block. This, when encrypted, is added to the next list of transactions, etc. As a result, a chain of blocks is brought about, each containing the hash value of the previous block. The computers storing these blocks periodically compare their hash values to ensure that they all agree. Computers that do not agree discard the records causing the problem. This approach is excellent at ensuring the immutability of the blockchain but is not perfect.

[0159] One way to exploit this system is for an unauthorized user to advantageously modify the list of transactions, but leave the hash value unchanged. This can be done by brute force, that is, by modifying the record, encrypting the result, and checking whether the hash value is the same. And if not, trying again and again until a matching hash is found. The security of the blockchain is based on the belief that a normal computer can only perform this kind of brute force attack over a time scale that is not at all realistic, like the age of the universe. In contrast, a quantum computer is much faster (thousands of times faster) and as a result, poses a much greater threat.

[0160] Figure 8B shows 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 is something that sends information using quantum particles such as photons, which cannot be copied by eavesdroppers without destroying them. In this way, the sender and receiver via the blockchain can confirm each other's identities.

[0161] In the example of Figure 8B, there are four users 854, 856, 858, and 860. Each pair of users can share a secret key 862 (i.e., QKD) between themselves. In this example, since there are four nodes, there are six pairs of nodes, and thus, QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CDSix different secret keys 862 are used, including. Each pair can create QKD by sending information using quantum particles such as photons, which cannot be copied by eavesdroppers without destroying them. In this way, the user pairs can verify each other's identities.

[0162] The operation of the blockchain 852 is based on two procedures: (i) creating a transaction and (ii) constructing a block that aggregates new transactions. New transactions can be created in the same way as in a conventional blockchain network. Each transaction can include information about the sender, recipient, creation time, amount (or value) transferred, and a list of reference transactions justifying that the sender has funds for the operation. Next, this transaction record is sent to all other nodes and entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 854 - 860) authenticate the transaction by providing a shared secret key 862 (QKD). This quantum signature can be attached to any transaction, making it very difficult to forge. Each node checks its entry with respect to the local copy of the blockchain 852 and verifies that each transaction has sufficient funds. However, the transaction has not yet been confirmed.

[0163] Rather than performing a conventional mining process on a block, the block can be created in a decentralized manner using a broadcast protocol. During a predetermined period (e.g., seconds, minutes, hours, etc.), the network applies the broadcast protocol to any unconfirmed transactions, thereby achieving a Byzantine consensus on the correct version of the transaction. For example, each node can hold a secret value (the transaction data of that particular node). In the first round, the nodes transmit their secret values to each other. In subsequent rounds, the nodes transmit the information received from other nodes in the previous round. Here, an honest node can create 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 shown herein can be performed on or with respect to the blockchain 852.

[0164] FIG. 9 shows an exemplary system 900 that supports one or more of the exemplary embodiments described and / or shown herein. System 900 includes a computer system / server 902 operable in a number of other general purpose or special purpose computing system environments or configurations. Exemplary computing systems, environments or configurations with which the computer system / server 902 can be used, without limitation, include personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices.

[0165] The computer system / server 902 can be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform particular tasks or implement particular abstract data types. The computer system / server 902 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules can be located in both local and remote computer system storage media, including a memory storage device.

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

[0167] The 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, and a processor or local bus using any of various bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect (PCI) bus.

[0168] The computer system / server 902 typically includes various computer system readable media. Such media can be any available media accessible by the computer system / server 902 and includes both volatile and nonvolatile media, as well as removable and non-removable media. In one embodiment, the system memory 906 implements the flow diagrams of other figures. The system memory 906 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 or cache memory 912 or both. The computer system / server 902 can further include other removable / non-removable, volatile / nonvolatile computer system storage media. By way of example only, a storage system 914 can be provided for reading from and writing to a non-removable nonvolatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from and writing to a removable nonvolatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to the bus by one or more data media interfaces. As further shown and described below, the memory 906 can include at least one program product having a set (e.g., at least one) of program modules configured to execute the functions of the embodiments of the present disclosure.

[0169] By way of example and not limitation, the memory 906 can store a program / utility 916 having a set (at least one) of program modules 918, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, can include an implementation of a networking environment. The program modules 918 generally execute the functions and / or methods of the various embodiments of the present application described herein, or both.

[0170] As will be appreciated by those skilled in the art, the embodiments of the present application can be embodied as a system, method, or computer program product. Accordingly, the embodiments of the present application can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software aspects and hardware aspects, which can be collectively referred to herein as a "circuit", "module", or "system". Furthermore, aspects of the present application can take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied therein.

[0171] The computer system / server 902 can 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, or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.), or a combination thereof. Such communication can be carried out via the input / output (I / O) interface 924. Furthermore, the computer system / server 902 can also communicate with one or more networks such as a local area network (LAN), a general-purpose wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via the network adapter 926. As shown, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. Although not shown, it should be understood that other hardware and / or software components can be used with the computer system / server 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0172] At least one exemplary embodiment of a system, method, and non-transitory computer-readable medium is shown in the accompanying drawings and described in the foregoing detailed description, but the present application is not limited to the disclosed embodiments, and as defined by the following claims, it will be understood that numerous rearrangements, modifications, and substitutions are possible. For example, the capabilities of the systems of the various figures can be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or part of the functions performed by individual modules can be performed by one or more of these modules. Further, the functions described herein can be performed inside or outside of modules or components, multiple times, and in relation to various events. Also, the information transmitted between the various modules can be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, or via multiple protocols, or both. Also, messages transmitted or received by any of the modules can be transmitted or received directly, or via one or more of the other modules, or both.

[0173] One of ordinary skill in the art will understand that "system" can be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device, or combination of devices. Presenting the above-described functions performed by a "system" is not intended to limit the scope of the present application in any way, but rather to provide an example of one of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in both local and distributed forms consistent with computing technology.

[0174] Note that some of the system features described in this specification are presented as modules, more particularly to emphasize their implementation independence. For example, a module can be implemented as a hardware circuit that includes custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module can also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device, graphics processing unit, etc.

[0175] A module can also be implemented at least partially in software for execution by various types of processors. For example, an identified unit of executable code can include one or more physical or logical blocks of computer instructions that can be organized, for example, as objects, procedures, or functions. Nevertheless, the executable files of the identified modules need not be physically located together, but can include different instructions stored in different locations that, when logically combined, include the modules and achieve the purposes described for the modules. Further, a module can be stored on a computer-readable medium, which can be, for example, a hard disk drive, flash device, random access memory (RAM), tape, or any other such medium used to store data.

[0176] In fact, the modules of executable code can be single instructions or multiple instructions, and can even be distributed across multiple different code segments, between different programs, and across multiple memory devices. Similarly, the operational data can be identified and shown herein within a module, embodied in any suitable form, and organized within any appropriate type of data structure. The operational data may be collected as a single data set, or may be distributed across different locations including different storage devices, and may exist at least partially simply as electronic signals on a system or network.

[0177] It will be readily understood that the components of this application can be arranged and designed in a variety of different configurations as generally described herein and shown in the drawings. Accordingly, the detailed description of the embodiments is not intended to limit the scope of this claimed application, but merely represents selected embodiments of this application.

[0178] Those skilled in the art will readily understand that the above may be implemented in different orders of steps, or in hardware elements in configurations different from those disclosed, or both. Accordingly, although this application is described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative structures are apparent.

[0179] Although preferred embodiments of this application are described, the embodiments described are merely exemplary, and it is to be understood that the scope of this application is defined only by the appended claims when considered together with the full scope of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. Receiving a chain of blocks from a blockchain including a directed acyclic graph (DAG) format in which blocks are hash-linked independently to a plurality of blocks, identifying a temporal relationship between blocks within the chain of blocks based on a structure of the chain of blocks in the DAG format, determining a sequential linear order of the chain of blocks in the DAG format based on the identified temporal relationship a processor configured to; a storage configured to store the sequential linear order of the chain of blocks, comprising, the processor is configured to generate a graph in the DAG format including nodes corresponding to the blocks having edges corresponding to hash links, and to identify the temporal relationship based on a structure of the edges between the nodes on the graph, the processor is configured to perform any one, or a combination thereof, of transforming a parent relationship on the graph by linking an edge from a child node to a node linked to a parent node of the child node and removing the edge between the child node and the parent node, transforming a cyclic node on the graph by aggregating nodes having the same relative temporal relationship into a single cyclic node including the aggregated nodes, or identifying two different paths between a pair of nodes on the graph and removing the shorter of the two different paths between the pair of nodes, a computing system.

2. The computing system according to claim 1, wherein the processor is further configured to perform a blockchain consensus process at a plurality of peer nodes based on the sequential linear order of the chain of blocks.

3. The computing system according to claim 1 or claim 2, wherein the chain of blocks in the DAG format includes a plurality of subsets of a linear chain of blocks of a plurality of peers, and the plurality of subsets of the linear chain of blocks include an interconnection therebetween.

4. The computing system according to claim 1, wherein the processor is further configured to create an order among the aggregated nodes included within the single cyclic node based on a predetermined protocol.

5. Receiving, by a computing device, a chain of blocks from a blockchain including a directed acyclic graph (DAG) format in which blocks are hash-linked independently to a plurality of blocks; Identifying, by the computing device, a temporal relationship between blocks in the chain of blocks based on a structure of the chain of blocks in the DAG format; Determining, by the computing device, a sequential linear order of the chain of blocks in the DAG format based on the identified temporal relationship; Storing, by the computing device, the sequential linear order of the chain of blocks; Including; Said identifying includes generating a graph in the DAG format including nodes corresponding to the blocks having edges therebetween corresponding to the hash links, and identifying the temporal relationship based on a structure of the edges between the nodes on the graph; Said identifying includes converting a parent relationship on the graph by adding an edge from a child node to a node linked to a parent node of the child node and removing an edge between the child node and the parent node, converting cyclic nodes on the graph by aggregating nodes having the same relative temporal relationship into a single cyclic node including the aggregated nodes, or identifying two different paths between a pair of nodes on the graph and removing the shorter one of the two different paths between the pair of nodes, or any combination thereof; Method.

6. The method according to claim 5, further comprising, by the computing device, performing a blockchain consensus process at a plurality of peer nodes based on the sequential linear order of the chain of blocks.

7. The chain of blocks in the DAG format includes a plurality of subsets of a linear chain of blocks of a plurality of peers, and the plurality of subsets of the linear chain of blocks include an interconnection therebetween, the method according to claim 5 or claim 6.

8. The method according to claim 5, wherein said converting the cyclic nodes further includes creating an order among the aggregated nodes included in the single cyclic node based on a predetermined protocol. **Claim 9** A non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to execute the method according to any one of claims 5 to 8. **Claim 10** A computer program including instructions that cause a computer to execute the method according to any one of claims 5 to 8.

Images