Valid threshold storage for data objects

Abstract

Example operations may include one or more of: dividing a data object into a plurality of portions; hashing the data object to generate a hashed data object; and hashing the plurality of portions to generate a plurality of hashed portions; generating a plurality of slices, wherein each slice includes the hashed data object and a different corresponding hashed portion; and distributing the plurality of slices across a plurality of blockchain peers, respectively.

Description

Technical Field

[0001] The present application relates generally to storing data on a blockchain, and more particularly, to breaking up a large data object into slices and distributing the slices across multiple blockchain peers. Background Art

[0002] A centralized database stores and maintains data in a single database (e.g., a database server) at a location. The location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored on a centralized database is typically accessible from multiple different points. Multiple users or client workstations can work on a centralized database simultaneously, for example, based on a client / server configuration. A centralized database is easy to manage, maintain, and control due to its single location, especially for security purposes. Within a centralized database, data redundancy is minimized because a single storage location for all data also means that a given data set has only one primary record.

[0003] However, centralized databases have significant disadvantages. For example, if fault tolerance is not considered, centralized databases have a single point of failure. Therefore, if a hardware failure (e.g., hardware, firmware, and / or software failure) occurs, all 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, the slower the connection, the amount of time required for each database access increases. Another disadvantage is that bottlenecks occur when centralized databases experience high traffic due to a single location. In addition, centralized databases provide limited access to data because the database is maintained with only one copy of the data.

[0004] Organizations have recently turned to blockchain as a means for securely storing data that is not restricted by a central entity and is accessible from multiple points. In a blockchain network, peers are responsible for collectively managing and storing data on the blockchain. In a traditional blockchain, each peer stores a copy of a data object, providing redundancy without the need for a central storage. For larger data files, peers may store a hash of the data object on the blockchain while storing the actual data object in off-chain storage. However, this storage process breaks the security of the blockchain by relying on an external entity (off-chain storage) to store the data. Therefore, what is needed is a solution that overcomes these shortcomings and limitations. Summary of the invention

[0005] An example embodiment provides a system, the system comprising one or more processors, the processors being configured to perform one or more of the following: dividing a data object into a plurality of parts; hashing the data object to generate a hashed data object; and hashing the plurality of parts to generate a plurality of hashed parts; and generating a plurality of slices, wherein each slice comprises a hashed data object and a different corresponding hashed part; and a network interface configured to distribute the plurality of slices across a plurality of blockchain peers, respectively.

[0006] Another example embodiment provides a method, the method comprising one or more of: dividing a data object into a plurality of parts; hashing the data object to generate a hashed data object; and hashing the plurality of parts to generate a plurality of hashed parts; generating a plurality of slices, wherein each slice comprises the hashed data object and a different corresponding hashed part; and distributing the plurality of slices across a plurality of blockchain peers, respectively.

[0007] Yet another example embodiment provides a non-transitory computer-readable medium comprising instructions which, when read by a processor, cause the processor to perform one or more of: partitioning a data object into a plurality of portions; hashing the data object to produce a hashed data object; and hashing the plurality of portions to produce a plurality of hashed portions; generating a plurality of slices, wherein each slice comprises a hashed data object and a different corresponding hashed portion; and distributing the plurality of slices respectively across a plurality of blockchain peers. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A diagram illustrating a blockchain network for storing data objects in slices according to an example embodiment.

[0009] Figure 2A is a diagram illustrating a blockchain architecture configuration according to an example embodiment.

[0010] Figure 2B is a diagram illustrating a blockchain transaction flow according to an example embodiment.

[0011] Figure 3A is a diagram illustrating a permissioned blockchain network according to example embodiments.

[0012] Figure 3B is a diagram illustrating another permissioned blockchain network according to example embodiments.

[0013] Figure 3C is a diagram illustrating an unlicensed blockchain network according to example embodiments.

[0014] Figure 4Ais a diagram illustrating a process of converting a data object into slices according to example embodiments.

[0015] Figure 4B is a diagram illustrating a process of reconstructing a data object from a slice and verifying the data object according to example embodiments.

[0016] Figure 5 A diagram illustrating a method of storing slices of a data object on a blockchain according to an example embodiment.

[0017] Fig. 6A is a diagram illustrating an example system configured to perform one or more operations described herein according to an example embodiment.

[0018] Figure 6B is a diagram illustrating another example system configured to perform one or more operations described herein according to an example embodiment.

[0019] Figure 6C is a diagram illustrating another example system configured to utilize smart contracts according to example embodiments.

[0020] Fig.6D is a diagram illustrating yet another example system configured to utilize blockchain according to example embodiments.

[0021] Fig. 7A is a diagram illustrating a process in which a new block is added to a distributed ledger according to an example embodiment.

[0022] Figure 7B is a diagram illustrating contents of a new data block according to an exemplary embodiment.

[0023] Figure 7C is a diagram illustrating a blockchain of digital content according to example embodiments.

[0024] Fig.7D is a diagram illustrating a block structure that may represent a block in a blockchain according to example embodiments.

[0025] Fig. 8A is a diagram illustrating an exemplary blockchain storing machine learning (artificial intelligence) data according to an exemplary embodiment.

[0026] Figure 8B is a diagram illustrating an exemplary quantum-secure module blockchain according to an exemplary embodiment.

[0027] Fig. 9 is a diagram illustrating an exemplary system that supports one or more exemplary embodiments. Specific embodiments

[0028] It will be readily understood that the components of the present invention, as generally described and illustrated in the drawings herein, may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, devices, non-transitory computer-readable media, and systems as represented in the drawings is not intended to limit the scope of the claimed applications, but is merely representative of selected embodiments.

[0029] In one or more embodiments, the instant features, structures, or characteristics as described throughout this specification may be combined or removed in any suitable manner. For example, the use of the phrases "exemplary embodiments", "some embodiments" or other similar language throughout this specification refers to the fact that the specific features, structures, or characteristics described in conjunction with the embodiments may be included in at least one embodiment. Therefore, the phrases "exemplary embodiments", "in some embodiments", "in other embodiments", or other similar language that appear throughout this specification do not necessarily all refer to the same group of embodiments, and in one or more embodiments, the described features, structures, or characteristics may be combined or removed in any suitable manner. Also, in the figure, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the accompanying drawings may be a different device. For example, if a mobile device is shown as sending information, a wired device may also be used to send the information.

[0030] In addition, although the term "message" may be used in the description of the embodiments, the application may be applied to many types of networks and data. In addition, although specific types of connections, messages and signaling may be described in the exemplary embodiments, the application is not limited to specific types of connections, messages and signaling.

[0031] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks for breaking down a large data object into slices and storing the slices across a set of blockchain peers within a blockchain network.

[0032] In one embodiment, the application utilizes a distributed database (such as a blockchain) as a distributed storage system that includes multiple nodes that communicate with each other. A decentralized database includes an append-only immutable data structure similar to a distributed ledger that can maintain records between mutually untrusted parties. Untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching a consensus between the distributed peers. For example, peers may execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and establish a hash chain on the blocks. For consistency, the process forms an account book by sorting storage transactions as needed. In different embodiments, permissioned and / or unpermissioned blockchains can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains may involve local passwords and use consensus based on different protocols such as proof of work (PoW). On the other hand, a permissioned blockchain database provides secure interactions between a group of entities that share a common goal but do not fully trust each other, such as enterprises that exchange funds, goods, information, etc.

[0033] The present application can utilize a blockchain that operates arbitrary, programmable logic, which is customized as a distributed storage solution and is called a "smart contract" or "chain code". In some cases, there may be a dedicated chain code called a system chain code that manages functions and parameters. Applications can also utilize smart contracts, which are trusted distributed applications that utilize the tamper-proof nature of the blockchain database and the underlying protocol between nodes, which is called endorsement or endorsement policy. Blockchain transactions associated with the present application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. The endorsement policy allows the chain code to specify the endorser for the transaction in the form of a set of peer nodes necessary for the endorsement. When the client sends the transaction to the peer specified in the endorsement policy, the transaction is executed to verify the transaction. After verification, the transaction enters the sorting phase, where an ordered sequence of endorsed transactions grouped into blocks is generated using a consensus protocol.

