Partially Ordered Blockchain

Abstract

Example operations may include one or more of receiving blocks of a blockchain from one or more of a neighboring blockchain peer and an ordering service node; identifying two or more blocks from the received blocks that belong to the same slot in the blockchain; validating the two or more identified blocks in parallel by concurrently executing the two or more identified blocks; and storing the two or more identified blocks in a local blockchain ledger of the blockchain peer in response to validating the two or more identified blocks.

Description

Technical Field

[0001] This application generally relates to storing data in a blockchain, and more particularly to a blockchain ledger in which independent blocks are ordered by slots instead of a linear order, thereby enabling improved data access to block data.

Background Art

[0002] A centralized database stores data in a single database (e.g., a database server) and maintains it in one place. This location is often a central computer, e.g., a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database is usually accessible from multiple different locations. Multiple users or client workstations can work simultaneously using the centralized database, e.g., based on a client / server configuration. A centralized database is easy to manage, maintain, and control, especially for security purposes, because of its single location. Within a centralized database, there is also minimal data redundancy because the single storage location for all data also means that only one primary record contains a particular set of data.

[0003] However, centralized databases have significant drawbacks. For example, if fault tolerance is not considered, there is a single point of failure in a centralized database. Thus, if a hardware failure (e.g., a failure of hardware, firmware, or software, or a combination thereof) occurs, all the data within the database is lost and the work of all users is interrupted. In addition, centralized databases are highly dependent on network connectivity. As a result, when the connection speed decreases, the time required for each database access increases. Another drawback is the occurrence of bottlenecks when the traffic of the centralized database increases due to a single location. Furthermore, centralized databases provide limited access to data because only one copy of the data is maintained by the database.

[0004] In recent years, organizations have been looking to blockchain as a means to securely store data that can be accessed from multiple locations in a way that is not restricted by a central entity. In a blockchain network, peers collectively manage the data and are responsible for storing it on the blockchain. Blockchain provides data redundancy, multiple nodes for access, etc. without a central authority. Conventional blockchains store data blocks in a linear order of blocks, where each block is hash-linked to the previous block, and so on. This link is the result of the block storing the hash of the previous block. These links create a sequential chain of blocks called a blockchain.

[0005] Validity confirmation (sometimes called a consensus protocol) is a fundamental aspect of blockchain to ensure that a blockchain peer contains a blockchain in the correct state. In a permissioned blockchain, a blockchain peer can verify the validity of the blockchain state by verifying the hash links between blocks. To do this, the blockchain peer needs to perform validity confirmation of the hash of each link in the linear chain of blocks. The blockchain can grow to thousands or even millions of blocks. Therefore, the validity confirmation process may require significant time and resources. Thus, solutions are needed to overcome these drawbacks and limitations.

Summary of the Invention

[0006] Viewed from a first embodiment, the present invention provides an apparatus comprising: a network interface configured to receive blocks of a blockchain from one or more of adjacent blockchain peers and sequencing service nodes; identifying two or more blocks belonging to the same slot in the blockchain from among the received blocks, and concurrently verifying the validity of the two or more identified blocks by concurrent execution of the two or more identified blocks, and in response to the verification of the validity of the two or more identified blocks, storing the two or more identified blocks in a local blockchain ledger of the blockchain peer.

[0007] Preferably, the present invention provides an apparatus in which two or more identified blocks belonging to the same slot are independent blocks with respect to each other.

[0008] Preferably, the present invention provides an apparatus in which the processor is configured to concurrently execute two or more identified blocks on two or more independent processor cores of the blockchain peer.

[0009] The present invention preferably provides an apparatus further configured such that a processor initializes a local blockchain ledger for at least one of a startup process and a recovery process.

[0010] The present invention preferably provides an apparatus further configured such that a processor identifies two or more other blocks on a blockchain belonging to a previous slot.

[0011] The present invention preferably provides an apparatus further configured such that, when these two or more other blocks do not depend on two or more identified blocks belonging to the same slot, the processor verifies the validity of two or more blocks belonging to the previous slot in parallel with these two or more identified blocks.

[0012] The present invention preferably provides an apparatus configured such that a processor identifies which of the received blocks belong to the same slot based on hash values stored in the received blocks.

[0013] The present invention preferably provides an apparatus in which a processor determines that a block belongs to the current slot when a hash value of the block immediately preceding the block is a function of the hashes of a plurality of blocks stored in the immediately preceding slot on the blockchain.

[0014] Viewed from another aspect, the present invention provides a method including one or more of: receiving blocks of a blockchain from one or more of adjacent blockchain peers and ordering service nodes; identifying at least two blocks belonging to the same slot within the blockchain from among the received blocks; concurrently verifying the validity of the at least two identified blocks by concurrent execution of the at least two identified blocks; and storing the at least two identified blocks in a local blockchain ledger of a blockchain peer in response to verification of the validity of the at least two identified blocks.

[0015] The present invention preferably provides a method in which two or more identified blocks belonging to the same slot are independent blocks with respect to each other.

[0016] The present invention preferably provides a method in which verification of validity includes concurrently and simultaneously executing two or more identified blocks on two or more independent processor cores of a blockchain peer.

[0017] The present invention preferably further provides a method that includes initializing a local blockchain ledger during at least one of a startup process and a recovery process.

[0018] The present invention preferably further provides a method that includes identifying two or more other blocks on the blockchain belonging to the immediately preceding slot.

[0019] The present invention preferably further provides a method that includes, when these two or more other blocks do not depend on two or more identified blocks belonging to the same slot, concurrently verifying the validity of the two or more other blocks belonging to the immediately preceding slot in parallel with the two or more identified blocks.

[0020] The present invention preferably provides a method that includes identifying, based on a hash value stored in a received block, which of the received blocks belong to the same slot.

[0021] The present invention preferably provides a method that includes determining that a block belongs to the current slot when the hash value immediately preceding the block is a function of the hashes of a plurality of blocks stored in the immediately preceding slot on the blockchain.

[0022] Viewed from another aspect, the present invention provides a non-transitory computer-readable medium that includes instructions that, when read by a processor, cause the processor to receive blocks of a blockchain from one or more of adjacent blockchain peers and an ordering service node, identify at least two blocks belonging to the same slot within the blockchain from among the received blocks, concurrently verify the validity of the at least two identified blocks by simultaneously executing the at least two identified blocks, and store the at least two identified blocks in a local blockchain ledger of the blockchain peer in response to verifying the validity of the at least two identified blocks.

[0023] The present invention preferably provides a non-transitory computer-readable medium in which two or more identified blocks belonging to the same slot are independent blocks with respect to each other.

[0024] The present invention preferably provides a non-transitory computer-readable medium in which verifying validity includes concurrently and simultaneously executing two or more identified blocks on two or more independent processor cores of a blockchain peer.

[0025] The present invention preferably provides a non-transitory computer-readable medium, wherein the method further includes initializing a local blockchain ledger during at least one of a startup process and a recovery process.

Brief Description of the Drawings

[0026]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

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

DETAILED DESCRIPTION OF THE INVENTION

[0027] As generally described and shown in the figures of this specification, it will be readily understood that the components of this specification may be arranged and designed in a variety of different configurations. Accordingly, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system represented in the accompanying figures is not intended to limit the scope of the claimed application and merely represents selected embodiments.

[0028] The features, structures, or characteristics described throughout this specification may be combined in any suitable manner or deleted in one or more embodiments. For example, the use of phrases such as "example embodiments", "some embodiments", or other similar words indicates that specific features, structures, or characteristics described in relation to embodiments may be included in at least one embodiment throughout this specification. Accordingly, the appearance of phrases such as "example embodiments", "in some embodiments", "in other embodiments", or other similar words does not necessarily refer to the same group of embodiments throughout this specification, and the described features, structures, or characteristics may be combined in any suitable manner or deleted in one or more embodiments. Additionally, in each figure, any connection between elements can permit one-way communication, two-way communication, or both, whether the indicated connection is a one-way or two-way arrow. Also, any device shown in the drawings can be a different device. For example, if a mobile device transmitting information is shown, a wired device can also be used to transmit that information.

[0029] In addition, although the term "message" may be used in the description of embodiments, this application may be applicable to many types of networks and data. Further, although certain types of connections, messages, and signal transmissions may be shown in example embodiments, this application is not limited to specific types of connections, messages, and signal transmissions.

[0030] Embodiment examples provide a method, system, component, non-transitory computer-readable medium, device, or network, or a combination thereof, for a partially ordered blockchain ledger in which blocks are placed within slots instead of a linear order.

[0031] In one embodiment, the present application utilizes a distributed database (such as a blockchain) that is a distributed storage system including a plurality of nodes that communicate with each other. The distributed database includes an additional dedicated immutable data structure similar to a distributed ledger that can maintain records among parties who do not trust each other. The parties who do not trust each other are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and a single peer cannot change the database records without reaching an agreement among the distributed peers. For example, a peer may execute a consensus protocol to verify the validity of blockchain storage transactions, group those storage transactions into blocks, and construct a hash chain on the blocks. This process forms a ledger by ordering the storage transactions as needed for consistency. In various embodiments, a permissioned blockchain or a permissionless blockchain or both may be used. A public blockchain or a permissionless blockchain allows anyone to participate without specific identification information. A public blockchain includes 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 interaction within a group of entities that share a common goal, such as companies that exchange funds, goods, information, etc., but do not fully trust each other.

[0032] This application can utilize a blockchain that operates arbitrary programmable logic, called "smart contract" or "chaincode", adapted to a distributed storage system. Optionally, there may be a special chaincode for administrative functions and parameters, called system chaincode. The application can further utilize smart contracts, which are reliable distributed applications that leverage the immutability property of the blockchain database and the underlying consensus between nodes called signatures or signature policies. Blockchain transactions associated with this application can be "signed" before being committed to the blockchain, while unsigned transactions are ignored. Signature policies enable the chaincode to specify the signers of a transaction in the form of a set of peer nodes required for signing. When a client sends a transaction to the peers specified by the signature policy, a transaction is executed to verify the validity of the transaction. After validity verification, the transaction moves to the ordering phase, where a consensus protocol is used to generate an ordered sequence of signed transactions grouped into blocks.