[0034] The present application may utilize nodes as communication entities of a blockchain system. In the sense that multiple nodes of different types may run on the same physical server, a "node" may perform a logical function. Nodes are grouped in trust domains and are associated with logical entities that control them in different ways. Nodes may include different types, such as clients or submit-client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node that receives transactions submitted by clients, submits transactions, and maintains the state and copy of the ledger of blockchain transactions. Peers may also have the role of endorsers, although it is not required. Ordering-service-nodes or orderers are nodes that run communication services for all nodes, and they implement delivery guarantees, such as broadcasting to each peer node in the system when submitting transactions and modifying the world state of the blockchain, which is another name for the initial blockchain transaction, which typically includes control and setup information.

[0035] The application can utilize a ledger, which is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions can be caused by chaincode invocations (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (such as a peer node) can maintain a copy of the ledger. A transaction can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also called a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0036] The present application can utilize a chain as a transaction log, which is constructed as hashed linked blocks, and each block contains a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hash value of the block's transaction and the hash value of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Thus, it is impossible to tamper with the ledger data without breaking the hash link. The hash value of the most recently added blockchain block represents every transaction that has appeared before the chain, so that all peer nodes can be ensured to be in a consistent and trusted state. The chain can be stored on the peer node file system (i.e., local, attached storage, cloud, etc.), effectively supporting the append-only nature of the blockchain workload.

[0037] The current state of the immutable ledger represents the latest values ​​of all keys included in the chain transaction log. Because the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Chain calls execute transactions against the current state data of the ledger. In order for these chaincode interactions to be efficient, the latest values ​​of the keys can be stored in the state database. The state database can simply be an indexed view into the chain's transaction log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated if necessary) when a peer node starts and before accepting transactions.

[0038] Entries in a blockchain ledger (e.g., a permissioned blockchain) are highly available and resistant to denial of service and denial of service attacks as long as a specified number of members are not compromised. This provides security without relying on any centralized authority over the information stored on the chain. However, the ledger is limited in the amount of data it can store because performance is related to the size of the chain. In addition, the total cost of storage is based on the product of the number of network members that replicate the ledger and the total capacity of the data in all entries because the ledger is fully replicated. In addition, the total network bandwidth required to add an entry is a function of the amount of data transmitted to each member. Therefore, it is not practical to store large objects such as high-resolution medical images, videos, audio, detailed technical designs, etc. in blockchain entries.

[0039] Furthermore, the ledger entries are public to anyone with access to any blockchain peer (member). Thus, if a blockchain peer is compromised, the attacker can see the contents of all ledger entries. While it is possible to store encrypted information in the ledger, this increases the complexity of key management. A centralized key management solution would be simple, but then becomes a single point of control and attack. An alternative using secret sharing would be secure against a single point of attack and eliminate a centralized authority, but would create the added complexity of an external solution for key management.

[0040] To date, most systems that attempt to deal with the problem of storing large objects in a blockchain rely on external storage or side databases off-chain. For example, Hyperledger Fabric has a side database that provides more storage for large objects. Some of the disadvantages of this option include the aggregate storage requirements, which are proportional to the sum of the sizes of all off-chain objects multiplied by the number of members in the network. There are also aggregate network bandwidth costs, which are a function of the size of the off-chain object multiplied by the number of members. In addition to the cost of storage, there is an additional need for each member to provide and manage off-chain storage. Furthermore, this option does not provide control over the ability of members to see the contents of off-chain objects, because all information is visible to all network members, just like the information on the ledger.

[0041] Example embodiments overcome the shortcomings of these existing systems by enabling large storage objects to be stored on the blockchain without requiring each peer to store an entire copy of the large data object. Instead, the data object is divided into slices distributed across nodes and stored on the blockchain table of each node. For example, a data object may be divided into N slices, where any k slices of the N slices can be used to reconstruct the data object (where k < N). In this example, each peer in the group can store a different slice of the data object on its ledger. By doing so, off-chain storage is not required, thus eliminating the need to manage off-chain storage. In addition, access to large data objects can be managed / controlled because a subset of peers (e.g., k of N peers) must provide their slices before the data object can be restored. Thus, even if an attacker obtains access to the ledger via a blockchain peer member, the attacker cannot view / restore the data object. Instead, in order to be able to access the data object, the attacker must obtain access to the ledgers of k blockchain peer members.

[0042] Furthermore, since peers only store corresponding slices of a data object, the full data object is not exposed to blockchain peers (member organizations), thus providing protection of the data object from visibility, even between participants of the blockchain itself. In order for any entity (member or non-member) to gain access to the entire data object, they must receive a prescribed number of slices. Furthermore, such access will be tracked via the blockchain ensuring confidentiality and privacy.

[0043] Example embodiments integrate an effective threshold scheme (ETS) for storing large objects on a blockchain, which provides the advantages of ETS for storage management along with blockchain guarantees. For example, ETS may include an algorithm that encodes an input (data object) into a configurable number of "N" parts or slices (referred to herein as slices). Here, a configurable number of at least "k" unique slices are required to determine the input, where (k <= N). The total size of the K slices is approximately equal to the size of the input. If you have fewer than K slices, it is difficult (e.g., computationally expensive or infeasible) to determine anything about the content of the input. Some examples of ETS include, but are not limited to, All-or-No Transform-Reed Solomon (AONT-RS). Another example is Secret Sharing Simplified (SSMS), which is a computationally secure secret sharing scheme.

[0044] In the examples herein, a client / peer may use the ETS algorithm to generate N slices from a data object in such a way that the data object can then be reconstructed from K slices. The client may distribute the N slices among different nodes in the network, with each node receiving a different slice. The main object in the blockchain may contain a hash of the object and a hash of all slices. In order to extract an object, a peer or client will need to receive a slice from any K nodes in the network. The endorsement policy also relies on K peers. Example embodiments provide a unique storage process for keeping large objects on the same node as the blockchain without requiring each node to store a copy of the entire object. The system uses memory efficiently without duplicating large objects, while also providing control over where slices are stored and which peer gets which data. The benefit of this system is that the aggregate network bandwidth is independent of the number of network members, because each member stores its corresponding slice rather than storing the entire data object in an off-chain storage device (via the network).

[0045] It is not possible to implement this solution in a traditional database. To implement the solution here, at least k members of the network would need to participate to provide k different storage locations. This is not possible in a traditional database (with one centralized storage location). Example embodiments solve the problem of how to store large data objects securely and cost-effectively on a blockchain in a distributed manner. In addition, instead of storing the entire object at each node, different slices are stored at each node.

[0046] Some benefits of the solution provided herein include allowing large objects to be stored within a permissioned blockchain without the need for shared data storage (offline) or the use of encryption keys, while still retaining blockchain privacy properties. By storing slices rather than entire data objects, more efficient storage and bandwidth usage is possible. In addition, large objects can be managed between different organizations with the same requirements as other blockchain objects. Full access is provided to all allowed peers with limited bandwidth and storage usage. However, each peer cannot view the object. Instead, peers must collaborate to reconstruct the data object. This prevents attackers from gaining access to the object through one peer.

[0047] Figure 1 A blockchain network 100 is shown for storing data objects 10 in slices 10a-10f according to an example embodiment. Figure 1, the client 110 uploads the data object 10 to the blockchain network 100 including a plurality of blockchain peers 121-126. In this example, the client 110 divides the data object 10 into a plurality of parts. The number of parts created may be based on the number of blockchain peers in the blockchain network 100. In particular, there are six blockchain peers (N=6). Thus, the client 110 may decompose the data object 10 into six corresponding parts. In addition, the client 110 may generate six corresponding slices 10a-10f including the six corresponding parts of the data object 10. In addition, the slices 10a-10f may include a hashing of the data object 10 and a hashing of the corresponding slices. The slices 10a-10f may be assigned to the blockchain peers 121-126.

[0048] If a peer goes down, restarts, reconnects, etc., if there are at least k active peers with slices, then the slices can be recreated. When a peer restarts or reconnects after losing communication with the network, the peer processes its lost blocks and discovers whether it has lost any slices in the data object. In the case of missing slices, it can request slices from the client 110. As another example, a peer, client 110, or another entity can use a newly defined slice retrieval (retrieve_slice) application programming interface (API) to retrieve enough slices (e.g., k slices) from other peers. Then, the records can be reconstructed, and the missing slices can be regenerated and provided to the restarting / reconnecting peer.

[0049] In addition, example embodiments modify the way storage objects 10 are endorsed by blockchain network 100. In a traditional permissioned blockchain, a subset of peers is selected (e.g., by a client) to initially endorse a transaction before it is sent to an ordering node and committed to the blockchain. In this process, each endorsing node verifies the entire transaction. In contrast, in example embodiments, each blockchain peer can endorse its corresponding slice, rather than the entire storage transaction. Figure 1 In, for example, each blockchain peer 121-126 may support its respective slice 10a-10f upon receiving its respective slice. Here, the blockchain peer 121-126 may store the slices 10a-10f while also performing simulations of the corresponding slices for endorsement purposes. The results may be provided back to the client 110. If the client receives successful endorsements from at least k blockchain peers out of the N blockchain peers 121-126, the data object 10 is successfully endorsed. In addition, the client may package these signatures together with the hash value of the data object and the hash value of the slice into a proposal, and transmit the storage proposal to an ordering node that can verify the package, and then provide the storage proposal to the blockchain peers 121-126 for storage on the blockchain.

[0050] Therefore, the endorsement process can be combined with the storage process and can also be divided into slices similar to the storage process. Therefore, even if one or more peers are unable to endorse the slice (e.g., out of state, disconnected, etc.), as long as k peers can endorse their respective slices, the data object can be successfully endorsed.

[0051] Figure 2A A blockchain architecture configuration 200 is shown according to an example embodiment. Figure 2A , the blockchain architecture 200 may include certain blockchain elements, for example, a set of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are depicted by way of example only). These nodes participate in many activities, such as blockchain transaction addition and confirmation processes (consistency). One or more of the blockchain nodes 204-210 may endorse transactions based on endorsement policies and may provide sorting services for all blockchain nodes in the architecture 200. The blockchain node may initiate a blockchain authentication and attempt to write to a blockchain immutable ledger stored in the blockchain layer 216, a copy of which may also be stored on the supporting 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 stored program / application code 220 (e.g., chain code, smart contracts, etc.), which may be created based on the customized configuration sought by the participant and may maintain its own state, control its own assets, and receive external information. This may be deployed as a transaction and installed on all blockchain nodes 204-210 via attachment to a distributed ledger.

[0052] The blockchain foundation or platform 212 may include different layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure that may be 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 provides access to the virtual execution environment necessary to process program code and participate in the physical infrastructure 214. Cryptographic trust services 218 may be used to verify transactions (such as asset exchange transactions) and keep information private.

[0053] Figure 2AThe blockchain architecture configuration of the blockchain platform 212 can process and execute program / application code 220 via one or more interfaces exposed and services provided by the blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transfer data and can be executed by the nodes 204-210 in the form of smart contracts and associated chain codes, which have conditions or other code elements that are subject to their execution. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications of changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and use of the ledger. For example, read data 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216 to create a processing result to be written to the blockchain, the processing result including write data 228. The physical infrastructure 214 can be used to retrieve any data or information described herein.

[0054] Smart contracts can be created via high-level applications and programming languages, and then written to blocks in a blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which can be executed in response to satisfying a condition associated with the smart contract. The execution of a smart contract can trigger a trusted modification to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout a distributed network of blockchain peers via one or more consensus protocols.

[0055] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of different logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by the smart contract is saved in memory by the supplied execution environment and then deleted once the data required by the blockchain is identified.

[0056] Chaincode may include a code interpretation of a smart contract with additional features. As described herein, a chaincode may be a program code deployed on a computing network, wherein the chaincode is executed and verified together by a chain validator during a shared process. The chaincode receives a hash and retrieves from the blockchain a hash value associated with a data template created by using a previously stored feature extractor. If the hash value of the hash value identifier and the hash value created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain.

[0057] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. Figure 2B , the transaction flow may include a transaction proposal 291 that includes a slice of the data object sent by the client node 260 to the endorsing peer nodes 281-283. According to various embodiments, each of the different slices may be stored by only one of the respective endorsing peer nodes 281-283. The endorsing peer nodes 281-283 may also execute / simulate the respective slice and verify the slice against the hash value of the slice and verify the client signature. The output may include a chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values ​​written in the chaincode (write set). If approved, each of the endorsing peer nodes 281-283 may send a proposal response 292 back to the client 260 along with the endorsement signature. Here, the proposal response 292 may be only for the respective slice sent to the respective endorsing peer node, rather than for the entire data object. The client 260 assembles the signatures of at least k slices (where N>k), the hash value of the data object, and the hash value of the slice into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then delivers the ordering transaction as a block to all peers 281-283 on the channel. Before submitting to the blockchain, each peer 281-283 can verify the transaction. For example, a peer can check the endorsement policy to ensure that the correct assignment of the specified peer has signed the result and verify the signature on the transaction payload 293.

[0058] Reference again Figure 2B , in 290, the client node 260 slices the data object, and in 291, sends a request with different slices to the peer nodes 281-283 as endorsers. The client 260 may include an application that utilizes a supported software development kit (SDK) that utilizes an available API to generate transaction proposals. In addition, the client 260 may include software for slicing a data object into a plurality of N slices, where any k of the N slices require rebuilding the data object. A proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger (i.e., write a new key-value pair for an asset). The SDK can act as a shim to encapsulate the transaction proposal into an appropriately architected format (e.g., protocol buffers over remote procedure calls (RPCs)) and employ the client's cryptographic certificate to generate a unique signature for the transaction proposal.

[0059] In response, in 292, the endorsing peer nodes 281-283 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, client 260) is properly authorized to perform the proposed operation on the channel. In addition, in 292, the endorsing peer nodes 281-283 may store their respective slices on the blockchain ledger and, if successfully verified, send back endorsement responses for the corresponding slices. Here, the successful verification and stored identification of the slices and the signatures of the endorsing peer nodes 281-283 are passed back to the SDK of the client 260 as the proposal response 292, and the SDK parses the payload for application consumption. This process may be repeated by at least k endorsing peer nodes so that enough endorsing peer nodes reach consensus on different slices of the data object.

[0060] In response, the client 260 application checks / validates the endorsed peer signatures and compares the proposed responses to determine if the proposed responses are identical. If the chaincode is only querying the ledger, the application will check the query response and will typically not submit the transaction to the ordering node service 284. If the client application plans to submit a transaction to the ordering node service 284 to update the ledger, the application determines if the endorsement policy specified before submission has been satisfied (i.e., at least k peers must have endorsed the slice). This architecture enables the endorsement policy to be enforced by peers and maintained during the submission verification phase even if the application chooses not to check the response or otherwise forward the unpersonalized transaction.

[0061] After a successful check, at step 293, client 260 assembles the endorsements (e.g., of at least k different slices, etc.) into a transaction and broadcasts the transaction proposal and response to ordering node 284 within a transaction message. The transaction may contain proof that the slice is stored and verified along with the endorsed peer signatures and channel IDs. The transaction proposal may also include a hash of the data object and a hash of the slice. Ordering node 284 does not need to examine the entire contents of a transaction in order to perform its operations, instead, ordering node 284 may simply receive transactions from all channels in the network, sort them chronologically by channel, and create a transaction block per channel.

[0062] The block of transactions is delivered from the ordering node 284 to all peer nodes 281-283 on the channel. Transactions 294 within the block are validated to ensure that any endorsement policies are satisfied and that the state of the ledger for the read set variables has not changed because the read set was generated by the transaction execution. The transactions in the block are marked as valid or invalid. In addition, at step 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events are emitted to notify the client application that the transaction (call) has been immutably appended to the chain, and whether the transaction is validated or invalidated.

[0063] Figure 3A An example of a permissioned blockchain network 300 featuring a distributed, decentralized peer-to-peer architecture is shown. In this example, a blockchain user 302 can initiate a transaction to a permissioned blockchain 304. In this example, a transaction can be a deployment, call, or query, and can be issued through a client-side application utilizing an SDK, directly through an API, etc. The network can provide access to regulators 306 such as auditors. The blockchain network operator 308 manages member permissions, such as registering regulators 306 as "auditors" and blockchain users 302 as "clients." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, call, and query certain types of chaincodes.