[0033] This application can utilize nodes, which are communication entities in a blockchain system. In the sense that multiple different types of nodes can be executed on the same physical server, they may perform logical functions. Nodes are grouped within a trusted domain and are associated with a logical entity that controls those nodes in various ways. Nodes can include various types, such as a client or a submitting client node that submits a transaction call to a signer (e.g., a peer) and broadcasts a transaction proposal to an ordering service (e.g., an ordering node). Another type of node is a peer node that can receive a transaction submitted by a client, commit the transaction, and maintain the state and a copy of the ledger of blockchain transactions. A peer can also play the role of a signer, but this is not an essential requirement. An ordering service node or an ordering node is a node that executes a communication service for all nodes and implements delivery guarantees, such as broadcasting to each of the peer nodes in the system when committing a transaction and when changing the world state of the blockchain (usually another name for the initial blockchain transaction that includes control information and configuration information).

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

[0035] This application can utilize a chain, which is a transaction log structured as hash - linked blocks, where each block contains a sequence of N transactions and N is greater than or equal to 1. The block header contains the hash of the transactions in the block and the hash of the header of the previous block. In this way, all transactions in the ledger can be ordered and cryptographically linked together. Thus, it is not possible to tamper with the ledger data without breaking the hash link. The hash of the block in the blockchain that was most recently added represents all the transactions that occurred on the chain previously, ensuring that all peer nodes are in a consistent and reliable state. The chain may be stored in a file system of peer nodes (i.e., local, attached storage, cloud, etc.) that efficiently supports the property of being append - only for the workload of the blockchain.

[0036] The current state of the immutable ledger represents the latest values of all keys included in the chain's transaction log. Since the current state represents the latest key values known to the channel, it is sometimes referred to as the world state. Chaincode calls execute transactions against the data in the current state of the ledger. To efficiently facilitate their interaction, the latest key values may 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 may be automatically restored (or generated if necessary) when the peer node starts up, before transactions are received.

[0037] Blockchain frameworks such as Hyperledger Fabric provide permissioned distributed ledger technology (DLT) for enterprises. Permissioned blockchains are different from public blockchains in that access is restricted to only the members of the blockchain. Hyperledger Fabric has gained high evaluations by adopting a new architecture for storing blockchain transactions in the ledger, called execute-order-validate. Hyperledger Fabric is known as a general-purpose blockchain architecture used in both industrial and public domains.

[0038] One of the main elements of an execution order validity confirmation blockchain network is an ordering service (also referred to herein as an ordering node). The role of the ordering node is to provide the blockchain peers with blocks executed in an ordered manner for storage in each ledger of the blockchain peers. The ordering node provides a shared communication channel to the clients and peers and provides a broadcast service for messages containing transactions. The ordering node also ensures that transactions are strictly ordered (i.e., all transactions are strictly before or after another transaction).

[0039] When the ordering node receives sufficient transactions and orders them, the ordering node generates blocks and broadcasts those blocks to the blockchain peers participating in the blockchain network. Each block contains the hash of the previous block on the blockchain. This creates a link between two blocks. This process is continuously repeated when new blocks are created. The result is a sequential linear order of blocks. However, the size of the blocks is limited. Furthermore, the validity confirmation of such blocks requires the validity confirmation of each hash in the linear order of the blocks. This can cause hundreds, thousands, or even millions of hashes to be verified during the validity confirmation process.

[0040] Embodiment examples employ a new ordering process for blocks of a blockchain ledger, called partially ordered transactions or partially ordered blocks. Blocks may store hundreds or thousands of transactions. However, not all blocks have dependencies on each other. For example, a new block may not depend on the transactions of the immediately preceding block. The systems described herein utilize this non-dependency and employ the use of slots in the blockchain ledger. Slots may be used by an ordering service to hold multiple blocks in parallel with each other and in sequence with other slots. For example, a slot may hold two or more blocks, and each of the two or more blocks may include a hash link to a previous slot. In this example, each of the two or more blocks within the current slot may include a hash function based on a combination of blocks within the previous slot, rather than a hash link to one block (such as the immediately preceding block).

[0041] Some of the advantages of a partially ordered blockchain (and the transactions contained therein) include the ability to verify the validity of blocks / execute blocks in parallel. In a traditional blockchain, validity verification occurs in a linear order, and each block hash is verified in sequential order. The result is a sequential series of hash verifications executed in a linear fashion. In contrast, a partially ordered blockchain allows multiple blocks (e.g., blocks within the same slot) to be executed / verified in parallel. This can significantly reduce the time required for blockchain validity verification. Other advantages created by a partially ordered blockchain include faster peer recovery / startup, faster query processing, selective validity verification of blocks for improved transaction throughput, adoption of different DAG-based methods by groups of peers in any configuration for improved transaction throughput and query response time, ordering of encrypted blocks of transactions, etc.

[0042] Figure 1A shows a blockchain network 100 according to an execution order validity verification framework, according to an example embodiment. Referring to Figure 1A, the blockchain network 100 includes a plurality of blockchain peers 121, 122, 123, and 124 that store distributed copies of a blockchain ledger (blockchain 110). A client (not shown) may propose a transaction via blockchain peers 121 - 124 for storage on blockchain 110. Before a transaction can be committed to blockchain 110, the transaction may be executed by one or more signing peers. Any of blockchain peers 121 - 124 may act as a signer.

[0043] Transactions that are executed successfully may then be provided to the ordering node 120 (e.g., by a client, etc.). The ordering node 120 receives the transactions, orders them based on timestamps, and stores the ordered transactions in a block. When sufficient transactions have been received or a predefined time limit has passed, a new block holding the ordered transactions may be cut and sent to the blockchain peers 121 - 124 for storage. Before storing the block in each copy of the blockchain 110, each of the blockchain peers 121 - 124 may re - verify the validity of the transactions. However, rather than the ordering node 120 ordering the blocks in a linear order, the ordering node 120 may create partially ordered blocks / transactions, as shown in FIG. 1B.

[0044] Specifically, FIG. 1B shows an example of a partially ordered blockchain ledger 110 according to an exemplary embodiment. As will be appreciated, not all transactions have dependencies among them, and the transactions within the current block do not always depend on each previous block on the blockchain. Partial ordering utilizes this concept to provide a mechanism that can store non - dependent blocks (blocks that contain no transactions that depend on each other) in the same slot on the blockchain ledger. To prevent the slot from growing too large, the ordering node 120 may implement a maximum slot size, or an end time, or a combination thereof.

[0045] According to various embodiments, the ordering node 120 can place transactions in such a way that it can avoid dependencies between blocks for as long as possible (or until the maximum slot size or end time is reached). Additionally, example embodiments adopt the concept of slots on the blockchain ledger. A slot is basically a group of blocks that can be placed in parallel (previously sequential and linear) on the blockchain ledger. Slots placed in parallel can be executed vertically (in parallel), while different slots of the ledger are executed horizontally (sequentially one after the other), in contrast to the linear order of conventional blocks. For time purposes, blocks within the same slot are assumed to be equal. Since the system does not contain transactions where any block depends on another, this concept can be adopted, thus removing the importance of timing differences between different blocks within the same slot.

[0046] Figure 1B shows an example of four slots 111, 112, 113, and 114 for each block 115. A slot does not have to contain more than one block. In other words, a slot may contain only a single block or may contain two or more blocks. Also, the number of blocks within each of the slots 111 - 114 may be limited by the slot size, end time, etc. monitored by the ordering node 120.

[0047] In the case of transactions within the same slot, the transactions may have various characteristics that are identified and implemented by the ordering node 120. For example, a transaction within a block of slot 112 (e.g., block 9) can depend on a transaction within the same block (e.g., block 9), or on a transaction present in a block of the previous slot 111 (or multiple slots) (e.g., block 8). However, a transaction within a block cannot depend on a transaction in another block within the same slot. Thus, block 9 cannot contain a transaction that depends on block 10, 11, or 12, and conversely, block 10, 11, or 12 cannot contain a transaction that depends on block 9. If a new block contains a transaction that depends on any transaction present in a block of the current slot, the ordering node 120 creates a new slot. For example, while creating slot 112, if the ordering node 112 receives a transaction that depends on block 10, the ordering node may create block 13 and, at the same time, create slot 113.

[0048] On the one hand, the previous hash values stored in each block are different from the previous hash values in a conventional sequential linear blockchain. In the example of Figure 1B, function 116 is used to create the previous hash value. For example, each of the blocks within the same slot may store the same previous hash value. Further, the previous hash value may be a value generated based on a combination of the hash value / block of the immediately preceding slot. For example, blocks 13, 14, and 15 belong to the same slot 113 (also referred to as slot i). Here, each of blocks 13, 14, and 15 may store a previous hash value based on a combination of the hashes of blocks 9, 10, 11, and 12 belonging to the immediately preceding slot 112, and based on the previous hash values 116 of blocks 9, 10, 11, and 12. This ensures that while maintaining the sequential nature of the slots, parallelism between blocks within the same slot is also made possible.

[0049] According to various embodiments, the previous hash value of a new block within slot (i) is a function (Fn) of the hashes of the blocks present in the previous slot (i - 1). Examples of the function Fn include the exclusive OR of the hashes of the blocks in the previous slot. As another example, the Fn function may be a composite hash of the blocks in the previous slot. For example, the composite hash may be a secondary hash of a key as a function of the hashes of the blocks in the previous slot.

[0050] In the example of FIG. 1B, blocks 9-12 do not depend on each other and thus belong to the same slot 112. On the other hand, since at least one of the transactions within block 13 depends on a transaction existing in one of blocks 9-12, block 13 violates the non-dependency requirement. Therefore, the ordering node 120 creates a new slot 113 and block 13 is added to slot 13. Further, the previous hash value of block 13 is a function 116 based on the blocks existing in the previous slot 112. On the other hand, the remaining blocks 14 and 15 do not depend on the transactions within block 13 and do not depend on each other. Therefore, blocks 14 and 15 are added to slot 113. On the other hand, block 16 either violates the dependency requirement or block 16 is received after the slot limit parameter.