[0064] Blockchain developers 310 can write chaincodes and client-side applications. Blockchain developers 310 can deploy chaincodes directly to the network through an interface. In order to include certificates from traditional data sources 312 in the chaincode, developers 310 can use out-of-band connections to access the data. In this example, blockchain users 302 connect to the licensed blockchain 304 through peer nodes 314. Before conducting any transactions, peer nodes 314 retrieve the user's registration and transaction certificates from the certificate authority 316 that manages user roles and permissions. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the licensed blockchain 304. At the same time, users attempting to utilize chaincodes may be required to verify their credentials on traditional data sources 312. In order to confirm the user's authorization, the chaincode can use an out-of-band connection to the data through a traditional processing platform 318.

[0065] Figure 3BAnother example of a permissioned blockchain network 320 featuring a distributed, decentralized peer-to-peer architecture is shown. In this example, a blockchain user 322 can submit a transaction to a permissioned blockchain 324. In this example, a transaction can be a deployment, call, or query, and can be issued through a client-side application utilizing an SDK, directly through an API, etc. The network can provide access to regulators 326 such as auditors. The blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and blockchain users 322 as "clients." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, call, and query certain types of chaincodes.

[0066] Blockchain developers 330 write chaincodes and client-side applications. Blockchain developers 330 can deploy chaincodes directly to the network through an interface. In order to include credentials from traditional data sources 332 in the chaincode, developers 330 can use out-of-band connections to access the data. In this example, blockchain users 322 connect to the network through peer nodes 334. Before conducting any transactions, peer nodes 334 retrieve the user's registration and transaction certificates from certificate authorities 336. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain 324. At the same time, users attempting to utilize chaincodes may be required to verify their credentials on traditional data sources 332. To confirm the user's authorization, the chaincode can use an out-of-band connection to the data through a traditional processing platform 338.

[0067] In some embodiments, the blockchain herein may be an unlicensed blockchain. In contrast to a licensed blockchain that requires permission to join, anyone can join an unlicensed blockchain. For example, to join an unlicensed blockchain, a user may create a personal address and begin interacting with the network by submitting transactions and thereby adding entries to the ledger. In addition, all parties have the option of running a node on the system and employing a mining protocol to help verify transactions.

[0068] Figure 3CThe processing 350 of a transaction processed by an unlicensed blockchain 352 including a plurality of nodes 354 is shown. A sender 356 wishes to send a payment or some other form of value (e.g., a deed, medical record, contract, good, service, or any other asset that may be encapsulated in a digital record) to a receiver 358 via the unlicensed blockchain 352. In one embodiment, each of the sender device 356 and the receiver device 358 may have a digital wallet (associated with the blockchain 352) that provides user interface controls and a display of transaction parameters. In response, the transaction is broadcasted 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 unlicensed blockchain 352 (which may be predefined or dynamically assigned). For example, this may include verifying the identities of the parties involved, etc. The transaction may be verified immediately, or it may be placed in a queue with other transactions, and the nodes 354 determine whether the transaction is valid based on the network rule set.

[0069] In structure 362, valid transactions are formed into blocks and sealed with locks (hash values). This process can be performed by a node in mining node 354. The mining node can utilize additional software that is specifically used to mine and create blocks for the unlicensed blockchain 352. Each block can be identified by a hash value (e.g., a 256-bit number, etc.) created using an algorithm agreed upon by the network. Each block can include a header, a pointer or reference to the hash value of the header of the previous block in the chain, and a set of valid transactions. The reference to the hash value of the previous block is associated with the creation of a secure independent chain of blocks.

[0070] Before a block can be added to the blockchain, the block must be validated. Validation of the permissionless blockchain 352 may include proof of work (PoW), which is the solution to a puzzle derived from the header of the block. Figure 3C Not shown in the example, but another process for validating blocks is Proof of Stake. Unlike Proof of Work, where the algorithm rewards miners for solving mathematical problems with Proof of Stake, the creator of a new block is chosen in a deterministic way, depending on their wealth, also defined as “stake”. Similar proofs are then performed by the chosen / selected nodes.

[0071] With mining 364, nodes attempt to solve a block by incrementally changing a variable until the solution satisfies the network-wide goal. This generates a PoW, thereby ensuring the correct answer. In other words, a potential solution must prove to exhaust computing resources in solving the problem. In some types of permissionless blockchains, miners can be rewarded with value (e.g., coins, etc.) for correctly mining a block.

[0072] Here, the PoW process makes the modification of the blockchain extremely difficult beside the linking of the blocks, because the attacker must modify all subsequent blocks in order to accept the modification of one block. In addition, as new blocks are mined, the difficulty of modifying the block increases, and the number of subsequent blocks increases. Through distribution 366, the successfully verified block is distributed through the unlicensed group chain 352, and all nodes 354 add the block to the majority chain which is an auditable ledger of the unlicensed group chain 352. In addition, the value in the transaction submitted by the sender 356 is deposited or otherwise transmitted to the digital wallet of the recipient device 358.

[0073] Figure 4A 4 shows a process 400A for converting a data object into a slice according to an example embodiment. Here, the process 400A may be performed by a client node or the like. Figure 4A , the data object to be stored on the blockchain is encrypted to create an encrypted data object 410. The encrypted data object 410 may be divided into slices 420. In addition to the data object, the client may also add additional data 412 to provide resilience to loss. Here, the additional data may create additional slices 420. The additional data 412 enables overlap between slices and redundancy in the event that one or more slices are subsequently lost or damaged. In some embodiments, m slices are created by dividing the object into m equal-sized parts, and an additional k slices are provided for resilience against loss of slices (such as due to a failure or due to a malicious member of the network), and N=m+k.

[0074] Each slice 420 may include both common content and unique content. Figure 4A In the example of , the content of slice 3 is shown. Here, the common content includes a hash value of the data object 422, which can be used to subsequently verify the reconstructed data object. The unique content includes a hash value of the corresponding slice 424 and encrypted slice content 426 (e.g., a corresponding portion of the encrypted data object 410).

[0075] Therefore, the effective threshold scheme (ETS) can be integrated with the blockchain. Here, the system can generate N slices from the data object, where each slice has its hash value and the hash value for the entire object. The blockchain peer can store the slices during the endorsement process, and the slices can be verified against the hash value during the endorsement process. This ensures that only transactions with k+c <= n slices are endorsed. The data object and the slices can be encrypted with a random key, which can be provided via secret sharing along with the slices. Thus, in order to reconstruct the data object, k live peers may be required to extract their respective slices. Otherwise, the key will not be able to decrypt the encrypted data.

[0076] In this example, blockchain peers (members) are uniquely numbered from 1 to N, where N is the number of peers that are members of the network. When proposing a new entry with a large data object to the ledger, the client (proposer) may apply ETS to the data object and produce N slices, where any k slices (e.g., a specified number of slices, etc.) may be required to reconstruct the data object. In addition, for each slice, the enhancer will generate an integrity check value (ICV) for the slice. Figure 4A In the example of , the ICV is a hash value of data object 422 and a hash value of slice 424. It should also be understood that the ICV can be any type of data item that can be tested to be consistent with any data slice and confirms with a high degree of certainty that the ICV is consistent with the associated data slice for which the ICV is calculated. Other examples of ICVs include message authentication codes, checksums, hash values ​​(digests), digital signatures, cyclic redundancy checks, etc.

[0077] According to various embodiments, each proposed slice may contain 1) the ICV of the entire data object and 2) the ICV of the corresponding slice of the N slices, in addition to any information the proposer wants to include in the slice. Each member will receive a proposed entry (data portion and hash value) corresponding to the member's index. Adding entries to the chain works like any other blockchain. During the endorsement process, the node will store its slice and verify that the ICV in the blockchain transaction is consistent with the received slice, and then it will endorse this transaction.

[0078] In addition to the above changes for adding entries to the chain, the system may also require blockchain peers to implement a new API for retrieving slices of data from each other. This API takes an identifier for an object (or a slice of an object) and, if authorized, returns the corresponding slice stored by the network member for that object. The system may implement this API and retrieval outside the blockchain. As another example, the system may add a transaction to the ledger that requires the entire record to be provided to members, which would create a tracking mechanism for all members that have retrieved the record. With this extension, slices are provided to members only after the transaction is added to the blockchain.

[0079] In addition, the encryption key used to encrypt the data object may also be divided into partial keys (e.g., by the client), which are then distributed among the blockchain peers. In this case, each peer may have access to only a partial key and not the entire encryption key. Then, during the reconstruction process, the peer may provide its portion of the encryption key. If a sufficient portion of the encryption key is recovered, the data object can be decrypted.

[0080] Figure 4B A process 400B of reconstructing a data object from a slice and verifying the data object according to an example embodiment is shown. Figure 4B, four slices are available. In other words, the blockchain peers storing slices 2 and 5 are unavailable, making only slices 1, 3, 4, and 6 available. In this example, four of the six meet the required minimum (e.g., k=4). Therefore, blockchain peer 430 can use the newly defined retrieve slice API to retrieve four slices from the corresponding peers holding such slices. In addition, peer 430 can reconstruct the data object from the four slices (slices 1, 3, 4, and 6) to generate a reconstructed data object 432.

[0081] Peer 430 may also retrieve a previously stored hash value of a data object from any of the blockchain peers holding slices 1, 3, 4, and 6. In this example, peer 430 may generate a corresponding hash value of reconstructed data object 432 using a shared hash function to generate hashed data object 434. In addition, peer 430 may verify that the value of hashed data object 434 is the same as the hash value of the retrieved data object. If so, peer 430 knows that reconstructed data object 432 is valid. If not, the peer may ignore and attempt to retrieve the data object when other slices / peers exist.

[0082] Figure 5 A method 500 of storing slices of a data object on a blockchain according to an exemplary embodiment is shown. Figure 5 In 510, the method may include dividing the data object into a plurality of parts. The parts may be smaller objects (e.g., sub-objects) of the original data object. Examples of data objects include audio files, documents, videos, images, etc. In some embodiments, the smaller parts may each have the same size or different sizes. In some embodiments, the partitioning may include decomposing the data object into N parts corresponding to N blockchain peers, wherein any k of the N parts may be used to perform reconstruction of the data object, and k is less than N. In some embodiments, the partitioning may include adding k additional parts of data for loss recovery to generate N parts. For example, m parts may be generated based on the data object, and k parts may be added for loss resistance. In this example, m+k may be equal to N.

[0083] At 520, the method may include hashing the data object to generate a hashed data object and hashing the plurality of portions to generate a plurality of hashed portions. Here, the hashed data object may represent a verification value that can be used to subsequently verify the reconstructed data object. At 530, the method may include generating a plurality of slices, wherein each slice includes the hashed data object and a different corresponding hashed portion. Furthermore, at 540, the method may include distributing the plurality of slices across a plurality of blockchain peers.

[0084] In some embodiments, the distribution may include: assigning an index between 1 and N to the N blockchain peers respectively; and assigning N slices to the N peers based on the assigned indexes. In some embodiments, the method may include encrypting the multiple slices using an encryption key shared among the multiple blockchain peers. In this example, as with the data object, the encryption key may be decomposed into partial keys (key parts) and distributed so that each peer can access a portion of the key but not all of the key. In some embodiments, in response to a request for the data object, the method also includes retrieving a subset of slices from a subset of blockchain peers, and reconstructing the data object from the hashed portion contained in the subset of slices.

[0085] In some embodiments, the method may further include verifying the reconstructed data object based on a hashed data object stored in one of the retrieved slices. Here, the hashed data object may be extracted from any of the retrieved slices. The verification may include, for example, generating a hash value of the reconstructed data object and comparing it to the hashed data object to ensure that they are the same. If not, the reconstructed data object is faulty. In some embodiments, the retrieval of the slice subset is performed via a slice retrieval application programming interface (API) running on a subset of blockchain peers.

[0086] Fig. 6A An exemplary system 600 is shown including a physical infrastructure 610 configured to perform various operations according to an example embodiment. 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 reside on the blockchain 620), and the smart contract 630 may perform any operation step 608 (in the module 612) included in any example embodiment. The step / operation 608 may include one or more of the described or depicted embodiments, and may represent output or written information written or read from one or more smart contracts 630 and / or blockchain 620. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, the module 612 and the module 614 may be the same module.

[0087] Figure 6B Another example system 640 is shown that is configured to perform various operations according to an example embodiment. Figure 6B, system 640 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which may reside on blockchain 620), and smart contract 630 may perform any operation step 608 (in module 612) included in any example embodiment. Step / operation 608 may include one or more of the described or depicted embodiments, and may represent output or written information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, module 612 and module 614 may be the same module.

[0088] Figure 6C An example system configured to utilize a smart contract configuration between contracting parties and a mediation server configured to enforce the terms of the smart contract on a blockchain are shown according to example embodiments. Figure 6C , configuration 650 may represent a communication session, asset transfer session, or process or journey driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract execution may be managed by a server 654. The content of the smart contract 630 may require digital signatures of one or more of the entities 652 and 656 that are parties to the smart contract transaction. The results of the smart contract execution may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0089] Fig.6D A system 660 including a blockchain according to an exemplary embodiment is shown. Fig.6D In the example of , the application programming interface (API) gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 662 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the server 654 is a blockchain network peer component that maintains a copy of the world state and the distributed ledger, allowing clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where the endorsing peers will run the smart contract 630 according to the smart contract 630 and the endorsement policy.

[0090] The above embodiments can be implemented in hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program can be implemented on a computer-readable medium, such as a storage medium. For example, the computer program can reside 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 art.

[0091] An example storage medium may be coupled to the processor such that the processor can read information from and write information to the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components.

[0092] Fig. 7A shows a process 700 of adding a new block to a distributed ledger 720 according to an example embodiment, Figure 7B The contents of a new data block structure 730 for a blockchain are shown according to an example embodiment. Fig. 7A , a client (not shown) may submit a transaction to blockchain nodes 711, 712, and / or 713. A client may be an instruction received from any source to enact an activity on blockchain 720. As an example, a client may be an application acting on behalf of a requester (such as a device, person, or entity) to propose a transaction for a blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain the state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes / peers may exist in the blockchain network, including peers that endorse simulated and endorsed transactions proposed by clients and peers that submit verified endorsements, verified transactions, and submitted transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may perform the role of an endorsement node, a submission node, or both.

[0093] The distributed ledger 720 includes a blockchain that stores immutable ordered records in blocks and a state database 724 (current world state) that maintains the current state of the blockchain 722. A distributed ledger 720 may exist for each channel, and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions. Blocks may include transactions such as Figure 7B The various components shown in the . Block links (by Fig. 7A) can be generated by adding a hash of the header of the previous block within the block header of the current block. In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together, thereby preventing tampering with the blockchain data without breaking the hashed links. In addition, due to the linking, the latest block in the blockchain 722 represents every transaction that came before it. The blockchain 722 can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0094] The current state of the blockchain 722 and distributed ledger 722 may be stored in a state database 724. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 722. Chain calls execute transactions against the current state in the state database 724. In order to make these chaincode interactions extremely efficient, the latest values ​​of all keys are stored in the state database 724. The state database 724 may include an indexed view of the transaction log that entered the blockchain 722, so it can be regenerated from the chain at any time. The state database 724 may be automatically restored (or generated if necessary) at peer startup before a transaction is accepted.

[0095] The endorsing node receives the transaction from the client and endorses the transaction based on the simulation results. The endorsing node holds the smart contract proposed by the simulated transaction. When the endorsing node endorses the transaction, the endorsing node creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing the transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing colleagues must endorse the transaction". Different channels can have different endorsement policies. The client application forwards the verified transaction to the sorting service 710.

[0096] The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers the blocks to committing peers. For example, the ordering service 710 may initiate a new block when a transaction threshold has been reached, a timer has expired, or another condition. Fig. 7A In the example of , blockchain node 712 is a submitting peer that has received new data new data block 730 for storage on blockchain 720. The first block in the blockchain can be called a generation block, which includes information about the blockchain, its members, the data stored therein, etc.

[0097] The sorting service 710 may be composed of a cluster of sorters. The sorting service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the sorting service 710 may accept endorsed transactions and specify the order in which those transactions are submitted to the distributed ledger 720. The architecture of the blockchain network may be designed so that the specific implementation of 'sorting' (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0098] Transactions are written to the distributed ledger 720 in a consistent order. The order of transactions is established to ensure that updates to the state database 724 are valid when they are submitted to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcont, etc.) where ordering occurs by solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 720 can choose the ordering mechanism that best suits the network.

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