[0051] For example, to prevent the computational cost from increasing explosively, the ordering node 120 may implement one or more of the slot size requirement and the end time requirement. The slot size requirement limits the number of blocks (or transactions) that can exist in one slot. When the number of blocks within a slot reaches the assigned slot size parameter, the ordering node 120 cuts off a new slot and places the next block in the new slot. As another example, the end time parameter is the maximum assigned time that the ordering node 120 can add a block to the current slot. The end time parameter may be tracked by the ordering node 120 that starts a timer when a new slot is created. Here, the ordering node 120 continues to add blocks to the slot until the timer expires / completes. When the ordering node 120 starts a new slot, the ordering node 120 restarts the timer. In the example of FIG. 1B, it is assumed that the timer expires during the creation of slot 113 and block 16 is created after the timer expiration. Therefore, block 16 is added to the new slot 114.

[0052] The ordered node 120 may maintain a slot read set and a slot write set that include keys read or written by transactions within the block belonging to the current slot. By restricting the size of the slot, the resources used by the ordered node 120 to maintain these sets are suppressed. In some embodiments, when the ordered node 120 receives a new transaction, a new slot may be created in response to a transaction within a block prior to any of the current slots. In this case, the resources used by the ordered node are automatically reset. The restriction on the size of the slot ensures that the ordered node is not overwhelmed when it does not receive a new transaction that depends on transactions within a block prior to any of the current slots. The actual size of the slot can be set according to the resources available to the ordered node. Further, if the size of the slot is not restricted, it may take a long time to verify the validity of the hash of the previous block because it is necessary to wait for a large number of immediately preceding blocks to be received. Due to the limited number of processors owned by each peer, it is not necessary to verify the validity of all blocks within the slot in parallel.

[0053] As another example, by restricting the time the slot is open, the resources used by the ordered node 120 to maintain these sets are suppressed. The restriction on the time the slot is open also ensures that the ordered node 120 is not overwhelmed when it does not receive a new transaction that depends on transactions within a block prior to any of the current slots. The actual time the slot is open can be set according to the resources available to the ordered node. If the time the slot is open is not restricted, the transactions initially included in the slot are adversely affected by long waiting times.

[0054] In these examples, new slots may be created in the following three scenarios. For example, when the ordering node 120 receives a new transaction, a new slot may be created according to the transactions in the blocks before any of the current slots. As another example, the ordering node 120 may create a new slot when it reaches the slot size. As another example, the ordering node 120 may create a new slot when it reaches the end time.

[0055] On the other hand, the blockchain peers 121-124 may receive a block from the ordering node 120 after the block is created. Here, the blockchain peers 121-124 may receive the blocks one by one. Therefore, the partial order of the slots / blocks in the blockchain ledger 110 is not immediately clear to the blockchain peers. When a blockchain peer (e.g., 121-124) receives a new block broadcast from the ordering node 120, the blockchain peer may check whether this block belongs to the current slot by checking whether the previous hash value in the new block is a function of the hash of the block existing in the previous slot.

[0056] If the previous hash is not a function of the hash of the previous slot, the blockchain peer may check whether the new block belongs to the next slot. In this case, if the new block belongs to the next slot, the previous hash value in the new block should be a function of the hash of the block in the current slot. If the hash value is successfully checked, the blockchain peer increments the pointer of the current slot and creates a new slot in the blockchain ledger. If the hash values do not match, the blockchain peer has not yet received some of the blocks in the current slot that the transactions in this block may depend on. Additionally, due to redundancy within the blockchain network, it is expected that each block will be received by all peers. The blockchain peer may store the block in a buffer and periodically check whether the block belongs to the current slot.

[0057] To track the dependencies of transactions, the ordering node 120 may use a hash set to track the keys of the transactions for each block in the slot. In this example, a transaction can be added to a block only if it depends only on transactions that exist in that block or in a block in the previous slot. On the other hand, if a transaction cannot be added to the current slot, the ordering node 120 can decide to create a new slot and add the transaction there, or hold this transaction and process other transactions that can be added to the current slot. In this case, the ordering node 120 can take means (e.g., a limit on the previous waiting time for a transaction to be included in a block) to ensure that resource exhaustion does not occur for the held transactions.

[0058] For each key, the ordering node 120 may maintain separate metadata regarding which transactions (present in which blocks) are read and modified. This approach is costly in terms of memory requirements, but this metadata may be advantageous in the case of a permissioned platform where peers trust the ordering node 120. When a peer joins the blockchain network 100, the peer begins receiving blocks. In existing scenarios, the peer has to request all previous blocks before it can verify the validity of the transactions of the currently received block. However, in an exemplary embodiment, due to partial ordering, a blockchain peer can request only the blocks that the transactions in the current block depend on.

[0059] The hash set generated by the ordering node 120 may include the set of all keys read or written by the transactions in the blocks belonging to the current slot. The ordering node 120 can maintain this set in various data structures, such as via a hash set or a linked list or an array. In some embodiments, the ordering node 120 may maintain two sets, including a slot read set and a slot write set. The slot read set may include the keys read by the transactions belonging to the blocks in the current slot. The slot write set may include the keys written by the transactions belonging to the blocks in the current slot. When a new transaction is received, the ordering node 120 may compare the read / write set of that transaction with the slot read set and the slot write set. Using this comparison, the ordering node 120 can determine whether the transaction can be inserted into the blocks belonging to the current slot or requires a new slot.

[0060] As another example, the ordering node 120 may create a directed acyclic graph (DAG) of transactions submitted by clients. In this example, transactions belonging to the same connected component may be placed in the same block or in different blocks across different slots. Additionally, transactions belonging to different components may be inserted into the same slot (but different blocks within the same slot).

[0061] The example embodiments provide significant advantages over conventional linearly ordered blockchains. For example, the example embodiments describe an ordering node that implements a partial ordering among the transactions of a blockchain. The ordering node identifies dependencies between the keys of different transactions arriving within a period, creates different blocks, and may order together those blocks that can be executed simultaneously by any peer (i.e., the slots within the blockchain ledger). The hash of a block includes a function (e.g., exclusive OR of hashes, composite hash, etc.) of the hashes of the blocks within the previous slot. In some embodiments, the number of blocks within a slot is limited by the maximum number of blocks permitted within the slot or a timeout period until no more blocks can be added to the current slot. In some embodiments, the ordering node ensures that the resources of the transactions do not run out while maximizing the number of blocks that fit into a slot.

[0062] Figure 2A shows the configuration 200 of a blockchain architecture according to an exemplary embodiment. Referring to Figure 2A, the blockchain architecture 200 may include certain blockchain elements (e.g., a group 202 of blockchain nodes). The blockchain nodes 202 may include one or more nodes 204 - 210 (merely by way of example, these four nodes are shown). These nodes participate in a plurality of activities such as the addition and validation process (consensus) of blockchain transactions. One or more of the blockchain nodes 204 - 210 may sign a transaction based on a signature policy and may provide an ordering service for all the blockchain nodes within the architecture 200. The blockchain nodes may initiate blockchain authentication and attempt to write to an immutable ledger of the blockchain stored in the blockchain layer 216, and a copy of this write may also be stored in the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 to access and execute the stored program / application code 220 (e.g., chain code, smart contract, etc.). The program / application code 220 can be created according to a customized configuration requested by participants, maintain their own state, control their own assets, and receive external information. The blockchain configuration can be installed on all the blockchain nodes 204 - 210 by deploying it as a transaction and adding it to the distributed ledger.

[0063] The blockchain-based or platform 212 may include various layers of blockchain data, services (such as cryptographic credit services, virtual execution environments, etc.), and underlying physical computer infrastructure used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 may 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 credit service 218 may verify transactions such as asset exchange transactions and be used to keep information private.

[0064] The configuration of the blockchain architecture of FIG. 2A may process and execute the program / application code 220 via one or more interfaces exposed and services provided by the blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 may be able to store and transfer data and may be executed by the nodes 204-210 in the form of associated chain code or other code elements to be executed, including smart contracts and conditions. As a non-limiting example, smart contracts may be created to execute reminders, updates, or changes, other notifications to be updated, or combinations thereof. The smart contract itself may be used to identify authorization and access requirements as well as rules associated with the use of the ledger. For example, the read data 226 may be processed by one or more processing entities (such as virtual machines) included in the blockchain layer 216 to create a processing result to be written to the blockchain containing the write data 228. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

[0065] Using high-level applications and programming languages, smart contracts can be created and then written to blocks within a blockchain. A smart contract may include executable code in which registration, storage, or replication to a blockchain (e.g., a distributed network of blockchain peers), or a combination thereof, is performed. A transaction is the execution of smart contract code that can be executed in response to conditions associated with the smart contract being satisfied. Execution of a smart contract may trigger a reliable change to the state of a digital blockchain ledger. Changes to the blockchain ledger caused by the execution of a smart contract may be automatically replicated across the distributed network of blockchain peers via one or more consensus protocols.

[0066] A smart contract may write data to a blockchain in the form of key-value pairs. Further, smart contract code can read values stored in the blockchain and use them in the operation of an application. Smart contract code can write the output of various logical operations to a blockchain. This code may be used to create temporary data structures within a virtual machine or other computing platform. Data written to a blockchain may be made public, or maintained privately and encrypted, or both. Temporary data used / generated by a smart contract is held in memory by the provided execution environment and deleted after the data necessary for the blockchain is identified.

[0067] The chain code may include code interpretation of smart contracts, along with additional features. As described herein, the chain code may be program code deployed on a computing network and may be executed together by chain validators during a consensus process to confirm its validity. 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 extraction function. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chain code sends an authorization key to the requested service. The chain code may write data related to cryptographic details to the blockchain.

[0068] Figure 2B shows an example of a blockchain transaction flow 250 between nodes of a blockchain, according to an example embodiment. Referring to Figure 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to a signing peer node 281. The signing peer 281 may verify the client's signature and execute a chain code function to initiate the transaction. The output may include the result of the chain code, a set of key / value versions read by the chain code (read set), and a set of key / values written by the chain code (write set). If the proposal response 292 is approved, it is returned to the client 260 along with a signature. The client 260 combines the signature with the transaction payload 293 and broadcasts it to the ordering service node 284. Subsequently, the ordering service node 284 distributes the ordered transactions as blocks on the channel to all peers 281 - 283. Prior to committing to the blockchain, each peer 281 - 283 may confirm the validity of the transaction. For example, the peer may check a signature policy to confirm that the correct assignment of the specified peer signed the result and authenticated the signature for the transaction payload 293.