[0100] refer to Figure 7B , a new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be understood that blocks and their contents, such as the new data block 730 and its contents, are depicted differently. Figure 7B The examples shown in FIG. 7 are merely examples and are not meant to limit the scope of the example embodiments. New data block 730 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 750. New data block 730 may also include a block header 740 containing information about a previous block (e.g., Fig. 7AIn particular, the block header 740 may include a hash of the header of the previous block. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block number of the new data block 730 may be unique and assigned in a different order, such as an increasing / sequential order starting from zero.

[0101] The block data 750 may store transaction information for each transaction recorded within the new data block 730. For example, the transaction data may include one or more of the transaction's type, version, timestamp, channel ID of the distributed ledger 720, transaction ID, period, payload visibility, chaincode path (deploy TX (transaction)), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identity (such as public key and certificate), client's signature, endorser's identity, endorser signature, proposal hashing, chaincode event, response status, namespace, read set (list of keys and versions read by the transaction, etc.), write set (list of keys and values, etc.), start key, end key, key list, Merkel tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0102] According to various embodiments, the block data 750 may also store slice data 752 including a slice of data from a plurality of slices of a data object. The slice data 752 may include a portion of the original data object, a hash value of the data object, a hash value of the slice, etc. The slice data 752 includes one or more of the steps, features, processes, and / or actions described or depicted herein. Thus, the slice data 752 may be stored in an immutable log of a block on the distributed ledger 720 of the blockchain 722. Some benefits of storing the slice data 752 on the blockchain are reflected in various embodiments disclosed and depicted herein. Although in Figure 7B , the slice data 752 is depicted in the chunk data 750 , but the slice data 752 may also be located in the chunk header 740 or the chunk metadata 760 .

[0103] The block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature regarding block creation, a reference to the last configured block, a transaction filter identifying valid and invalid transactions within the block, a last offset retained by the sorting service that sorts the block, and the like. The signature, last configured block, and sorter metadata may be added by the sorting service 710. At the same time, the submitter of the block (such as the blockchain node 712) may add valid / invalid information based on endorsement policies, verification of read / write sets, and the like. The transaction filter may include a byte array of size equal to the number of transactions in the block data 750 and a verification code identifying whether the transaction is valid / invalid. In some embodiments, although in Figure 7BNot shown, but block metadata 760 may store therein metadata of the recommended smart contract.

[0104] Figure 7C An embodiment of a blockchain 770 for digital content is shown in accordance with embodiments described herein. The digital content may include one or more files and associated information. The files may contain media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspect of the blockchain acts as a safeguard to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where admissibility rules apply, or in other settings where evidence is considered or where the presentation and use of digital information is otherwise of interest. In such cases, the digital content may be referred to as digital evidence.

[0105] The blockchain can be formed in a variety of ways. In one embodiment, the digital content can be included in and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing the previous block. This can be illustrated as follows:

[0106] Block 1 Block 2 Block N

[0107] Hash value 1 Hash value 2 Hash value N

[0108] Digital content 1 Digital content 2 Digital content N

[0109] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of the content of each block without any digital content. The digital content may be stored in another storage area or memory address associated with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or may be a different storage area or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest, and then looking up the value stored in the storage area corresponding to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows:

[0110] Blockchain Storage Area

[0111] Block 1 hash value Block 1 hash value… Contents . . . . . .

[0115] Block N hash value Block N hash value… Contents

[0116] exist Figure 7C In an exemplary embodiment of the present invention, the blockchain 770 includes a plurality of blocks 7781, 7782, ..., 7783 that are cryptographically linked in an ordered sequence. N , where N ≥ 1. Used to link blocks 7781, 7782, ..., 778 N The encryption of can be any of a number of keyed or non-keyed hash value functions. In one embodiment, blocks 7781, 7782, ..., 778 N Subjected to a hash value function that produces an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, nonce-based algorithms, and collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778 N The link may be encrypted by a function other than a hashing function.For purposes of illustration, the following description is made with reference to a hash function (eg, SHA-2).

[0117] Blocks 7781, 7782, ..., 778 in the blockchain N Each of the blocks includes a header, a version of the file, and a value. Due to hashing in the blockchain, the header and value are different for each block. In one embodiment, the value may be included in the header. As described in more detail below, the version of the file may be the original file or a different version of the original file.

[0118] The first block 7781 in the blockchain is called the genesis block and includes a header 7721, a raw file 7741, and an initial value 7761. The hashing scheme used for the genesis block and in fact in all subsequent blocks can vary. For example, all of the information in the first block 7781 can be hashed together and at once, or each or a portion of the information in the first block 7781 can be hashed separately, and then hashing of the separately hashed portions can be performed.

[0119] The header 7721 may include one or more initial parameters, which may include, for example, a version number, a timestamp, a random number, root information, a difficulty level, a consensus protocol, a duration, a media format, a source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be generated automatically (e.g., by blockchain network management software) or manually by a blockchain participant. N Unlike the header in , header 7721 in the genesis block does not reference a previous block simply because no previous block exists.

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

[0121] The value 7761 in the gene 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 a hash value of the original file 7741, metadata of the original file 7741, and other information associated with the file. In one embodiment, the initial value 7761 may be based on the following unique attributes:

[0122] 1) The hash value calculated by HA-2 of the original file

[0123] 2) Originating device identification

[0124] 3) The start timestamp of the original file

[0125] 4) The original storage location of the original file

[0126] 5) The blockchain network member ID for the software currently controlling the original file and associated metadata

[0127] Other blocks in the blockchain are 7782 to 778 N It also has a header, a file, and a value. However, unlike the first block 7721, the headers 7722 to 772 NEach of the Nth blocks includes a hashed value of the immediately preceding block. The hash value of the previous block may be only a hash of the header of the previous block or may be a hash value of the entire previous block. By including the hashed value of the previous block in each of the remaining blocks, tracking from the Nth block back to the origin block (and associated original file) may be performed on a block-by-block basis, as indicated by arrow 780, to establish an auditable and immutable chain of custody.

[0128] Headers 7722 to 772 in other blocks N Each of may also include other information, such as a version number, a timestamp, a random number, root information, a difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or blockchain.

[0129] Files 7742 to 774 in other blocks N The original file may be equal to the original file or may be a modified version of the original file in the origin block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. The processing may involve, for example, any modification of the files in the previous block, such as editing information or otherwise changing the contents of the files, taking information away from these files, or adding or appending information to these files.

[0130] Additionally or alternatively, processing may involve merely copying a file from a previous block, changing a storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing an action with respect to the file and / or its associated metadata on the blockchain. Processing involving analyzing a file may include, for example, appending, including, or otherwise associating various analytics, statistics, or other information associated with the file.

[0131] Other blocks in other blocks 7762 to 776 N The value in each of the blocks is a unique value and is different as a result of the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hashing of the block being assigned. The value of the block thus provides an indication of what processing was performed in the block and also allows a trace back to the original file through the blockchain. The trace confirms the blockchain of the file throughout the blockchain.

[0132] For example, consider a situation where portions of a file in a previous block are edited, blocked, or pixelated in order to protect the identity of the person shown in the file. In this case, the block that includes the edited file will include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp when the edit occurred, etc. The metadata can be hashed to form a value. Because the metadata of the block is different from the information that was hashed to form a value in the previous block, the values ​​are different from each other and can be recovered upon decryption.

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

[0134] a) If the file has been manipulated in any way (for example, if the file was edited, copied, changed, accessed, or some other action taken), then the new SHA-2 calculated hash value

[0135] b) New storage location for the file

[0136] c) new metadata associated with the file identified

[0137] d) Transferring access to or control over a file from one blockchain participant to another

[0138] Fig.7D FIG. 7 shows an example of a block structure that can represent a block in a blockchain 790 according to one embodiment. The block Blocki includes a header 772 i 、File 774 i The sum is 776 i .