[0069] Referring again to FIG. 2B, client node 260 initiates transaction 291 by constructing a request and sending it to peer node 281 (the signer). Client 260 may include an application that utilizes a supported software development kit (SDK), and this application generates a transaction proposal using the available application programming interfaces (APIs). The proposal is a request to call a chaincode function such that data can be read from or written to the ledger (i.e., write a new key-value pair for an asset), or both. The SDK functions as a shim to package the transaction proposal into a properly designed format (e.g., a protocol buffer via a remote procedure call (RPC)), and may receive the client's cryptographic authentication information and generate a unique signature for the transaction proposal.

[0070] In response, signing peer node 281 may verify that (a) the transaction proposal is properly formed, (b) the transaction has not already been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (client 260 in the example) has the appropriate permissions to execute the proposed operation on that channel. The signing peer node 281 may receive the input of the transaction proposal as an argument to the chaincode function to be called. The chaincode is then executed against the current state database, generating a transaction result that includes a response value, a read set, and a write set. However, at this point, no updates are made to the ledger. At 292, the set of values is returned to the SDK of client 260 as a proposal response 292, along with the signature of the signing peer node 281, and this SDK parses the payload for use by the application.

[0071] Accordingly, the application of client 260 inspects / verifies the signatures of the signing peers, compares the proposed responses, and determines whether the proposed responses are the same. If the chain code simply queries the ledger, the application inspects the query response and typically does not submit the transaction to the ordering node service 284. When the client application attempts to submit a transaction to the ordering node service 284 to update the ledger, the application determines whether the specified signature policy is satisfied before submission (i.e., whether all the peer nodes required for the transaction have signed the transaction). Here, the client may include only one of the multiple parties related to the transaction. In this case, each client may include its own signing node, and each signing node needs to sign the transaction. The architecture ensures that the signature policy is still enforced by the peers and maintained during the commit validation phase even if the application chooses not to inspect the response or transfers unsigned transactions in other ways.

[0072] After a successful inspection, in step 293, client 260 combines the signatures with the transaction and broadcasts the transaction proposal and transaction response within the transaction message to the ordering node 284. The transaction may include a read / write set, the signatures of the signing peers, and the channel ID. The ordering node 284 does not need to inspect the entire content of the transaction to perform its operation. Instead, the ordering node 284 may simply receive the transaction from all channels in the network, order it over time per channel, and create a block of transactions for each channel.

[0073] The blocks of the transaction are distributed from the ordering node 284 to all peer nodes 281-283 on the channel. To ensure that any signature policy is satisfied and to ensure that there are no changes to the ledger state with respect to the variables in the read set since the read set was generated by the execution of the transaction, the validity of the transactions 294 in the block is verified. The transactions in the block are tagged as either valid or invalid. Further, in step 295, each peer node 281-283 adds the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events are issued to notify the client application that the transaction (call) has been added to the chain in an immutable manner and to notify whether the validity of the transaction has been verified or invalidated.

[0074] FIG. 3A shows an example of a permissioned blockchain network 300, which features a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 302 may initiate a transaction against the permissioned blockchain 304. In this example, the transaction can be a deploy, call, or query and may be issued via a client-side application using the SDK, directly via the API, etc. The network may provide access to regulators 306 such as auditors. 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 can be restricted to only querying the ledger, while the client can be given the right to perform deployments, calls, and queries of certain types of chaincode.

[0075] Blockchain developers 310 can write chain code and client-side applications. Blockchain developers 310 can directly deploy chain code to the network via an interface. To include authentication information from a conventional data source 312 in the chain code, developers 310 can access the data using an out-of-band connection. In this example, blockchain user 302 connects to a permissioned blockchain 304 via peer node 314. Peer node 314 obtains a user's registration and transaction certificates from an authentication authority 316 that manages the user's roles and permissions before starting any transaction. In some cases, blockchain users may have to own those digital certificates to execute transactions on the permissioned blockchain 304. On the other hand, users attempting to utilize the chain code may need to verify the authentication information of those users on the conventional data source 312. To confirm a user's authorization, the chain code can use an out-of-band connection to this data via a conventional processing platform 318.

[0076] Figure 3B shows another example of a permissioned blockchain network 320, which features a distributed, decentralized peer-to-peer architecture. In this example, blockchain users 322 may submit transactions to the permissioned blockchain 324. In this example, the transactions can be deployments, calls, or queries and may be issued via a client-side application using an SDK, directly via an API, etc. The network may provide access to regulators 326 such as auditors. The blockchain network operator 328 manages the permissions of the members, such as registering the regulator 326 as an "auditor" and registering the blockchain users 322 as "clients". The auditor can be restricted to only querying the ledger, while the client can be given permissions to perform deployments, calls, and queries of certain types of chaincode.

[0077] Blockchain developer 330 writes chain code and client-side applications. The blockchain developer 330 can directly deploy the chain code to the network via an interface. To include authentication information from the conventional data source 332 in the chain code, the developer 330 can access the data using an out-of-band connection. In this example, the blockchain user 322 connects to the network via the peer node 334. The peer node 334 obtains the user's registration and transaction certificates from the certification authority 336 before starting any transaction. In some cases, the blockchain user must possess those digital certificates to execute a transaction on the permissioned blockchain 324. On the other hand, a user attempting to utilize the chain code may need to verify the authentication information of those users on the conventional data source 332. To confirm user authorization, the chain code can use an out-of-band connection to this data via the conventional processing platform 338.

[0078] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain that requires permission to participate, anyone can participate in a permissionless blockchain. For example, a user may start information exchange with the network by creating a personal address and submitting a transaction, and thus adding an entry to the ledger, to participate in a permissionless blockchain. Further, all stakeholders can choose to run nodes on the system and adopt a mining protocol to help verify transactions.

[0079] Figure 3C shows a process 350 of a transaction being processed by a permissionless blockchain 352 that includes a plurality of nodes 354. A sending side 356 wishes to send a payment or other form of value (e.g., a certificate, medical record, contract, good, service, or any other asset that can be encapsulated in a digital record) to a receiving side 358 via the permissionless blockchain 352. In one embodiment, each of the sending-side device 356 and the receiving-side device 358 may have a digital wallet that provides user interface control and display of transaction parameters (associated with the blockchain 352). Accordingly, the transaction is broadcast to the nodes 354 throughout 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 predefined or dynamically assigned). For example, this verification may include verifying the identification information of the parties involved. The transaction may be verified immediately, or the transaction may be queued with other transactions, and the node 354 determines whether the transaction is valid based on a set of network rules.

[0080] Within structure 362, a valid transaction is formed within a block and sealed using a lock (hash). This process may be executed among nodes 354 by a mining node. The mining node may utilize additional software, particularly for mining and creating blocks of the permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit numerical value, etc.) created using an algorithm agreed upon by the network. Each block may 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.

[0081] Before a block can be added to the blockchain, the validity of the block must be confirmed. The validity confirmation of the permissionless blockchain 352 may include a proof-of-work (PoW) that is a solution to a puzzle obtained from the block's header. Although not shown in the example of Figure 3C, another process for block validity confirmation is proof-of-stake. Unlike a proof-of-work where an algorithm rewards miners for solving a mathematical problem, in proof-of-stake, the creator of a new block is selected in a deterministic manner according to wealth (also defined as "stake"). Subsequently, a similar proof is executed by the selected node.

[0082] In mining 364, the node attempts to solve the block by making incremental changes to one variable until the solution meets a network-wide target. This creates a PoW, thereby guaranteeing the correct answer. In other words, a possible solution must prove that computational resources were consumed in solving the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins, etc.) for correctly mining a block.

[0083] Here, since an attacker must modify all subsequent blocks in order to accept the modification of one block, the PoW process makes it extremely difficult to modify the blockchain along with the modification of the block. Further, as new blocks are mined, the difficulty of modifying a block increases as the number of subsequent blocks increases. In distribution 366, the blocks that have been properly validated are distributed throughout the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the permissionless blockchain 352. Further, the value in the transaction submitted by the sending side 356 is deposited in the digital wallet of the receiving device 358 or transferred in some other way.

[0084] FIG. 4A shows a process 400A for concurrently verifying the validity of blocks during the operation of a peer, according to an exemplary embodiment. Referring to FIG. 4A, a blockchain peer 420 may retrieve multiple blocks 411-414 simultaneously during a startup or recovery process when restoring a local blockchain ledger 422 that includes a blockchain 424 and a state database 426.

[0085] By default, in existing blockchain protocols, a blockchain peer needs to start many applications during reboot and, at the same time, sequentially execute different blocks of the blockchain. This leads to a long startup time because the blocks are executed sequentially. However, in the exemplary embodiment, the blockchain peer 420 may execute the blocks 411-414 in parallel, thereby saving the time required to complete the validation of the blocks of the entire blockchain 410. Due to the partial ordering of the transactions within a slot, parallel validation of multiple blocks can be used. This results in faster recovery for failed peers or newly started peers or both.

[0086] For example, blockchain peer 420 may use multiple physical cores to accelerate the recovery process. When the blockchain peer 420 starts the recovery process, it receives blocks from another peer (not shown) via the gossip protocol. Accordingly, the blockchain peer 420 may identify blocks 411-414 that belong to the same slot. These blocks 411-414 that belong to the same slot can be restored simultaneously using multiple threads (which may be executed on multiple physical cores within the blockchain peer 420 in some cases). This parallelism between blocks improves the recovery time compared to current systems that must execute blocks in a linear order.

[0087] For example, during process 400A, the blockchain peer 420 may collect blocks from adjacent peers. This collection process may be executed during startup or restart. The blockchain peer 420 may initialize the local ledger 422. The blockchain peer 420 may simultaneously retrieve blocks 411-414 and independently use different cores / processors to simultaneously verify the validity of blocks 411-414 (without additional processing). The blockchain peer 420 may update the state database 426 in parallel by different cores of the blockchain peer 420. This results in a reduction in the peer's recovery / startup time. Without additional processing, the validity of multiple blocks belonging to the same slot can be verified in parallel with the transactions within the blockchain 410 in a partially ordered state.