[0139] Header 772 i Including previous block Block i-1 The hash value of the previous block and additional reference information, such as any type of information discussed herein (e.g., header information including references, characteristics, parameters, etc.). All blocks refer to the hash of the previous block, except for the generation block. The hash value of the previous block can be only the hash of the header in the previous block or the hash of all or part of the information in the previous block (including files and metadata).

[0140] File 774 i The system includes a plurality of data, such as data 1, data 2, ..., data N in order. Metadata 1, metadata 2, ..., metadata N are used to describe the content and / or characteristics associated with the data. NTagging the data. For example, the metadata for each data may include a timestamp indicating the data, processing data, keywords indicating the person or other content depicted in the data, and / or other information that can help establish the validity and content of the file as a whole, and in particular its use of digital evidence, for example, as described in conjunction with the embodiments discussed below. In addition to the metadata, each data may be tagged with references to previous data REF1, REF2, ..., REF N To prevent tampering, gaps in the file, and sequential references through the file.

[0141] Once metadata is assigned to data (e.g., by a smart contract), the metadata cannot be altered without a hash value change, which can be easily identified for invalidation. Thus, metadata creates a data record of information that can be accessed for use by participants in the blockchain.

[0142] Value 776 i is a hash value or other value calculated based on any of the types of information discussed previously. For example, for any given block i , the value of the block may be updated to reflect the processing performed for the block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other action or information to be added. Although the value in each block is shown as being separate from the metadata and header of the file's data, in another embodiment, the value may be based in part or in whole on the metadata.

[0143] Once the blockchain 770 is formed, at any point in time, an immutable chain of custody for a file can be obtained by querying the blockchain to obtain the transaction history of values ​​across blocks. The query or tracking process can begin by decrypting the value of the most currently included block (e.g., the last (Nth) block), and then continue to decrypt the values ​​of other blocks until the generation block is reached and the original file is recovered. Decryption can also include decrypting the header and file and associated metadata at each block.

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

[0145] Generating a key pair can be similar to creating an account on the blockchain, but without actually having to register it anywhere. In addition, each transaction performed on the blockchain is digitally signed by the sender using his private key. This signature ensures that only the owner of the account can track and process (if within the scope of permission determined by the smart contract) the files on the blockchain.

[0146] Fig. 8A and Figure 8B Additional examples of use cases in which blockchains may be incorporated and used herein are shown. Specifically, Fig. 8A An example 800 of a blockchain 810 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models in order to make accurate predictions about new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to mine non-intuitive patterns.

[0147] exist Fig. 8A In the example of , host platform 820 builds and deploys a machine learning model for predictive monitoring of asset 830. Here, host platform 820 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. Asset 830 may be any type of asset (e.g., a machine or equipment, etc.), such as an airplane, a locomotive, a turbine, a medical machine and equipment, an oil and gas equipment, a ship, a boat, a vehicle, etc. As another example, asset 830 may be a non-tangible asset, such as a stock, a currency, a digital coin, an insurance, etc.

[0148] 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 data scientists / engineers or other users to collect data, historical data can be stored on blockchain 810 by the asset 830 itself (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be directly and reliably transmitted directly from its starting location to blockchain 810. By using blockchain 810 to ensure the security and ownership of the collected data, smart contracts can directly send data from assets to individuals who use the data to build machine learning models. This allows data to be shared between assets 830.

[0149] The collected data can be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (allows nodes) to ensure that the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Therefore, it is auditable, transparent, and secure. In some cases (i.e., supply chain, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of the data being recorded.

[0150] In addition, training of the machine learning model on the collected data may take the form of rounds of refinement and testing by the host platform 820. Each round may be based on additional data or data that was not previously considered to help expand the knowledge of the machine learning model. In 802, the different training and testing steps (and the data associated therewith) may be stored on the blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) may be stored on the blockchain 810. This provides verifiable proof of how the model was trained and what data was used to train the model. In addition, when the host platform 820 has implemented the final trained model, the resulting model may be stored on the blockchain 810.

[0151] After the model has been trained, it can be deployed to a field environment where it can make predictions / decisions based on the execution of the final trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, healthcare machines, etc. In this example, data fed back from asset 830 can be input into the machine learning model and used to make event predictions, such as failure events, error codes, etc. Decisions made by executing the machine learning model at the host platform 820 can be stored on the blockchain 810 to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict a future crash / failure of a portion of the asset 830 and create an alert or notification to replace the portion. The data behind this decision can be stored on the blockchain 810 by the host platform 820. In one embodiment, the features and / or actions described and / or depicted herein can occur on or with respect to the blockchain 810.

[0152] New transactions to a blockchain can be grouped together into a new block and added to an existing hash. This is then encrypted to create a new hash of the new block. As a transaction is encrypted, it is added to the next transaction list, and so on. The result is a blockchain of blocks that each contain the hashes of all previous blocks. The computers storing these blocks periodically compare their hashes to ensure they all agree. Any computer that disagrees discards the record that caused the problem. This method is good for ensuring the tamper-resistance of the block chain, but it is not perfect.

[0153] One way to game the system is for a dishonest user to change the transaction list to their preference, but in a way that keeps the hashing unchanged. This can be done by brute force, in other words, by changing the record, encrypting the result, and seeing if the hashed value is the same. And if not, it tries again and again until it finds a matching hashing. The security of the blockchain is based on the belief that ordinary computers can only perform such brute force attacks on completely unrealistic time scales (such as the age of the universe). In contrast, quantum computers are much faster (1000s of times faster) and therefore pose a much greater threat.

[0154] Figure 8B An example 850 of a quantum-safe module blockchain 852 that implements quantum key distribution (QKD) to prevent quantum computing attacks is shown. In this example, blockchain users can use QKD to verify each other's identities. This uses quantum particles such as photons to send information that cannot be copied by an eavesdropper without destroying the photons. In this way, the sender and receiver can determine each other's identity through the blockchain.

[0155] exist Figure 8B In the example of , there are four users 854, 856, 858, and 860. Each pair of users can share a secret key 862 (i.e., QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, so six different secret keys 862 are used, including QKDAB, QKDAC, QKDAD, QKDBC, QKDBD, and QKDCD. Each pair can create a QKD by sending information using quantum particles (such as photons), which cannot be copied by an eavesdropper without destroying them. In this way, a pair of users can determine each other's identity.

[0156] The operation of blockchain 852 is based on the following two processes: (i) the creation of transactions, and (ii) the construction of blocks that aggregate new transactions. New transactions can be created similar to traditional blockchain networks. Each transaction can contain information about the sender, the receiver, the creation time, the amount (or value) to be transferred, a list of reference transactions that prove that the sender has funds for the operation, etc. The transaction record is then sent to all other nodes, where it is entered into the unconfirmed transaction pool. Here, two parties (i.e., a pair of users in 854-860) authenticate the transaction by providing their shared key 862 (QKD). The quantum signature can be attached to each transaction, making it very difficult to tamper with. Each node checks their entries relative to the local copy of blockchain 852 to verify that each transaction has sufficient funds. However, the transaction has not yet been confirmed.

[0157] Blocks can be created in a decentralized manner using a broadcast protocol, rather than performing a traditional mining process on blocks. In a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transactions, thereby achieving a Byzantine agreement (consensus) on the correct version of the transaction. For example, each node can have a private value (the transaction data of that particular node). In the first round, the nodes transmit their private values ​​to each other. In subsequent rounds, the nodes transmit the information they received from other nodes in the previous round. Here, honest nodes are able to create a complete set of transactions within a new block. This new block can be added to blockchain 852. In one embodiment, the features and / or actions described and / or depicted herein may occur on or relative to blocking chain 852.

[0158] Fig. 9 An exemplary system 900 is shown that supports one or more exemplary embodiments described and / or depicted herein. The system 900 includes a computer system / server 902, which can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the computer system / server 902 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, etc.

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

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

[0161] Bus refers to any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0162] The computer system / server 902 generally includes various computer system readable media. Such media can be any available media that can be accessed by the computer system / server 902, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 906 implements the flow charts of other figures. The system memory 906 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache memory 912. The computer system / server 902 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 914 may be provided for reading and writing from a non-removable non-volatile magnetic medium (not shown, and generally referred to as a "hard drive"). Although not shown, a disk drive for reading from or writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical drive for reading from or writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media) may be provided. In such a case, each may be connected to the bus via one or more data medium interfaces. As will also be depicted and described below, memory 906 may include at least one program product having a set (eg, at least one) of program modules configured to perform the functions of different embodiments of the application.

[0163] A program / utility 916 having a set (at least one) of program modules 918, as well as an operating system, one or more application programs, other program modules, and program data, may be stored in memory 906 by way of example and not limitation. Each or some combination of the operating system, one or more application programs, other program modules, and program data may include an implementation of a network environment. Program modules 918 generally perform the functions and / or methods of different embodiments of the application as described herein.

[0164] As will be appreciated by those skilled in the art, aspects of the present application may be embodied as systems, methods, or computer program products. Therefore, aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may be collectively referred to herein as a "circuit," "module," or "system." In addition, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having a computer-readable program code embodied thereon.

[0165] The computer system / server 902 may also communicate with one or more external devices 920 (e.g., keyboard, pointing device, display 922, etc.); and / or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication may occur via I / O interface 924. In addition, the computer system / server 902 may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter 926. As depicted, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction 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 archival storage systems, etc.

[0166] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media have been shown in the accompanying drawings and described in the foregoing detailed description, it will be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as set forth and defined by the following claims. For example, the capabilities of the systems of the different drawings may be performed by one or more modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver, or both. For example, all or part of the functions performed by a separate module may be performed by one or more of these modules. Also, the functions described herein may be performed at different times and on different events inside or outside a module or component. In addition, the information sent between the modules may be sent between the modules via a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or via at least one of a plurality of protocols. Moreover, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

[0167] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, server, console, personal digital assistant (PDA), cellular telephone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide an example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in local and distributed forms consistent with computing technology.

[0168] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically emphasize their implementation independence. For example, modules can be implemented as hardware circuits that include custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices (such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.).

[0169] Modules may also be implemented at least in part in software for execution by different types of processors. The identified executable code units may, for example, include one or more physical or logical blocks of computer instructions that may, for example, be organized as objects, procedures, or functions. However, the executable files of the identified modules need not be physically located together, but may include different instructions stored in different locations that, when logically joined together, comprise the module and achieve the stated purpose of the module. Also, the module may be stored on a computer-readable medium, which may be, for example, a hard drive, a flash device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

[0170] In practice, a module of executable code may be a single instruction or many instructions, and may even be distributed over several different code segments, between different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within a module, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations, including on different storage devices, and may exist, at least in part, simply as electronic signals on a system or network.

[0171] It will be readily understood that the components of the present application, as generally described and illustrated in the drawings herein, may be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application.

[0172] Those skilled in the art will readily appreciate that the above content may be practiced with steps in a different order and / or with hardware elements in a configuration different from that disclosed. Therefore, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent.

[0173] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and that the scope of the present application will be limited solely by the appended claims when considering the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A device comprising: a processor configured to divide the data object into a plurality of parts, hashing the data object to generate a hashed data object, and hashing the plurality of portions to generate a plurality of hashed portions, generating a plurality of slices, wherein each slice comprises a copy of the hashed data object and a different corresponding hashed portion from the plurality of hashed portions; as well as A network interface configured to distribute a plurality of blockchain transactions having the plurality of slices to a plurality of blockchain peers, respectively, wherein each blockchain peer receives blockchain transactions having a different slice; The processor is further configured to, in response to a request for the data object, retrieve a subset of slices from a subset of the blockchain peers, generate a corresponding hash value of a reconstructed data object from the hashed portions included in the subset of slices to obtain a hashed reconstructed data object, and verify the reconstructed data object based on a copy of the hashed data object stored in one of the retrieved slices and the hashed reconstructed data object, and in response to the reconstructed data object being invalid, retrieve slices from other blockchain peers among the plurality of blockchain peers, if any, for reconstructing the data object.

2. The apparatus of claim 1 , wherein the processor partitions the data object into N parts corresponding to N blockchain peers, wherein any k of the N parts are capable of reconstructing the data object, and k is less than N.

3. The apparatus according to claim 2, wherein the processor is further configured to: assign indexes between 1 and N to the N blockchain peers, respectively, and control the network interface to distribute the N slices to the N blockchain peers based on the assigned indexes. 4 . The apparatus of claim 2 , wherein the processor is configured to partition the data object into m equal-sized portions and to add k additional portions of data for loss resistance to generate the N portions.

5. The apparatus of claim 1 , wherein the processor is further configured to encrypt the plurality of slices using an encryption key, wherein each of the blockchain peers maintains only an incomplete portion of the encryption key such that no single blockchain peer stores the encryption key in its entirety.

6. The apparatus of claim 1 , wherein the processor is configured to retrieve a subset of the slices via a slice retrieval application programming interface (API) running on a subset of the blockchain peers.

7. A method comprising: Divide the data object into multiple parts; hashing the data object to generate a hashed data object, and hashing the plurality of portions to generate a plurality of hashed portions; generating a plurality of slices, wherein each slice comprises a copy of the hashed data object and a different corresponding hashed portion from the plurality of hashed portions; as well as Distributing the plurality of blockchain transactions having the plurality of slices to the plurality of blockchain peers, respectively, wherein each blockchain peer receives the blockchain transactions having a different slice, The method further comprises: Retrieving a subset of the slices from a subset of the blockchain peers in response to a request for the data object; generating a corresponding hash value of the reconstructed data object from the hashed portions included in the subset of slices to obtain a hashed reconstructed data object; and verifying the reconstructed data object based on a hashed copy of the data object stored in one of the retrieved slices and the hashed reconstructed data object; and In response to the reconstructed data object being invalid, if other blockchain peers among the plurality of blockchain peers exist, slices are retrieved from the other blockchain peers for reconstructing the data object.

8. The method of claim 7, wherein the partitioning comprises splitting the data object into N parts corresponding to N blockchain peers, wherein any k of the N parts are capable of reconstructing the data object, and k is less than N.

9. The method of claim 8, wherein the distributing comprises assigning indexes between 1 and N to the N blockchain peers, respectively, and distributing the N slices to the N blockchain peers based on the assigned indexes.

10. The method of claim 8, wherein the partitioning comprises partitioning the data object into m equal-sized portions and adding k additional portions of data for loss resistance to generate the N portions.

11. The method of claim 7, further comprising encrypting the plurality of slices using an encryption key, wherein each of the blockchain peers maintains only an incomplete portion of the encryption key such that no single blockchain peer stores the encryption key in its entirety.

12. The method of claim 7, wherein the retrieval of a subset of the slices is performed via a slice retrieval application programming interface (API) running on a subset of the blockchain peers.

13. A non-transitory computer readable medium comprising instructions which, when read by a processor, cause the processor to perform a method comprising: Divide the data object into multiple parts; hashing the data object to generate a hashed data object, and hashing the plurality of portions to generate a plurality of hashed portions; generating a plurality of slices, wherein each slice comprises a hashed copy of the data object and a different corresponding hashed portion from the plurality of hashed portions; as well as Distributing the plurality of blockchain transactions having the plurality of slices to the plurality of blockchain peers, respectively, wherein each blockchain peer receives the blockchain transactions having a different slice, The method further comprises: Retrieving a subset of the slices from a subset of the blockchain peers in response to a request for the data object; generating a corresponding hash value of the reconstructed data object from the hashed portions included in the subset of slices to obtain a hashed reconstructed data object; and verifying the reconstructed data object based on a hashed copy of the data object stored in one of the retrieved slices and the hashed reconstructed data object; and In response to the reconstructed data object being invalid, if other blockchain peers among the plurality of blockchain peers exist, slices are retrieved from the other blockchain peers for reconstructing the data object.

14. The non-transitory computer-readable medium of claim 13, wherein the partitioning comprises splitting the data object into N parts corresponding to N blockchain peers, wherein any k of the N parts are capable of reconstructing the data object, and k is less than N.

15. The non-transitory computer-readable medium of claim 14, wherein the distributing comprises assigning indices between 1 and N to the N blockchain peers, respectively, and distributing the N slices to the N peers based on the assigned indices.

16. The non-transitory computer-readable medium of claim 13, wherein the method further comprises encrypting the plurality of slices using an encryption key, wherein each of the blockchain peers maintains only an incomplete portion of the encryption key such that no single blockchain peer stores the encryption key in its entirety.

Images