[0088] Figure 4B shows a process 400B that skips the validity check of blocks during an inquiry search operation according to an embodiment example. Referring to Figure 4B, a blockchain peer 420 is receiving an inquiry regarding the transaction stored in block 415. This inquiry may be received from a client 430 or the like. In response, the blockchain peer 420 may verify the validity of block 415 and the previous block in the blockchain 410. However, rather than verifying the validity of all blocks as is done in a conventional blockchain ledger, the blockchain peer 420 may skip blocks that do not depend on block 415 and remove them from the validity check process.

[0089] By default, in an existing blockchain protocol, before a peer node responds to an inquiry regarding the key of the current block, it must verify the validity of all previous blocks of the current block. This leads to a longer response time for the inquiry because the validity of the blocks is verified sequentially. However, the key within the current block may not depend on the previous block. Nevertheless, it is essential to verify the validity of the previous block on the chain before responding to the inquiry. In contrast, in process 400B, the blockchain peer 420 does not need to execute all preceding blocks before responding to the inquiry, thereby saving the time required to respond to the inquiry. For example, the blockchain peer 420 may skip the blocks within slot (i) that include the inquiry block 415. Additionally, the blockchain peer 420 may skip other blocks (e.g., slot (i - 1)) if they do not contain transactions on which block 415 depends. This skip may continue until a block depends on block 415.

[0090] For example, blockchain peer 420 may receive an inquiry regarding the transaction stored in block 415 of slot (i). Verification of the validity of other blocks within the same slot (i) as the current block may be pending (or may not even be received by blockchain peer 420). However, before responding to the inquiry, blockchain peer 420 may skip these blocks and verify the validity of only the current block (without caring about the verification of the validity of other blocks within the same slot). Thus, the blockchain peer may identify the next block in the chain before block 415 and skip the remaining intermediate blocks. This results in speeding up / improving the response time of the inquiry. Further, after verifying the validity of the current block, state database 426 is updated and a response to the inquiry is provided. After the validity of the remaining blocks within the same slot is verified, the state database 426 is updated accordingly. However, those updates do not affect the response to the inquiry.

[0091] FIG. 4C is a diagram showing a process 400C for mapping a transaction to a DAG to determine an option for parallel processing according to an exemplary embodiment. An organization may execute multiple peers within a blockchain network. By default, in an existing blockchain protocol, all peers within an organization commit all valid transactions to the state database by independently and sequentially executing the transactions within each block. In some embodiments, only the anchor peer node may need to immediately verify the validity of the transactions within each block so that the transaction response time is not limited. Other peers within each organization may buffer the blocks and execute the transactions in parallel if possible. The exemplary embodiment provides a mechanism that can split a transaction based on the concept of partially ordered transactions and execute it in parallel using multiple blockchain peers of an organization.

[0092] Specifically, referring to the process 400C in FIG. 4C, the blockchain peer 420 can construct DAG structures 442, 444, and 446 from the transactions present in the blocks within adjacent slots in order to further utilize the parallelism across multiple slots. In the example of FIG. 4C, three blocks (blocks A, B, and C) are placed in the same slot. One characteristic of the partially ordered transactions is that two blocks within the same slot cannot contain transactions that depend on each other. However, each block may contain dependent transactions. For example, each of blocks A, B, and C may contain a series of internal dependent transactions. The blockchain peer 420 can use the DAG to graph these internal dependencies. In a DAG structure, nodes represent transactions and links represent dependencies between transactions. Further, the blockchain peer 420 (or other services) may split the transactions to be processed in parallel based on the DAG structures 442, 444, and 446 so that two dependent transactions are not executed simultaneously across multiple peers of the same organization.

[0093] For example, the ordering node may distribute each block to an anchor peer among multiple peers of the organization. In FIG. 4C, the blockchain peer 420 represents the anchor node. The blockchain peer 420 may send each received block to all other blockchain peers (not shown) within the organization. Further, the blockchain peer 420 may sequentially verify the validity of the transactions of the block (thus, there is no delay for the clients in the transaction execution state). This validity verification may be based on the parallel validity verification of the blocks belonging to the same slot, as in the example of FIG. 4A.

[0094] Furthermore, other peers within the organization can buffer the blocks and then verify the validity of those blocks to find out if parallel validity verification between transactions is achievable. These peers can buffer the blocks within slot-i and find out if the transactions within these blocks can be executed in parallel with the transactions of slots after slot-i. The peers can construct a DAG from each block of slot-i and the block of slot-(i+1) and find out if they can verify the validity of that block of slot-(i+1) together with the blocks of slot-i. If there are no dependencies, the blocks of slot-(i+1) can be executed in parallel with the blocks of slot-(i). This objective is to achieve improved transaction throughput. Different peers within the same organization may implement such different combinations of DAG-based parallelism. As explained in this example, since different peers implement different levels of parallelism, the same peer may not be able to calculate the fastest response to different queries. The received query can be responded to by any peer of the organization that can calculate the response to the query faster. To do this, blockchain peer 420 may construct a DAG from each of blocks A, B, and C and determine if the transactions of the three blocks can be executed in parallel or are dependent on each other. In DAG 442, the transactions of block A that are dependent on each other are shown. Similarly, in DAGs 444 and 446, the transactions of block B and C that are dependent on each other are shown, respectively.

[0095] In this example, the DAG helps to separate transactions into groups so that there are no dependencies between different groups of transactions, and thus the validity of a group of transactions can be verified in parallel with other groups of transactions. The purpose of using DAG-based analysis to verify the validity of transactions is to verify the validity of transactions in parallel and thus achieve improved transaction throughput.

[0096] Figure 4D shows a process 400D for selectively verifying the validity of a block during the storage of a new transaction, according to an exemplary embodiment. By default, in existing blockchain protocols, a blockchain peer needs to verify the validity of all previous blocks of the current block before verifying the validity of the transactions of the current block. This leads to low transaction throughput. In particular, the keys in the previous block may not be relevant to the peer executing the current block (e.g., the previous block contains transactions related to different smart contracts within the same network, etc.). In the exemplary embodiment, the blockchain peer 420 does not need to verify the validity of all preceding blocks before verifying the validity of the transactions within the current block, which results in higher transaction throughput.

[0097] In process 400D of Figure 4D, the blockchain peer 420 may obtain details of previous transactions (along with their block numbers) on which the current transaction depends from the ordering node, which is made possible due to metadata (such as a hash set, etc.) available at the ordering node. The blockchain peer 420 can selectively verify the validity of only the preceding transactions on which the current transaction depends (without waiting for the validity verification of other transactions in the previous block) before verifying the validity of the current transaction. This results in improved transaction throughput.

[0098] As described with respect to FIG. 1B, the ordering node may include a list of transactions that update any particular key-value pair (e.g., to periodically update the ROI rate of interest) (along with the blocks in which each of these transactions resides). This metadata is maintained at the ordering node. This metadata may include identification information for each key and its dependencies. Here, the blockchain peer 420 identifies the keys of the read / write set of transactions. In this way, the peer attempts to find the metadata for each of these keys (i.e., the selective transactions and blocks that update a particular key) from the ordering node. In the example of FIG. 4D, the blockchain peer 420 receives the transaction of block 37. Based on the hash set from the ordering node, the blockchain peer 420 identifies that the dependencies of the keys of the transaction of block 37 are included in blocks 29, 17, and 16. Thus, the blockchain peer 420 may selectively verify the validity of only blocks 29, 17, and 16 that depend on the transaction within block 37, rather than verifying the validity of all blocks.

[0099] In the example of FIG. 4D, the blockchain peer 420 may obtain details of the previous transactions of the transactions within the current block (along with the block numbers in which these transactions are included) from the metadata maintained by the ordering node. Different transactions within a block (or across multiple blocks) may depend on different smart contracts. Thus, not all transactions are related to each other.

[0100] In the example of FIG. 4D, the blockchain peer 420 may process only selective blocks that contain transactions on which the current transaction in block 37 depends. In this case, the validity of transactions in the selected blocks that do not depend on the current transaction is also not verified. This overcomes the requirement to complete the verification of the validity of all previous block transactions of the current block, thereby greatly improving the transaction throughput.

[0101] FIG. 4E shows a process 400E for partially ordering encrypted blocks of data, according to an example embodiment. In this example, the ordering node 450 can perform a partial ordering of the blocks even in situations where the transactions are encrypted (thus hiding the dependencies). For example, due to privacy concerns, transactions may be encrypted along with the read / write set. A key may be associated with each encrypted transaction to allow the ordering node 450 to place the transactions in a slot-by-slot manner. Here, the key may be assigned by a transaction submitter such as a client, peer, etc. Transactions associated with each other may be submitted with the same key. In the example of FIG. 4E, the keys are "quality", "payment", and "transport".

[0102] In this example, the keys are assigned to transactions and may include different key names. Transactions containing the same key may be dependent on each other. However, transactions containing different keys should not have a dependency relationship between those transactions. For example, the read / write set of a transaction containing a quality key should be different from the read / write set of a transaction to which a transport key is assigned. According to various embodiments, the ordering node 450 may utilize these keys to place transactions into slots and take advantage of parallelism in the case of encrypted transactions. Specifically, the ordering node 450 assigns the block of a transaction containing a quality key to cluster 452, the block of a transaction containing a payment key to cluster 454, and the block of a transaction containing a transport key to cluster 456. Here, although all transactions are encrypted, the ordering node identifies a cluster of keys for each block.

[0103] According to various embodiments, the ordering node 450 can place blocks into slots on the blockchain 460. Specifically, one block from each of clusters 442, 444, and 446 may be ordered in parallel in the same slot. Thus, the maximum number of blocks within a slot can be equal to the number of clusters of keys. Here, the blocks are labeled with an identifier 462 to represent the keys of the stored transactions. In this way, encrypted transactions can still be placed into slots. The keys are assigned for each transaction by the submitter of the transaction. The ordering node 450 uses these keys to determine into which slot the blocks of transactions containing the same key should be classified.

[0104] Figure 5 shows a method 500 for verifying the validity of blocks in parallel during the operation of a peer, according to an exemplary embodiment. For example, method 500 may be executed during a peer's recovery operation, startup operation, etc. Referring to Figure 5, at 510, the method may include receiving blocks of the blockchain from an adjacent blockchain peer. For example, the blocks may be received by the blockchain peer during a startup process, recovery process, validity check, etc. The adjacent peer may be included in the same blockchain network as the peer receiving the blocks. In some embodiments, when the blockchain peer is performing a recovery operation or a startup operation, the method may further include initializing a local blockchain ledger during at least one of the startup process and the recovery process.

[0105] At 520, the method may include identifying two or more blocks from among the received blocks that belong to the same slot in the blockchain. For example, these two or more blocks may include only transactions that do not depend on transactions in other blocks within the slot. For example, the first and second blocks may be considered non-dependent blocks if no transaction in the first block depends on a transaction in the second block and no transaction in the second block depends on a transaction in the first block. However, it is possible that a transaction in the first block may depend on other transactions in the first block. Similarly, a transaction in the second block may depend on other transactions in the second block. However, the transactions may not have dependencies between blocks.

[0106] In some embodiments, identifying may include identifying which of the received blocks belong to the same slot based on the hash values stored in the received blocks. In some embodiments, identifying may include determining that a block belongs to the current slot if the hash value of the block immediately preceding it is a function of the hashes of a plurality of blocks stored in the immediately preceding slot on the blockchain.

[0107] At 530, the method may include concurrently verifying the validity of two or more identified blocks by concurrently executing the two or more identified blocks. Further, at 540, the method may include storing the two or more identified blocks in a local blockchain ledger of the blockchain peer in response to verifying the validity of the two or more identified blocks. According to various embodiments, verifying the validity may include concurrently (temporally overlapping) executing the two or more identified blocks on two or more independent processor cores of the blockchain peer.

[0108] In some embodiments, the method may further include identifying two or more other blocks on the blockchain belonging to the immediately preceding slot. In this example, the method may further include, if the two or more other blocks do not depend on the two or more identified blocks belonging to the same slot, concurrently verifying the validity of the two or more other blocks belonging to the immediately preceding slot in parallel with the two or more identified blocks.

[0109] FIG. 6A shows an exemplary system 600 that includes a physical infrastructure 610 configured to perform various operations according to an exemplary embodiment. Referring to FIG. 6A, the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may be present in the blockchain 620) that may execute any of the operation steps 608 (within the module 612) included in any of the exemplary embodiments. The step / operation 608 may include one or more of the embodiments described or shown in the figures and may represent information that is written to, read from, output, or written by one or more smart contracts 630 or blockchains 620 or both. The physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof. Further, the module 612 and the module 614 may be the same module.

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

[0111] FIG. 6C shows an exemplary system configured to utilize a mediation server configured to implement the conditions of a smart contract for a blockchain and the configuration of the smart contract among contracting parties, in accordance with an embodiment example. Referring to FIG. 6C, configuration 650 may represent a communication session, an asset transfer session, or a process or procedure, which is operated by a smart contract 630 that explicitly identifies one or more user devices 652 or 656 or both. The execution, operation, and results of the execution of the smart contract may be managed by server 654. The content of smart contract 630 may require a digital signature by one or more of entities 652 and 656, which are parties to the smart contract transaction. The execution result of the smart contract may be written to blockchain 620 as a blockchain transaction. Smart contract 630 may exist in blockchain 620, which may exist in one or more computers, servers, processors, memories, or wireless communication devices, or combinations thereof.

[0112] FIG. 6D shows a system 660 including a blockchain according to an example embodiment. Referring to the example of FIG. 6D, an application programming interface (API) gateway 662 provides a common interface for accessing the logic of the blockchain (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 executing transactions (calls, queries, etc.) against the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, the server 654 is a peer component of the blockchain network that holds copies of the world state and the distributed ledger, and these copies enable clients 652 and 656 to query data regarding the world state and submit transactions to the blockchain network, and in accordance with the smart contract 630 and the signature policy, the signing peers execute the smart contract 630.

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

[0114] An exemplary storage medium may be coupled to the 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 in an application specific integrated circuit (ASIC). Alternatively, the processor and the storage medium may be present as discrete components.

[0115] FIG. 7A shows a process 700 of a new block added to the distributed ledger 720 according to an embodiment example, and FIG. 7B shows the content of a new data block structure 730 of the blockchain according to the embodiment example. Referring to FIG. 7A, a client (not shown) may submit a transaction to a blockchain node 711, 712, or 713, or a combination thereof. The client may be an instruction received from any source for defining activities for the blockchain 720. As an example, the client may be an application that operates on behalf of a requester such as a device, person, or entity that proposes a transaction for the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain a copy of the state of the blockchain network and the distributed ledger 720. Various types of blockchain nodes / peers, including a signature peer that simulates and signs a transaction proposed by the client, and a commit peer that verifies the signature, confirms the validity of the transaction, and commits the transaction to the distributed ledger 720, may exist within the blockchain network. In this example, blockchain nodes 711, 712, and 713 may perform the role of a signer node, a committer node, or both.

[0116] The distributed ledger 720 includes a blockchain that stores immutable and ordered records within a block, and a state database 724 (the current world state) that maintains the current state of the blockchain 722. There may be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel of which the peer is a member. The blockchain 722 is a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. The block may include various components, such as the components shown in FIG. 7B. The link of the block (indicated by the arrow in FIG. 7A) may be generated by adding the hash of the previous block's header into the block header of the current block. In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together, preventing the blockchain data from being tampered with without breaking the hash link. Further, due to these links, the latest block in the blockchain 722 represents all transactions that came before it. The blockchain 722 may be stored in the peer's file system (local or attached storage) that supports the workload of an append-only blockchain.

[0117] The current state of the blockchain 722 and the distributed ledger 720 may 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 within the state database 724. To make the interaction of those chain codes extremely efficient, the latest values of all keys are stored in the state database 724. The state database 724 may 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 may be automatically restored (or generated if necessary) at the startup of the peer, before transactions are received.

[0118] The signing node receives a transaction from the client and signs the transaction based on the simulation result. The signing node holds a smart contract that simulates the transaction proposal. When the signing node signs the transaction, the signing node generates a signature of the transaction that is a signed response from the signing node indicating the signature of the simulated transaction to the client application. The way to sign a transaction is determined by a signature policy that may be specified within the chain code. An example of a signature policy is that "a majority of the signing peers must sign the transaction". Different channels may have different signature policies. The signed transaction is forwarded by the client application to the ordering service 710.

[0119] The ordering service 710 receives signed transactions, orders them within a block, and distributes the block to commit peers. For example, the ordering service 710 may start a new block when a threshold of transactions is reached, a timer times out, or another condition occurs. In the example of FIG. 7A, the blockchain node 712 is a commit peer that has received a new data block 730 of new data for storage in the blockchain 720. The first block in the blockchain may be called a genesis block that contains information about the blockchain, the members of the blockchain, the stored data, and so on.

[0120] The ordering service 710 may be composed of a cluster of ordering nodes. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 710 may receive signed transactions and specify the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network may be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a detachable component.

[0121] 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 the transactions are committed to the network. Unlike a cryptocurrency blockchain system (e.g., Bitcoin, etc.) where ordering occurs by solving a cryptographic puzzle or mining, in this example, the stakeholders of the distributed ledger 720 may select the ordering mechanism most suitable for their network.

[0122] The ordering service 710 initializes a new data block 730, and the new data block 730 may be broadcast to commit peers (e.g., blockchain nodes 711, 712, and 713). In response, each commit peer checks and verifies the validity of the transactions in the new data block 730 by checking that the read set and write set still match the current world state in the state database 724. In particular, the commit peer can determine whether the read data that existed when the signer simulated the transaction is identical to the current world state in the state database 724. If the commit peer verifies the validity of the transaction, the transaction is written to the blockchain 722 of the distributed ledger 720, and the state database 724 is updated with the write data from the read / write set. If the transaction fails, i.e., the commit peer detects 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 that block but marked as invalid, and the state database 724 is not updated.

[0123] Referring to FIG. 7B, a new data block 730 (also referred to as a data block) stored in the blockchain 722 of the distributed ledger 720 may include 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 illustrated blocks and their contents, such as the new data block 730 and its contents shown in FIG. 7B, are merely examples and are not intended to limit the scope of the exemplary embodiments. The new data block 730 may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions within the block data 750.

[0124] According to various embodiments, the new data block 730 may include a link to the previous slot on the blockchain within the block header 740. In particular, the block header 740 may include a hash function 742 of the previous slot of the block. In some embodiments, the hash function 742 may include an exclusive OR of the hash of the set of blocks (or the hash of the documents within the set of blocks) included in the immediately previous slot. As another example, the hash function 742 may include a composite hash of the hash of the set of blocks (or the hash of the documents within the set of blocks) included in the previous slot.

[0125] The block header 740 may also include a unique block number of the new data block 730, a hash of the block data 750, etc. The block number of the new data block 730 is unique and may be assigned in various orders such as a progressive / sequential order starting from 0.

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

[0127] Block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). Metadata fields may include a signature at block creation, a reference to the last configuration block, a transaction filter that identifies valid and invalid transactions within the block, a persistent last offset of an ordering service that orders the blocks, and the like. Signatures, the last configuration block, and metadata of the ordering nodes may be added by the ordering service 710. On the other hand, a block committer (such as blockchain node 712) may add valid / invalid information based on a signature policy, verification of read / write sets, and the like. The transaction filter may include a byte array of a size equal to the number of transactions within block data 750, and a validity check code that identifies whether the transaction was valid / invalid. In some embodiments, although not shown in FIG. 7B, block metadata 760 may store metadata of a recommended smart contract therein.

[0128] FIG. 7C shows an embodiment of a blockchain 770 for digital content according to the embodiments described herein. The digital content may include one or more files and related information. These files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable append-only feature of the blockchain serves as a precautionary measure to protect the integrity, validity, and reliability of digital content, and enables the use of the blockchain appropriately in legal procedures where admissibility rules apply, or in other settings where evidence is considered, or the presentation and use of digital information is otherwise subject. In this case, the digital content may sometimes be referred to as digital evidence.

[0129] The blockchain may be formed in various ways. In one embodiment, the digital content may be included in the blockchain itself and may be accessed from the blockchain itself. For example, each block of the blockchain may store the hash value of reference information (e.g., header, value, etc.) together with the associated digital content. Subsequently, the hash value and the associated digital content may be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis for referring to the previous block. This may be shown as follows. Block 1 Block 2 ··· Block N Hash value 1 Hash value 2 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 may store the encrypted hash of the content of each block that does not contain digital content. The digital content may be stored in another storage area or memory address in relation to the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area or a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the target block and then searching within the storage area for the hash value stored corresponding to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be shown 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 embodiment of FIG. 7C, the blockchain 770 includes a plurality of blocks 7781, 7782,... 778 that are cryptographically linked in a sequenced order N where N≥1. The encryption used to link the blocks 7781, 7782,... 778 N may be either a plurality of keyed hash functions or a keyless hash function. In one embodiment, the blocks 7781, 7782,... 778 N are subject to a hash function that generates an alphanumeric output of n bits from an input based on the information within the block (n is 256 or another number). Examples of such hash functions include, but are not limited to, SHA-type (SHA represents Secure Hash Algorithm) algorithms, Merkle-Damgård algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and collision-resistant PRF algorithms. In another embodiment, the blocks 7781, 7782,... 778 N may be cryptographically linked by a function different from a hash function. For illustrative purposes, the following description will refer to a hash function (e.g., SHA-2).

[0132] Each of the blocks 7781, 7782,... 778 within the blockchain N includes 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 process within the blockchain. In one embodiment, the value may be included in the header. As will be described 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 7781 within the blockchain is called the genesis block and contains a header 7721, an original file 7741, and an initial value 7761. The hashing method used for the genesis block (and actually for all subsequent blocks) may vary. For example, all the information within the first block 7781 may be hashed together simultaneously, or each or part of the information within the first block 7781 may be hashed separately, and then the hashes of the separately - hashed parts may be executed.

[0134] The header 7721 may contain one or more initial parameters, which may include, for example, a version number, a timestamp, a nonce, root information, difficulty, a consensus protocol, a period, a media format, a source, descriptive keywords, or other information associated with the original file 7741 or the blockchain or both, or a combination thereof. The header 7721 may be generated automatically (e.g., by blockchain - network management software) or manually by participants in the blockchain. Unlike the headers within other blocks 7782 - 778 N within the blockchain, the header 7721 within the genesis block does not refer to a previous block simply because there is no previous block.

[0135] The original file 7741 within the genesis block may be, for example, data captured by a device, with or without previous processing included in the blockchain. The original file 7741 is received from a device, a media source, or a node via the system interface. The original file 7741 is associated with metadata, which may be generated either manually or automatically by, for example, a user, a device, or a system processor or a combination thereof. The metadata may be included in the first block 7781 in relation to the original file 7741.

[0136] The value 7761 within the Genesis Block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may include the hash value of the original file 7741, the metadata of the original file 7741, and other information associated with the file. In one implementation, the initial value 7761 may be based on the following unique attributes. 1) The hash value calculated for the original file by SHA-2 2) The transmitting device ID 3) The start timestamp of the original file 4) The initial storage location of the original file 5) The blockchain network member ID of the software for currently controlling the original file and related metadata

[0137] The other blocks 7782 - 778 within the blockchain N also contain headers, files, and values. However, unlike the first block 7721, the headers 7722 - 772 within the other blocks N each contain the hash value of the previous block. The hash value of the previous block may simply be the hash of the header of the previous block, or it may be the hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, as indicated by the arrow 780, a trace block by block can be executed from the Nth block back to the Genesis Block (and the associated original file), establishing an auditable and immutable evidence preservation.

[0138] The headers 7722 - 772 within the other blocks N each may generally include other information (e.g., version number, timestamp, nonce, root information, difficulty, consensus protocol, or other parameters or information associated with the corresponding file or blockchain or both, or a combination thereof).

[0139] Files 7742 - 774 within other blocks N may be the same as the original files within the genesis block, or a modified version of the original files, depending on, for example, the type of processing to be performed. The type of processing to be performed may vary from block to block. The processing may include any modification of the files within the preceding blocks, such as editing the information, or otherwise changing the content of the information, removing the information from the file, or adding the information to the file.

[0140] Additionally or alternatively, the processing may include simply copying the files from the preceding blocks, changing the storage location of the files, analyzing the files from one or more preceding blocks, moving the files from one storage or memory location to another, or performing operations on the files of the blockchain or the associated metadata or both. The processing that includes analyzing the files may include, for example, adding, including, or otherwise associating various analyses, statistical values, or other information associated with the files.

[0141] Other blocks 7762 - 776 within other blocks N Each of the values contained in each of the other blocks is a unique value and all are different as a result of the processing performed. For example, the value within any one block corresponds to an updated version of the value within the previous block. This update is reflected in the hash of the block in which the value was assigned. Thus, the value of the block provides an indication of what processing was performed within the block and also makes it possible to trace back the blockchain to the original files. This tracing verifies the integrity of the files throughout the blockchain.

[0142] For example, consider the case where a portion of a file within a block is edited, blocked, or pixelated in order to protect the identification information of the person shown in the file. In this case, the block containing the edited file will include metadata associated with the edited file, such as, for example, how the edit was performed, who performed the edit, and the timestamp at which the edit occurred. This metadata may be hashed to form a value. Since the metadata of the block is different from the information hashed to form the value within the previous block, the values will be different from each other and may be recovered when decoded.

[0143] In one embodiment, the value of the previous block may be updated (e.g., a new hash value may be calculated) to form the value of the current block if any one or more of the following occur. The new hash value may be calculated in this example embodiment by hashing all or a portion of the information shown below. a) The hash value calculated by a new SHA-2 when the file is processed in any way (e.g., the file is edited, copied, changed, accessed, or other operations are performed) b) The new storage location of the file c) The newly identified metadata associated with the file d) The transfer of access or control of the file from a participant in one blockchain to a participant in another blockchain

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

[0145] Header 772 iis the hash value of the previous block (block i-1 ) described in this specification, and additional reference information (e.g., header information containing references, characteristics, parameters, etc.) that may be either of the types of information, for example. All blocks, except the genesis block of course, refer to the hash of the previous block. The hash value of the previous block may simply be the hash of the header within the previous block, or the hash of all or part of the information within the previous block, including files and metadata.

[0146] File 774 i contains a plurality of data such as data 1, data 2,..., data N in sequence. The data is tagged with metadata (metadata 1, metadata 2,..., metadata N) that describes the content or characteristics associated with the data or both. For example, the metadata for each data may be a time stamp of the data, a process of the data, keywords indicating a person or other content shown in the data, or other features that can help in using digital evidence as described, in particular, as described in the embodiments related to the embodiments described below, or information indicating a combination thereof. In addition to the metadata, each data may be tagged with a reference to the previous data (reference 1, reference 2,..., reference N ) to prevent tampering, gaps within the file, and continuous references throughout the file.

[0147] After the metadata is assigned to the data (e.g., via a smart contract), the metadata cannot be changed without changing the hash, and the change in the hash can be easily identified as invalid. Thus, the metadata creates a data log of information that may be accessed by participants within the blockchain for use.

[0148] Value 776 iis a hash value or other value calculated based on any of the types of information described previously. For example, in the case of any particular block (block i ), the value of that block may be updated to reflect the processing performed on that block (e.g., a new hash value, a new storage location, new metadata for related files, transfer of control or access, an identifier, or other operations or information added). Although the values within each block are shown as being separated from the metadata of the file and header data, in another embodiment, the values may be based in part or in whole on this metadata.

[0149] After the blockchain 770 is formed, at any point in time, non-repudiable evidence preservation of the file may be obtained by querying the blockchain regarding the transaction history of the values across the entire block. This querying procedure or tracking procedure may start by decrypting the value of the last 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 may further include decrypting the header and file as well as related metadata at each block.

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

[0151] Generating a key pair is similar to creating an account on the blockchain, but in fact, there is no need to register anywhere. Also, all transactions performed on the blockchain are digitally signed by the sender using the private key. This signature ensures that only the owner of the account (when within the scope of permission determined by the smart contract) can track and process the blockchain files.

[0152] Figures 8A and 8B show additional use cases of the blockchain that may be incorporated and used herein. In particular, Figure 8A shows an example 800 of a blockchain 810 that stores machine learning (artificial intelligence) data. Machine learning relies on large amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can often select among millions of records to discover non-intuitive patterns.

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

[0154] The blockchain 810 can be used to significantly improve both the training process 802 of the machine learning model and the prediction process 804 based on the trained machine learning model. For example, in 802, instead of requiring a data scientist / technician or other user to collect data, historical data regarding the blockchain 810 may be stored by the asset 830 itself (or via an intermediate not shown). This can significantly reduce the collection time required by the host platform 820 when executing the training of the prediction model. For example, using smart contracts, data can be transferred directly and securely from the original location to the blockchain 810. Smart contracts can use the blockchain 810 to directly transmit data from the asset to the individual using the data to build the machine learning model by guaranteeing the security and ownership of the collected data. This enables the sharing of data between assets 830.

[0155] The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism controls (the permitted nodes) to ensure that the recorded data is verified and accurate. The recorded data is timestamped, signed by encryption, and immutable. Therefore, the recorded data is auditable, transparent, and secure. By adding IoT devices that write directly to the blockchain, in certain cases (i.e., in the cases of supply chain, healthcare, logistics, etc.), the frequency of data recording can be increased and its accuracy can be improved.

[0156] Furthermore, the training of the machine learning model on the collected data may require a series of improvements and tests by the host platform 820. Each improvement and test may be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. In 802, different training steps and test steps (and related data) may be stored in the blockchain 810 by the host platform 820. Each improvement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored in the blockchain 810. This provides a verifiable proof of how the model was trained and what data was used to train the model. Furthermore, when the host platform 820 realizes the final trained model, the obtained model may be stored in the blockchain 810.

[0157] After the model has been trained, the model may be deployed in an operating environment and can make predictions / decisions based on the execution of the final trained machine learning model. For example, at 804, the machine learning model may be used for condition-based maintenance (CBM) for assets such as aircraft, wind turbines, and medical devices. In this example, data fed back from asset 830 may be input into the machine learning model and used to make event predictions such as failure events, error codes, etc. Decisions made by the execution of the machine learning model on host platform 820 may be stored in blockchain 810 to provide an auditable / verifiable proof. As one non-limiting example, the machine learning model may predict future stops / failures in the components of asset 830 and create warnings or notifications to replace those components. The data behind this decision may be stored in blockchain 810 by host platform 820. In one embodiment, features or operations or both described or shown or both herein may occur on or with respect to blockchain 810.

[0158] New transactions on the blockchain can be gathered together into a new block and added to the existing hash value. This hash value is then encrypted to generate a new hash for the new block. This new hash is added to the next list of transactions, such as when the transaction is encrypted. The result is a chain of blocks, each containing the hash values of all previous blocks. The computers storing these blocks periodically compare the hash values of the blocks to confirm that all of those computers agree. Any computers that do not agree discard the records causing the problem. This method is suitable for ensuring the prevention of blockchain tampering, but is not perfect.

[0159] One way to manipulate this system illegally is for an unauthorized user to modify the list of transactions to their advantage without changing the hash. This can be carried out by a brute - force attack, which, in other words, can be executed by modifying the records, encrypting the results, and checking whether the hash values are the same. If the hash values are not the same, keep trying repeatedly until a matching hash is found. The security of the blockchain is based on the idea that a normal computer can only execute this kind of brute - force attack over an impractically long time scale, such as the age of the universe. In contrast, quantum computers are extremely fast (thousands of times faster) and thus pose a very significant 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 use QKD to verify each other's identification information. In this verification, quantum particles such as photons are used to transmit information, and this information cannot be copied by eavesdroppers without being destroyed. In this way, the sender and the receiver can confirm each other's identification information via the blockchain.

[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. Since there are four nodes in this example, there are six pairs of nodes, and thus, QKD AB 、QKD AC 、QKD AD 、QKD BC 、QKD BD 、およびQKD CDSix different secret keys 862 are used, including. Each pair can create QKD by transmitting information using quantum particles such as photons, and this information cannot be copied by eavesdroppers without being destroyed. In this way, pairs of users can confirm each other's identification information.

[0162] The operation of the blockchain 852 is based on two procedures: (i) creation of a transaction and (ii) construction of a block that collects new transactions. New transactions may be created in the same way as in a conventional blockchain network. Each transaction may include information such as the sender, the receiver, the creation time, the 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 among 854 to 860) authenticate the transaction by providing a shared secret key 862 (QKD). This quantum signature is attached to all transactions and can make it extremely difficult to forge. Each node checks the entry of the transaction 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, a broadcast protocol may be used to create the block in a decentralized manner. At a given period (e.g., seconds, minutes, hours, etc.), the network may apply the broadcast protocol to any unconfirmed transaction, thereby achieving a Byzantine consensus (agreement) regarding the correct version of the transaction. For example, each node may own a private value (the transaction data of that particular node). First, the nodes send the private values to each other. Then, the nodes communicate the information received from other nodes last time. Here, an authentic 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, features or operations or both, described or shown or both herein, can occur in or with respect to the blockchain 852.

[0164] FIG. 9 illustrates an exemplary system 900 that supports one or more of the embodiments described or shown or both in this specification. System 900 includes a computer system / server 902 that can operate in a number of other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations suitable for use with computer system / server 902, or combinations thereof, include, but are not limited to, 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] Computer system / server 902 may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system / server 902 may operate 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 may be located in both local and remote computer system storage media including memory storage devices.

[0166] As shown in FIG. 9, the computer system / server 902 within the cloud computing node 900 is shown in the form of a general-purpose computing device. The components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, 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 any of a plurality of types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus that uses any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (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, including volatile and nonvolatile media, removable and non-removable media. The system memory 906, in one embodiment, 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 may 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 (R) 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 will be shown and described in detail below, the memory 906 may include at least one program product including a series of (e.g., at least one) program modules configured to execute the functions of the various embodiments of the present application.

[0169] For example, a program / utility 916 including a series of (at least one) program modules 918 may be stored in the memory 906, but is not limited thereto, and an operating system, one or more application programs, other program modules, and program data may also be stored. Each of the operating system, one or more application programs, other program modules, and program data or combinations thereof may include an implementation of a network environment. The program modules 918 typically execute the functions or methods or both of the various embodiments of the present application described herein.

[0170] As will be understood by those skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may 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, all of which may generally be referred to herein as a "circuit", "module", or "system". Further, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied therein.

[0171] In addition, 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, 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 I / O interface 924. Further, the computer system / server 902 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via the network adapter 926. As shown in the figure, 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 components or software components or both can be used in combination 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] Examples of at least one embodiment of a system, method, and non-transitory computer-readable medium are shown in the accompanying drawings and described in the foregoing detailed description, but it is to be understood that this application is not limited to the disclosed embodiments and that numerous rearrangements, changes, and substitutions can be made as defined by the following claims. For example, the functions 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 a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by individual modules may be performed by one or more of those modules. Further, the functions described herein may be performed at various times, with respect to various events, inside or outside of a module or component. Also, the information transmitted between the various modules may 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 a plurality of protocols, or a combination thereof. Also, a message transmitted or received by any of the modules may 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 the "system" can be embodied as a personal computer, server, console, PDA (personal digital assistant), mobile phone, tablet computing device, smartphone, or any other suitable computing device, or a combination of devices. Presenting the foregoing functions executed by the "system" is not at all intended to limit the scope of this application, but rather is intended to provide an example of one of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein may be implemented in a locally distributed form consistent with computing technology.

[0174] It should be noted that some of the features of the system described herein are presented as modules in order to particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising a custom very large-scale integration (VLSI) circuit or gate array, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device, graphics processing unit, and the like.

[0175] The module may be implemented at least in part in software for execution by various types of processors. For example, an identified unit of executable code may comprise one or more physical or logical blocks of computer instructions that may be organized, for example, as objects, procedures, or functions. Nevertheless, the executable of the identified module need not be physically collocated, may include heterogeneous instructions stored at different locations, and those instructions, when logically combined, comprise the module and achieve the defined purpose of the module. Further, the module may be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash device, a random access memory (RAM), a tape, or any other medium used for storing data.

[0176] In fact, a module of executable code can be a single instruction or many instructions and may be distributed across different programs and multiple memory devices over multiple different code segments. Similarly, operable data may be identified and shown herein within a module, embodied in any suitable form, and organized within any suitable type of data structure. The operable 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 in part as merely electronic signals on a system or network.

[0177] As schematically illustrated and described in the figures herein, it will be readily understood that the components of the present application may be arranged and designed in a wide variety of different configurations. Accordingly, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but merely represents selected embodiments of the present application.

[0178] Those skilled in the art will readily understand that the foregoing can be practiced using steps in a different order than those disclosed, using hardware elements different from those in the disclosed configurations, or both. Accordingly, although this application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain changes, modifications, and alternative structures are obvious.

[0179] Preferred embodiments of this application have been described, but the described embodiments are merely examples, and it should be understood that the scope of this application should be defined only by the appended claims when considering equivalents of those embodiments and the full scope of changes to those embodiments (e.g., protocols, hardware devices, software platforms, etc.).

Claims

**Claim 1**: An apparatus for a blockchain peer, comprising: a network interface configured to receive blockchain blocks from one or more of the blockchain peers adjacent to the blockchain peer and the ordering service nodes such that the blockchain peer receives the blocks; a processor configured to identify two or more blocks belonging to the same slot in the blockchain from among the received blocks, confirm the validity of the two or more identified blocks in parallel by simultaneously executing the two or more identified blocks, and store the two or more identified blocks in a local blockchain ledger of the blockchain peer in response to the confirmation of the validity of the two or more identified blocks. **Claim 2** The apparatus according to claim 1, wherein the two or more identified blocks belonging to the same slot are non-dependent blocks with respect to each other. **Claim 3** The apparatus according to claim 1, wherein the processor is configured to execute the two or more identified blocks in parallel and simultaneously on two or more independent processor cores of the blockchain peer where the two or more identified blocks are to be stored in the blockchain ledger. **Claim 4** The apparatus according to claim 1, wherein the processor is further configured to initialize the local blockchain ledger for at least one of a startup process and a recovery process. **Claim 5** The apparatus according to claim 1, wherein the processor is further configured to identify two or more other blocks on the blockchain belonging to the immediately preceding slot. **Claim 6** The apparatus according to claim 5, wherein the processor is further configured to confirm the validity of the two or more blocks belonging to the immediately preceding slot in parallel with the two or more identified blocks when the two or more other blocks do not depend on the two or more identified blocks belonging to the same slot. **Claim 7** The apparatus according to claim 1, wherein the processor is configured to identify which of the received blocks belong to the same slot based on hash values stored in the received blocks. **Claim 8** The apparatus according to claim 1, wherein the processor determines that the block belongs to the current slot when the hash value immediately before the block is a function of the hashes of a plurality of blocks stored in the immediately preceding slot on the blockchain.

9. A method comprising steps executed by a blockchain peer, receiving a block of the blockchain from one or more of a blockchain peer adjacent to the blockchain peer and an ordering service node; identifying, from among the received blocks, two or more blocks belonging to the same slot within the blockchain; confirming the validity of the two or more identified blocks in parallel by simultaneous execution of the two or more identified blocks; and storing the two or more identified blocks in a local blockchain ledger of the blockchain peer in response to the confirmation of the validity of the two or more identified blocks.

10. The method according to claim 9, wherein the two or more identified blocks belonging to the same slot are non-dependent blocks with respect to each other.

11. The method according to claim 9, wherein the validity confirmation includes simultaneously executing the two or more identified blocks in parallel on two or more independent processor cores of the blockchain peer that will store the two or more identified blocks in the blockchain ledger.

12. The method according to claim 9, further comprising initializing the local blockchain ledger during at least one of a startup process and a recovery process.

13. The method according to claim 9, further comprising identifying two or more other blocks on the blockchain belonging to the immediately preceding slot.

14. The method according to claim 13, further comprising, when the two or more other blocks belonging to the immediately preceding slot do not depend on the two or more identified blocks belonging to the same slot, confirming the validity of the two or more other blocks belonging to the immediately preceding slot in parallel with the two or more identified blocks.

15. The method according to claim 9, wherein the identifying step includes identifying, based on a hash value stored in the received block, which of the received blocks belong to the same slot.

16. The method according to claim 9, wherein the identifying step includes determining that the block belongs to the current slot if a hash value immediately preceding the block is a function of hashes of a plurality of blocks stored in the immediately preceding slot on the blockchain.

17. A computer program for operating a computer as a blockchain peer, the computer program for causing a computer to execute each step of the method according to any one of claims 9 to 16.

18. A non-transitory computer-readable medium having recorded thereon the computer program according to claim 17.

Images