Tracking Data Transfer

Abstract

Embodiments of the present disclosure relate to tracking data transfers. Example operations may include one or more of the following operations: connecting, by a data owner node, to a blockchain network, the blockchain network including a plurality of storage provider peer nodes associated with a plurality of cloud storage providers; selecting, by the data owner node, a storage provider peer node from the plurality of storage provider peer nodes as an approved storage location member node; and executing, by the data owner node, a smart contract to: store data on a cloud storage provider from the plurality of cloud storage providers associated with the approved storage location member node, and record the movement of the data to the cloud storage provider on a blockchain.

Description

Technical Field

[0001] The present application relates generally to a database storage system, and more particularly to tracking data transfer. Background Art

[0002] A centralized database stores and maintains data in a single database (e.g., a database server) located in one 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, especially for security purposes, because of its single location. In a centralized database, data redundancy is minimized because a single storage location for all data also means that there is only one master record for a given data set.

[0003] However, centralized databases have obvious drawbacks. For example, centralized databases have a single point of failure. In particular, if there is no fault tolerance consideration and a failure occurs (e.g., hardware, firmware, and / or software failure), all data in the database will be lost and the work of all users will be interrupted. In addition, centralized databases are highly dependent on network connectivity, which increases latency when the database is not near the data users in the network. As a result, the slower the connection, the longer it takes to access the database each time. Another drawback is that bottlenecks occur when centralized databases experience high traffic due to a single location. In addition, centralized databases provide limited data access because only one copy of the data is maintained by the database. As a result, multiple devices cannot access the same piece of data at the same time without causing serious problems or the risk of overwriting the stored data. In addition, because the database storage system has almost no data redundancy, accidentally lost data is very difficult to retrieve except by manual operation from the backup storage device.

[0004] Thus, a blockchain-based solution is needed that overcomes these drawbacks and limitations. In today's data-driven society, it is often necessary to provide cloud storage to consumers. Consumers can choose the quality of service, cost, and region of this storage. Consumers want data to be saved only on storage devices that meet their expectations of the service they paid for. However, consumers have no visibility into where the data is actually stored. Sometimes consumers may be audited. However, without a reliable way to verify that data is only stored in approved / paid locations, there may be consequences, such as data location restriction penalties.

[0005] For example, a cloud storage consumer may require that data be stored only in certain areas, or stored at certain access speeds, or stored with certain Redundant Array of Inexpensive Disks (RAID) features. If the data owner pays to use only "golden block storage" at all times, the owner cannot confirm that the cloud provider actually stores the data there. If a disaster recovery (DR) event occurs, the storage manager application can automatically move the consumer's data to an active DR location, which the consumer may not know violates data privacy laws. In other words, the consumer (i.e., the data owner) needs 100% verification and proof of where and how his data is stored and accessed across multiple cloud storage providers. This includes primary data and backup copies.

[0006] Therefore, methods and systems for tracking data transfers between trusted cloud storage devices in a blockchain network are desirable. Summary of the invention

[0007] An example embodiment provides a system comprising a processor and a memory, wherein the processor is configured to perform one or more of the following operations: connect to a blockchain network comprising a plurality of storage provider peer nodes associated with a plurality of cloud storage providers; select a storage provider peer node from the plurality of storage provider peer nodes to serve as an approved storage location member node; and execute a smart contract to: store data on a cloud storage provider from the plurality of cloud storage providers associated with the approved storage location member node, and record the movement of the data to the cloud storage provider on a blockchain.

[0008] Another example embodiment provides a method comprising one or more of the following operations: connecting, by a data owner node, to a blockchain network comprising a plurality of storage provider peer nodes associated with a plurality of cloud storage providers; selecting, by the data owner node, a storage provider peer node from the plurality of storage provider peer nodes to serve as an approved storage location member node; and executing, by the data owner node, a smart contract to: store data on a cloud storage provider from the plurality of cloud storage providers that is associated with the approved storage location member node, and record the movement of the data to the cloud storage provider on a blockchain.

[0009] A further example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following operations: connect to a blockchain network comprising a plurality of storage provider peer nodes associated with a plurality of cloud storage providers; select a storage provider peer node from the plurality of storage provider peer nodes to serve as an approved storage location member node; and execute a smart contract to: store data on a cloud storage provider from the plurality of cloud storage providers that is associated with the approved storage location member node, and record the movement of the data to the cloud storage provider on a blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A network diagram of a system including a database according to an example embodiment is illustrated.

[0011] Figure 2A An example blockchain architecture configuration is illustrated according to an example embodiment.

[0012] Figure 2B A blockchain transaction flow according to an example embodiment is illustrated.

[0013] Figure 3A A permission network according to an example embodiment is illustrated.

[0014] Figure 3B Another permission network according to an example embodiment is illustrated.

[0015] Figure 4A A flow chart according to an example embodiment is illustrated.

[0016] Figure 4B A further flow chart according to an example embodiment is illustrated.

[0017] Figure 5A An example system configured to perform one or more operations described herein is illustrated according to an example embodiment.

[0018] Figure 5B Another example system configured to perform one or more operations described herein according to an example embodiment is illustrated.

[0019] Figure 5C A further example system configured to utilize smart contracts according to an example embodiment is illustrated.

[0020] Figure 5D Yet another example system configured to utilize blockchain according to example embodiments is illustrated.

[0021] Fig. 6AA process for causing a new block to be added to a distributed ledger is illustrated according to an example embodiment.

[0022] Figure 6B The content of a new data block according to an example embodiment is illustrated.

[0023] Figure 6C A blockchain for digital content according to an example embodiment is illustrated.

[0024] Fig.6D Illustrated are blocks that may represent the structure of a block in a blockchain according to example embodiments.

[0025] Figure 7 An example system is illustrated that supports one or more example embodiments. DETAILED DESCRIPTION

[0026] It is readily understood that the instant components generally described and illustrated in the figures herein may be arranged and designed in a wide 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 illustrated in the figures is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0027] The instant features, structures, or characteristics described throughout this specification may be combined or removed in any suitable manner in one or more embodiments. For example, the phrases "example embodiments," "some embodiments," or other similar language used in this specification refer to the fact that a particular feature, structure, or characteristic described in conjunction with an embodiment may be included in at least one embodiment. Therefore, the phrases "example embodiments," "some embodiments," "in other embodiments," or other similar language appearing in this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments.

[0028] In addition, although the term "message" may have been used for the description of the embodiment, the application can be applied to many types of networks and data. In addition, although some types of connections, messages and signaling can be described in exemplary embodiments, the application is not limited to some types of connections, messages and signaling.

[0029] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide for tracking data transfer between trusted storage devices of a blockchain network.

[0030] In one embodiment, the present application utilizes a decentralized database (such as blockchain) as a distributed storage system, which includes multiple nodes that communicate with each other. The decentralized database includes an immutable data structure that is only appended, which is similar to a distributed ledger that can maintain records between mutually untrusted parties. Untrusted parties are referred to as peers or peer nodes here. 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 can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. For consistency, if necessary, the process forms an account book by sorting storage transactions. In various embodiments, permission and / or permissionless blockchains can be used. In a public or permissionless blockchain, any party can participate without a specific identity. Public blockchains generally involve native cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). On the other hand, permissioned blockchain databases provide secure interactions between a group of entities that share a common goal but do not fully trust each other, such as the business of exchanging funds, goods, information, etc.

[0031] The present application may utilize a blockchain that operates arbitrary programmable logic that is customized for a decentralized storage solution and is referred to as a "smart contract" or "chain code". In some cases, a specialized chain code may exist to manage functions and parameters referred to as system chain codes. The present application may also utilize a smart contract, which is a trusted distributed application that utilizes the tamper-proof properties of a blockchain database and an underlying protocol between nodes (which is referred to as endorsement or endorsement policy). Blockchain transactions associated with the application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. The endorsement policy allows the chain code to specify endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed to verify the transaction. After verification, the transaction enters the sorting phase, in which a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0032] The present application may utilize nodes, which are communication entities of a blockchain system. A "node" may perform a logical function in the sense that multiple nodes of different types may run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes may include different types, such as a client or submitting client node that submits a transaction call to an endorser (e.g., a peer) and broadcasts a transaction proposal to an ordering service (e.g., an ordering node). Another type of node is a peer node that can receive transactions submitted by clients, submit transactions, and maintain the state and copy of the ledger of blockchain transactions. Peers may also play the role of endorsers, although this is not required. An ordering service node or orderer is a node that runs a communication service for all nodes and implements delivery guarantees, such as broadcasts 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 that typically includes control and setup information).

[0033] The present application may utilize a ledger, which is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions may result from chaincode calls (i.e., transactions) submitted by parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each party (such as a peer node) may maintain a copy of the ledger. Transactions may 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 referred to as a chain) for storing immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0034] The present application can utilize a chain as a transaction log that is structured into hash-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 of the block's transactions and the hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction on the chain that appeared previously, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), thereby effectively supporting the append-only nature of blockchain workloads.

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

[0036] Some advantages of the instant solution described and depicted herein include methods and systems for tracking data transfer in a blockchain network in a blockchain network. Exemplary embodiments address time and trust issues by extending features of a database such as immutability, digital signatures, and being a single source of truth. Exemplary embodiments provide a solution for tracking data transfer in a blockchain network in a blockchain-based network. Blockchain networks can be homogeneous depending on the asset type and the rules governing the assets based on smart contracts.

[0037] The difference between blockchain and traditional database is that blockchain is not a central storage, but a decentralized, immutable and secure storage, where nodes must share changes in records in the storage. Some properties inherent in blockchain and helpful for implementing blockchain include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc., which will be further described in this article. According to various aspects, the reason for the system for tracking data transmission using blockchain network is immutable accountability, security, privacy, allowed decentralization, availability, endorsement and accessibility of smart contracts, which are inherent and unique to blockchain. In particular, blockchain ledger data is immutable and provides an effective method for tracking data transmission in blockchain network. Similarly, the use of encryption in blockchain provides security and establishes trust. Smart contracts manage the status of assets to complete the life cycle. The example blockchain is a decentralized permission. Therefore, each end user has his own copy of the ledger to access. Multiple organizations (and peers) can join (on-board) on the blockchain network. Key organizations can act as endorsement peers to verify smart contract execution results, read sets and write sets. In other words, the inherent characteristics of blockchain provide an effective implementation for methods for tracking data transmission in a blockchain network.

[0038] One of the advantages of the example embodiment is that it improves the functionality of a computing system by implementing a system for tracking data transfer / replication in a blockchain-based system. Through the blockchain system described herein, a computing system can perform functionality for tracking data transfer in a blockchain network by providing access to capabilities such as distributed ledgers, peers, encryption, MSP, event processing, etc. Similarly, blockchains are able to create business networks and enable any user or organization to join and participate in them. In this way, blockchains are more than just databases. Blockchains have the ability to create business networks of users and joined / unjoined organizations to collaborate and execute service processes in the form of smart contracts.

[0039] Compared to traditional databases, example embodiments provide many advantages. For example, through blockchain, embodiments provide immutable accountability, security, privacy, permissioned decentralization, availability of smart contracts, endorsements, and accessibility, which are inherent and unique to blockchain.

[0040] At the same time, a traditional database cannot be used to implement the example embodiments because it does not bring all parties into the business network, does not create trusted collaboration, and does not provide efficient storage of digital assets. Traditional databases do not provide tamper-proof storage and do not provide preservation of stored digital assets. Therefore, the proposed method for tracking data transfer in a blockchain network cannot be implemented in a traditional database.

[0041] Meanwhile, if a conventional database had been used to implement the example embodiments, the example embodiments would suffer from unnecessary drawbacks, such as, search capabilities, lack of security, and slow transaction speeds. Additionally, only an automated method for tracking data transfers in a blockchain network is not possible.

[0042] Thus, example embodiments provide specific solutions to problems in the art / field of tracking data transfers in a blockchain network.

[0043] Example embodiments also change how data can be stored within the block structure of the blockchain. For example, digital asset data can be securely stored in a portion of a data block (i.e., within a header, data segment, or metadata). By storing digital asset data within a data block of the blockchain, the digital asset data can be attached to the immutable blockchain ledger through a chain of hash links of the blocks. In some embodiments, the data blocks can differ from traditional data blocks by not allowing personal data associated with digital assets to be stored with the assets in the traditional block structure of the blockchain. By removing personal data associated with digital assets, the blockchain can provide the advantages of anonymity based on immutable accountability and security.

[0044] According to an exemplary embodiment, a system and method for a trusted blockchain-based storage network is provided in which multiple storage locations act as trusted members in a blockchain network. A trusted storage network can interact with data providers in terms of "sending data to be stored" and "receiving data and storing it" similar to simultaneous ledger entries in a shared ledger. As a result, the data owner can select and approve members (i.e., storage locations) and can have full visibility into where exactly his data is stored. The data owner can also know how many copies of the data there are and can have evidence that the data has been moved / copied between storage locations. According to an exemplary embodiment, a shared ledger can represent an immutable and trusted record of where data has been moved or copied.

[0045] According to an exemplary embodiment, tracking of data transfer / copying may be achieved as follows.

[0046] 1) The data owner agrees to provide the data to a trusted (blockchain) storage network.

[0047] 2) All available certified storage locations are listed in a potential member list. The data owner can select storage locations that can become permitted members of the network based on location, cost, data access speed, and other criteria. Additionally, the data owner can simply enter the desired characteristics of the storage location, and matching locations can be presented to the data owner.

[0048] For example, a request from a data owner, “I want to store data, and I am willing to pay this much,” will filter out confirmed storage locations by price. The filtered storage locations may come from multiple storage providers (e.g., IBM, AWS, Google TM These providers can level the playing field for location and permissions. As a result, data owners have full control over where their data is stored.

[0049] 3) Data owners can approve membership of selected storage locations on the storage blockchain network to serve requests from data owners. Of course, multiple data owners can participate in this trusted storage blockchain network. For example, a group of developers or a group of clusters (all working on workloads from the same company) may be members of the blockchain network.

[0050] 4) Data owners can create and execute smart contracts to request that data units be created on storage locations that match the requested quality of service. This may not be done directly by the data owner, but rather by a storage provider abstraction (such as Kubernetes). TMStorage provider plugins) are used to implement storage volumes, where storage volumes can be dynamically provisioned by specifying storage classes. In this example, the storage class can send requests to a trusted storage blockchain by executing a smart contract.

[0051] 5) Every time data needs to be moved / copied for various reasons (archiving, DR, RAID recovery, etc.):

[0052] Smart contracts initiate data movement / copying actions in the blockchain ledger and record why the action was initiated (who initiated it, when it was initiated, why it was initiated, etc.);

[0053] The receiving storage location records in the ledger that the data unit has started receiving data and has completely received the data (when the data transmission is complete);

[0054] The sending storage location records in the ledger that the data unit was removed. If the data request is to copy the data, only the receiving storage location can record that the data was received, resulting in two copies of the data unit being stored. As a result, every data action (move, copy, delete, etc.) can be recorded in the shared ledger.

[0055] 6) At any time, data owners can revoke access (or grant access) to member tiers / locations so that where data can be stored can be customized over time;

[0056] 7) At any time, the data owner can query the ledger to find the exact location of the data unit and how many data units there are;

[0057] 8) At any time, when data leaks to a designated location, the storage location provider can immediately notify the data owner which data has been leaked.

[0058] Note that verification of the verified storage location may be accomplished through existing blockchain membership processes. This may be accomplished through user confirmation of location, quality of service, or through other registration means. According to an exemplary embodiment, a data unit is a collection of data, a container of data (volume, bucket, blob) - i.e., any unit where individual storage gets / sets may be targeted. Performing this level of granularity greatly improves performance because any data request to the trusted storage blockchain executed at the unit level can ensure consistency and privacy at a level that can be tracked and enforced. While one of the exemplary embodiments may focus on cloud storage, an alternative embodiment may be located entirely within a single organization so that local storage locations (e.g., removable drives, internal hard drives, servers, local Cleversafe TM System, Spectrum TMCompute servers) can also participate just as easily.

[0059] Figure 1 Illustrated is a logical network diagram for tracking data transfers in a blockchain network according to an example embodiment.

[0060] Reference Figure 1 , the example network 100 includes a data owner node 102 connected to a storage provider peer node 105 through a blockchain network 106. The storage provider peer node 105 may represent a storage location hosted by a cloud storage device 107. It is noted that the storage device 107 may not be a member of the blockchain network 106.

[0061] The data owner node 102 may be connected to a blockchain 106 having a ledger 108 for storing data movement (copying, deleting) records. Although this example describes only the data owner node 102 in detail, multiple such nodes may be connected to the blockchain 106. It should be understood that the data owner node 102 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of the data owner node 102 disclosed herein. The data owner node 102 may be a computing device or a server computer, etc., and may include a processor 104, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or another hardware device. Although a single processor 104 is depicted, it should be understood that the data owner node 102 may include multiple processors, multiple cores, etc. without departing from the scope of the data owner node 102 system.

[0062] The data owner node 102 may also include a non-transient computer-readable medium 112 on which machine-readable instructions executable by the processor 104 may have been stored. Examples of machine-readable instructions are shown as 112 to 118 and are further discussed below. Examples of non-transient computer-readable media 112 may include electronic, magnetic, optical, or other physical storage devices that contain or store executable instructions. For example, the non-transient computer-readable medium 112 may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a hard disk, an optical disk, or other type of storage device.

[0063] The processor 104 may acquire, decode, and execute machine-readable instructions 114 to connect to a blockchain network 106 including a plurality of storage provider peer nodes 105 associated with a plurality of cloud storage providers 107. As described above, the blockchain ledger 108 may store a record 110 of data movement (i.e., copying, deleting, relocating, etc.). The blockchain 106 network may be configured to use one or more smart contracts that manage transactions for a plurality of participating nodes. The processor 104 may acquire, decode, and execute machine-readable instructions 116 to select a storage provider peer node from a plurality of storage provider peer nodes as an approved storage location member node. The processor 104 may acquire, decode, and execute machine-readable instructions 118 to execute a smart contract to: store data on a cloud storage provider associated with an approved storage location member node from a plurality of cloud storage providers, and record the movement of data to the cloud storage provider on the blockchain. Thus, efficient tracking of data storage in the blockchain is provided. The blockchain network 106 may act as a trusted controller of data stored with data owners.

[0064] Figure 2A A blockchain architecture configuration 200 is illustrated according to an example embodiment. Figure 2A , the blockchain architecture 200 may include certain blockchain elements, for example, a set of blockchain nodes 202. These blockchain nodes 202 may include one or more nodes 204 to 210 (these four nodes are depicted by way of example only). These nodes participate in multiple activities, such as blockchain transaction addition and verification processes (consensus). One or more of the blockchain nodes 204 to 210 may endorse transactions based on endorsement policies and may provide ordering services for all blockchain nodes in the architecture 200. The blockchain node may initiate blockchain authentication and seek to write to the blockchain immutable ledger stored in the blockchain layer 216, a copy of which may also be stored in the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224, which are 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 according to the custom configuration sought by the participants 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 to 210 via attachment to the distributed ledger.

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

[0066] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and the services provided by the blockchain platform 212. Code 220 can control blockchain assets. For example, code 220 can store and transmit data and can be executed by nodes 204 to 210 in the form of smart contracts and associated chain codes, where conditions or other code elements are affected by their execution. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications affected by changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and the use of the ledger. For example, data storage information 226 can be processed by one or more processing entries (e.g., virtual machines) included in the blockchain layer 216. Result 228 can include data blocks reflecting data movement records. Physical infrastructure 214 can be used to retrieve any data or information described herein.

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

[0068] 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 for application operations. Smart contract code can write the output of each logical operation 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 kept private. Temporary data used / generated by the smart contract is saved in memory by the provided execution environment and then deleted when the data required by the blockchain is identified.

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

[0070] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is illustrated. Figure 2B , the transaction flow may include a transaction proposal 291 sent by the application client node 260 to the endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute the chaincode function to initiate the transaction. The output may include the chaincode result, the set of key / value versions read in the chaincode (read set), and the set of key / values ​​written to the chaincode (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then delivers the ordered transaction as a block to all peers 281 to 283 on the channel. Each peer 281 to 283 may validate the transaction before submitting to the blockchain. For example, the peer may check the endorsement policy to ensure that the correct assignment of the specified peers has signed the result for the transaction payload 293 and authenticated the signature.

[0071] Refer again Figure 2B, the client node 260 initiates a transaction 291 by constructing and sending a request to a peer node 281 (which is an endorser). The client 260 may include an application that utilizes a supported software development kit (SDK) that utilizes an available API to generate a transaction proposal. A proposal is a request to call 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 may act as a shim to encapsulate the transaction proposal into a properly designed format (e.g., protocol buffers via remote procedure call (RPC)) and employ the client's cryptographic certificate to generate a unique signature for the transaction protocol.

[0072] In response, the endorsing peer 281 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not been committed in the past (replay-attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 may input the transaction proposal as a parameter to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no updates are made to the ledger at this time. In 292, the value set is passed along with the signature of the endorsing peer 281 to the SDK of client 260 as a proposal response 292, which parses the payload for the application to use.

[0073] In response, the application of client 260 checks / verifies the signature of the endorsing peer and compares the proposed response to determine if the proposed responses are the same. If the chaincode only queries the ledger, the application checks the query response and typically does not submit the transaction to the sorting node service 284. If the client application intends to submit the transaction to the sorting node service 284 to update the ledger, the application determines whether the endorsement policy specified before submission has been fulfilled (i.e., whether all peer nodes required for the transaction have endorsed the transaction). Here, the client may include only one of the multiple parties for the transaction. In this case, each client may have its own endorsing node, and each endorsing node will need to endorse the transaction. The architecture is such that even if the application chooses not to check the response or otherwise forward an unendorsed transaction, the endorsement policy will still be enforced by the peer and supported during the submission verification phase.

[0074] After successful checks, in step 293, client 260 combines endorsements into transactions and broadcasts transaction proposals and responses in transaction messages to ordering nodes 284. Transactions may contain read sets / write sets, signatures of endorsing peers, and channel IDs. Ordering nodes 284 do not need to check the entire contents of a transaction to perform their operations, instead, ordering nodes 284 may only receive transactions from all channels in the network, sort them in chronological order by channel, and create blocks of transactions for each channel.

[0075] The block of transactions is delivered from the ordering node 284 to all peer nodes 281 to 283 on the channel. The transactions 294 in the block are validated to ensure that any endorsement policies are fulfilled and that there have been no changes to the ledger state for the read set variables since the read set was generated by the transaction execution. The transactions in the block are marked as valid or invalid. In addition, in step 295, each peer node 281 to 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 attached to the chain unchanged and whether the transaction is validated or invalid.

[0076] Figure 3A An example of a permissioned blockchain network 300 is illustrated, which features a distributed, decentralized peer-to-peer architecture. 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 may be limited to querying the ledger, while clients may be authorized to deploy, call, and query certain types of chaincodes.

[0077] Blockchain developers 310 can write chaincodes and client-side applications. Blockchain developers 310 can deploy chaincodes directly onto the network through an interface. In order to include certificates from traditional data sources 312 in chaincodes, developers 310 can use out-of-band connections to access data. In this example, blockchain users 302 connect to permissioned blockchains 304 through peer nodes 314. Before conducting any transactions, peer nodes 314 retrieve the user's registration and transaction certificates from certificate authorities 316, which manage user roles and permissions. In some cases, in order to conduct transactions on permissioned blockchains 304, blockchain users must have these digital certificates. At the same time, users trying to utilize chaincodes may need to verify their certificates on traditional data sources 312. In order to confirm the user's authorization, chaincodes can use out-of-band connections to the data through traditional processing platforms 318.

[0078] Figure 3B Another example of a permissioned blockchain network 320 is illustrated, which features a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 322 can initiate a transaction to a permissioned blockchain 324. In this example, the 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 may be limited to querying the ledger only, while clients may be authorized to deploy, call, and query certain types of chaincodes.

[0079] Blockchain developers 330 write chaincodes and client-side applications. Blockchain developers 330 can deploy chaincodes directly onto the network through an interface. In order to include certificates from traditional data sources 332 in the chaincode, developers 310 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, in order to conduct transactions on the permissioned blockchain 324, blockchain users must have these digital certificates. At the same time, users trying to utilize chaincodes may need to verify their certificates on traditional data sources 332. 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 338.

[0080] Figure 4A A flowchart 400 of an example method of tracking data transmission in a blockchain network is illustrated according to an example embodiment. Figure 4A, method 400 may include one or more of the following steps.

[0081] Figure 4A The diagram shows a data owner node 102 (see Figure 1 ) is a flowchart of an example method performed. It should be understood that Figure 4A The method 400 depicted in the embodiment may include additional operations, and some of the operations described therein may be removed and / or modified without departing from the scope of the method 400. For illustration purposes, reference is also made to Figure 1 The method 400 is described with reference to the features depicted in . In particular, the processor 104 of the data owner node 102 may perform some or all of the operations included in the method 400 .

[0082] Reference Figure 4A At block 412, the processor 104 may connect to a blockchain network including a plurality of storage provider peer nodes associated with a plurality of cloud storage providers. At block 414, the processor 104 may select a storage provider peer node from the plurality of storage provider peer nodes as an approved storage location member node. At block 416, the processor 104 may execute a smart contract to: store data on a cloud storage provider from the plurality of cloud storage providers associated with the approved storage location member node, and record the movement of the data to the cloud storage provider on a blockchain.

[0083] Figure 4B A flowchart 450 of an example method of tracking data transfer in a blockchain network is illustrated according to an example embodiment. Figure 4B , the method 450 may also include one or more of the following steps. In box 452, the processor 104 may approve the membership of the selected storage node based on the quality of service of the cloud storage provider associated with the selected storage node. In box 454, the processor 104 may record the copying or deletion of data from the cloud storage provider associated with the approved storage location member node on the blockchain. In box 456, the processor 104 may record the relocation of data from each of the cloud storage providers associated with the approved storage location member node to another location on the ledger of the blockchain. In box 458, the processor 104 may approve the storage location member node based on the location of the associated cloud storage provider, data access speed, and data storage cost. In box 460, the processor 104 may revoke data access from the approved storage location member node. In box 462, the processor 104 may record the revocation of data access from the approved storage location member node on the blockchain.

[0084] Figure 5AAn example system 500 is illustrated that includes a physical infrastructure 510 configured to perform various operations according to an example embodiment. Figure 5A , the physical infrastructure 510 includes a module 512 and a module 514. The module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which may perform any operation steps 508 (in the module 512) included in any example embodiment. The step / operation 508 may include one or more of the described or depicted embodiments and may represent output or written information written to or read from one or more smart contracts 530 and / or blockchain 520. The physical infrastructure 510, the module 512, and the module 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, the module 512 and the module 514 may be the same module.

[0085] Figure 5B Another example system 540 is illustrated that is configured to perform various operations according to an example embodiment. Figure 5B , system 540 includes module 512 and module 514. Module 514 includes blockchain 520 and smart contract 530 (which may reside on blockchain 520), which can perform any operation step 508 (in module 512) included in any example embodiment. Step / operation 508 may include one or more described or depicted embodiments and may represent output or written information written to or read from one or more smart contracts 530 and / or blockchain 520. Physical infrastructure 510, module 512, and module 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, module 512 and module 514 may be the same module.

[0086] Figure 5C An example system configured to utilize a smart contract configuration between contracting parties and an intermediary server configured to implement the terms of the smart contract on a blockchain are illustrated according to an example embodiment. Figure 5C , configuration 550 may represent a communication session, an asset transfer session, or a process or program driven by a smart contract 530 that explicitly identifies one or more user devices 552 and / or 556. The execution, operation, and results of the smart contract execution may be managed by a server 554. The content of the smart contract 530 may require digital signatures of one or more entities 552 and 556 as parties to the smart contract transaction. The results of the smart contract execution may be written to the blockchain 520 as a blockchain transaction. The smart contract 530 resides on the blockchain 520, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0087] Figure 5D A system 560 including a blockchain is illustrated according to an example embodiment. Figure 5D In the example of , an application programming interface (API) gateway 562 provides a public interface for accessing blockchain logic (e.g., smart contract 530 or other chain code) and data (e.g., distributed ledger, etc.). In this example, API gateway 562 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 552 and 556 to blockchain peers (i.e., server 554). Here, server 554 is a blockchain network peer component that saves a copy of the world state and a distributed ledger that allows clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, where, according to the smart contract 530 and the endorsement policy, the endorsing peer will run the smart contract 530.

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

[0089] An exemplary storage medium may be coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. In an 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 an alternative, the processor and the storage medium may reside as discrete components.

[0090] Fig. 6A illustrates a process 600 in which a new block is added to a distributed ledger 620 according to an example embodiment, and Figure 6B The content of a new data block structure 630 for a blockchain according to an example embodiment is illustrated. Fig. 6A, a client (not shown) may submit a transaction to blockchain nodes 611, 612, and / or 613. The client may execute instructions received from any source to perform activities on blockchain 620. As an example, a client may be an application acting on behalf of a requester (such as a device, person, or entity that proposes a transaction for a blockchain). Multiple blockchain peers (e.g., blockchain nodes 611, 612, and 613) may maintain the state of the blockchain network and a copy of the distributed ledger 620. Different types of blockchain nodes / peers may exist in a blockchain network, including an endorsement peer that simulates and endorses a transaction proposed by a client and a submission peer that verifies the endorsement, checks the transaction, and submits the transaction to the distributed ledger 620. In this example, blockchain nodes 611, 612, and 613 may play the role of an endorser node, a submitter node, or both.

[0091] The distributed ledger 620 includes a blockchain that stores immutable, ordered records in blocks and a state database 624 (current world state) that maintains the current state of the blockchain 622. One distributed ledger 620 may exist in each channel, and each peer maintains its own copy of the distributed ledger 620 for each channel of which they are members. The blockchain 622 is a transaction log structured into hash-linked blocks, where each block contains a sequence of N transactions. A block may include Figure 6B The individual components shown. Block links (by Fig. 6A ) can be generated by adding the hash of the header of the previous block to the block header of the current block. In this way, all transactions on the blockchain 622 are ordered and cryptographically linked together, preventing tampering of the blockchain data without breaking the hash link. In addition, due to the link, the latest block in the blockchain 622 represents every transaction that has appeared before it. The blockchain 622 can be stored in a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0092] The current state of the blockchain 622 and distributed ledger 622 may be stored in a state database 624. Here, the current state data represents the latest values ​​for all keys ever included in the chain transaction log of the blockchain 622. Chaincode calls execute transactions on the current state in the state database 624. In order to make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database 624. The state database 624 may include an indexed view of the transaction log that was transformed into the blockchain 622, so it can be regenerated from the chain at any time. The state database 624 may be automatically restored (or generated as needed) before a transaction is accepted.

[0093] The endorsing node receives a transaction from a client and endorses the transaction based on the simulation results. The endorsing node stores a smart contract that simulates a transaction proposal. When an endorsing node endorses a transaction, the endorsing node creates a transaction endorsement, which is a signed response of the endorsing node to the client application indicating an endorsement of the simulated transaction. The method of endorsing a transaction depends on an endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction". Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the sorting service 610.

[0094] The ordering service 610 accepts endorsed transactions, orders them into blocks, and delivers blocks to committing peers. For example, when a transaction threshold has been reached, a timer has expired, or other conditions, the ordering service 610 may initiate a new block. Fig. 6A In the example of , blockchain node 612 is a submitting peer that has received a new data block 630 for storage on blockchain 620. The first block in a blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, data stored therein, and the like.

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

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

[0097] When the ordering service 610 initiates a new data block 630, the new data block 630 may be broadcast to the committing peers (e.g., blockchain nodes 611, 612, and 613). In response, each committing peer verifies the transaction in the new data block 630 by checking to ensure that the read set and write set still match the current world state in the state database 624. 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 624. When the committing peer verifies the transaction, the transaction is written to the blockchain 622 on the distributed ledger 620, and the state database 624 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, the transaction that was ordered into the block will still be included in the block, but it will be marked as invalid and the state database 624 will not be updated.

[0098] Reference Figure 6B , a new data block 630 (also referred to as a data block) stored on the blockchain 622 of the distributed ledger 620 may include multiple data segments, such as a block header 640, block data 650, and block metadata 660. It should be understood that each of the depicted blocks and their contents (such as, Figure 6B The new data block 630 and its contents shown in FIG. 6 are merely examples and are not intended to limit the scope of the example embodiments. The new data block 630 may store transaction information of N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the block data 650. The new data block 630 may also store transaction information of N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the block data 650. Fig. 6A A link to the block 622 in the blockchain 622 of the block 630 is included in the block header 640. In particular, the block header 640 may include a hash of the header of the previous block. The block header 640 may also include a unique block number, a hash of the block data 650 of the new data block 630, etc. The block number of the new data block 630 may be unique and assigned in a different order, such as an incremental / continuous order starting from zero.

[0099] The block data 650 may store transaction information for each transaction recorded in the new data block 630. For example, the transaction data may include one or more of the transaction's type, version, timestamp, channel ID of the distributed ledger 620, transaction ID, epoch, payload visibility, chaincode path (deployment 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 hash, 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, list of keys, Merkel tree query summary. The transaction data may be stored for each of the N transactions.

[0100] In some embodiments, the block data 650 may also store new data 662 that adds additional information to the hash-linked chain of blocks in the blockchain 622. The additional information includes one or more of the steps, features, processes, and / or actions described or depicted herein. Thus, the new data 662 may be stored in an immutable log of blocks on the distributed ledger 620. Some advantages of storing such new data 662 are reflected in the various embodiments disclosed and depicted herein. Although in Figure 6B , the new data 662 is depicted in the chunk data 650 , but may also be located in the chunk header 640 or chunk metadata 660 .

[0101] Block metadata 660 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature on block creation, a reference to the last configuration block, a transaction filter identifying valid and invalid transactions in the block, the last persistent offset of the sorting service that sorted the block, etc. The signature, the last configuration block, and the sorter metadata may be added by the sorting service 610. Meanwhile, the submitter of the block (such as blockchain node 612) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 650 and a verification code identifying whether the transaction is valid / invalid.

[0102] Figure 6CAn embodiment of a blockchain 670 for digital content is illustrated in accordance with embodiments described herein. Digital content may include one or more files and associated information. Files may include 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 for protecting 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 the presentation and use of digital information is otherwise of interest. In such cases, the digital content may be referred to as digital evidence.

[0103] 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.) and 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:

[0104]

[0105] In one embodiment, the digital content may not be included in the blockchain. For example, in the absence of any digital content, the blockchain may store a cryptographic hash of the content of each block. 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 block in the storage area with the value stored corresponding to the actual digital content. This operation may be performed, for example, by a database gatekeeper.

[0106] This can be illustrated as follows:

[0107]

[0108] exist Figure 6C In the example embodiment of FIG. 670 , the blockchain 670 includes a plurality of blocks 678 1 , 678 2 , . . . 678 , which are cryptographically linked in an ordered sequence. N , where N ≥ 1. Used to link blocks 6781, 6782, ... 678 N The encryption may be any one of a number of keyed or non-keyed hash functions. In one embodiment, blocks 6781, 6782, ... 678N The block is subjected to a hash 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, random number-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 6781, 6782, ... 678 N Cryptographic linking may be performed by functions other than hash functions. For purposes of illustration, the following description is made with reference to a hash function (eg, SHA-2).

[0109] Blocks 6781, 6782, ... 678 in the blockchain N Each of the blocks includes a header, a version of the file, and a value. Due to the hashing process 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.

[0110] The first block 6781 in the blockchain is called the genesis block and includes a header 6721, an original file 6741, and an initial value 6761. The hashing scheme used for the genesis block can vary, and in fact the hashing schemes in all subsequent blocks can vary. For example, all of the information in the first block 6781 can be hashed together and at once, or each piece or portion of the information in the first block 6781 can be hashed separately, and then the hashing of the separately hashed portions can be performed.

[0111] The header 6721 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 6741 and / or the blockchain. The header 6721 may be automatically generated (e.g., by blockchain network management software) or manually generated by a blockchain participant. N Unlike the header in , header 6721 in the genesis block does not reference the previous block simply because the previous block does not exist.

[0112] For example, the original file 6741 in the genesis block may be data captured by a device with or without processing before it is included in the blockchain. The original file 6741 is received from a device, media source, or node through an interface of the system. The original file 6741 is associated with metadata, which may be manually or automatically generated by a user, device, and / or system processor, for example. The metadata may be included in the first block 6781 in association with the original file 6741.

[0113] The value 6761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 6741. In one embodiment, the one or more unique attributes may include a hash value of the original file 6741, metadata of the original file 6741, and other information associated with the file. In one implementation, the initial value 6761 may be based on the following unique attributes:

[0114] 1) The hash value calculated against the SHA-2 of the original file,

[0115] 2) Originating device ID,

[0116] 3) The start timestamp of the original file,

[0117] 4) The original storage location of the original file,

[0118] 5. The blockchain network member ID for the software that currently controls the original file and associated metadata.

[0119] Other blocks in the blockchain: 6782 to 678 N It also has a header, a file, and a value. However, unlike the first block 6721, the headers 6722 to 672 N Each header in includes a hash value of the immediately preceding block. The hash value of the immediately preceding block may just be the hash of the header of the preceding block, or may be the hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, tracing from the Nth block back to the genesis block (and associated original file) may be performed on a block-by-block basis (as indicated by arrow 680) to establish an auditable and immutable chain of custody.

[0120] Headers 6722 to 672 in other blocks N Each header in 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 generally associated with the corresponding file and / or blockchain.

[0121] Files 6742 to 674 in other blocks NThe original file may be the same as the original file, or may be a modified version of the original file in the genesis block depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. For example, the processing may involve any modification of the file in the previous block, such as editing information or otherwise changing the contents of the file, deleting information from the file, or adding or appending information to the file.

[0122] Additionally or alternatively, processing may involve merely copying a file from a prior block, changing a storage location of a file, analyzing a file from one or more prior blocks, moving a file from one storage or memory location to another storage or memory location, or performing an action on the file relative to the blockchain and / or its associated metadata. For example, processing involving analyzing a file may include appending, including, or otherwise associating various analytical, statistical, or other information associated with the file.

[0123] In other blocks, other blocks 6762 to 676 N The values ​​in each block in a blockchain are unique values ​​and are all different due to 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 hash of the block to which the value is assigned. Thus, the value of the block provides an indication of what processing was performed in the block and also allows tracking back to the original file through the blockchain. This tracking confirms the chain of custody of the file throughout the blockchain.

[0124] For example, consider a situation where portions of a file in a previous block are redacted, masked, or pixelated in order to protect the identity of the person appearing in the file. In this case, the block that includes the redacted file will include metadata associated with the redacted file, such as how the redacting was performed, who performed the redacting, timestamps of when the redacting(s) occurred, etc. The metadata may be hashed to form a value. Because the metadata for the block is different from the information that was hashed to form the value in the previous block, the values ​​are different from each other and can be recovered when decrypted.

[0125] In one embodiment, when any one or more of the following situations occur, the value of the previous block can be updated (e.g., the calculated new hash value) to form the value of the current block. In this example embodiment, the new hash value can be calculated by hashing all or part of the following information.

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

[0127] b) The new storage location for the file,

[0128] c) new metadata identified in association with the file,

[0129] d) The transfer of access to or control of files from one blockchain participant to another.

[0130] Fig.6D An example of a block that can represent the structure of a block in blockchain 690 is illustrated in accordance with one embodiment. i Include header 672 i 、File 674 i Total value 676 i .

[0131] Header 672 i Including the previous block Block i-1 The hash value of the previous block and additional reference information, for example, the additional reference information can be any type of information discussed in this article (e.g., header information including references, characteristics, parameters, etc.). All blocks reference the hash of the previous block, except for the genesis block. The hash value of the previous block can just be 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.

[0132] File 674 i The plurality of data are included in sequence, such as data 1, data 2, ..., data N. The data are tagged with metadata (metadata 1, metadata 2, metadata N) describing the content and / or characteristics associated with the data. For example, the metadata for each data may include information indicating a timestamp for the data, processing data, keywords indicating people or other content depicted in the data, and / or other characteristics that may be helpful in establishing the validity and content of the file as a whole, especially digital evidence of its use, for example, as described in conjunction with the following embodiments. In addition to the metadata, each data may be labeled with a reference REF1, REF2, ... REF to the previous data. N to mark to prevent tampering, gaps in the file, and sequential references through the file.

[0133] Once metadata is assigned to data (e.g., by a smart contract), it cannot be changed without a hash change that can be easily identified as invalid. Metadata thus creates a data log of information that can be accessed by participants in the blockchain.

[0134] Value 676 i 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 can be updated to reflect the processing performed on 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 values ​​in each block are shown as separate from the metadata for the data of the file and header, in another embodiment, the value can be based in part or in whole on the metadata.

[0135] Once blockchain 670 is formed, at any point in time, an immutable chain of custody for a file can be obtained by querying the blockchain for the transaction history of the value across blocks. This query or tracing process can begin by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continue to decrypt the values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption can also involve decrypting headers and file and associated metadata at each block.

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

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

[0138] Figure 7An example system 700 that supports one or more example embodiments described and / or depicted herein is illustrated. System 700 includes a computer system / server 702 that operates with many other general or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, microcomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0139] Computer system / server 702 may be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. In general, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 702 may 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 may be located in local and remote computer system storage media including memory storage devices.

[0140] like Figure 7 As shown, a computer system / server 702 in a cloud computing node 700 is shown in the form of a general-purpose computing device. Components of the computer system / server 702 may include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the system memory 706 to the processor 704.

[0141] Bus refers to any one or more of several 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, these architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0142] The computer system / server 702 typically includes various computer system readable media. Such media can be any available media accessible by the computer system / server 702, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 706 implements the flow charts of other figures. The system memory 706 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 710 and / or cache memory 712. The computer system / server 702 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 714 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 and writing from a removable non-volatile disk (e.g., a "floppy disk") and an optical drive for reading or writing from a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media) may be provided. In these examples, each may be connected to the bus by one or more data media interfaces. As will be further depicted and described below, the memory 706 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of various embodiments of the present application.

[0143] By way of example and not limitation, a program / utility 716 having a set (at least one) of program modules 718 may be stored in memory 706 as well as an operating system, one or more application programs, other program modules, and program data. 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 networking environment. Program modules 718 generally perform the functions and / or methods of various embodiments of the present application as described herein.

[0144] As will be appreciated by those skilled in the art, various aspects of the present application may be implemented as a system, method or computer program product. Therefore, various 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 a combination of software and hardware embodiments that may generally all be referred to as "circuit", "module" or "system" herein. In addition, various aspects of the present application may take the form of a computer program product implemented in one or more computer-readable media having a computer-readable program code implemented thereon.

[0145] The computer system / server 702 may also communicate with one or more external devices 720 (such as a keyboard, a pointing device, a display 722, etc.), one or more devices that enable a user to interact with the computer system / server 702, and / or any device that enables the computer system / server 702 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via an I / O interface 724. The computer system / server 702 may still further 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 726. As depicted, the network adapter 726 may communicate with other components of the computer system / server 702 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 702. 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.

[0146] Although exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media have been illustrated in the accompanying drawings and described in the detailed description above, it should be understood that the present application is not limited to the disclosed embodiments, but is capable of a large number of rearrangements, modifications, and substitutions as set forth and defined by the claims below. For example, the capabilities of the systems of the various figures may be performed by one or more of the modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver, or both. For example, all or part of the functionality performed by the various modules may be performed by one or more of these modules. Further, the functionality described herein may be performed at different times and is related to various events inside or outside the modules or components. Similarly, information between various modules may be sent between modules via at least one of the following: a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or sent between modules via multiple protocols. Similarly, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

[0147] Those skilled in the art will appreciate that a "system" may be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smart phone, or any other suitable computing device or combination of these 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 localized and distributed forms consistent with computing technology.

[0148] It should be noted that some of the system features described in this application have been presented as modules in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising a custom very large scale integrated "VLSI" circuit or gate array, an off-the-shelf semiconductor (such as a logic chip, a transistor), or other discrete components. A module may also be implemented in a programmable hardware device, such as a field programmable gate array, a programmable array logic, a programmable logic device, a graphics processing unit, etc.

[0149] Modules may also be implemented at least in part in software executed by various types of processors. For example, the executable code unit identified may include one or more physical or logical computer instruction blocks, for example, these instruction blocks may be organized as objects, processes or functions. However, the executable file of the identified module does not need to be physically located together, but may include different instructions stored in different locations, which include modules and realize the stated purpose of the module when being logically connected together. Further, the module may be stored on a computer-readable medium, for example, the computer-readable medium may be a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape or any other such medium for storing data.

[0150] In fact, an executable code module can be a single instruction or many instructions, and can even be distributed over multiple different code segments, between different programs, and across multiple memory devices. Similarly, operational data can be identified and described within a module, and can be implemented in any suitable form and organized in any suitable type of data structure. The operational data can be collected as a single data set or can be distributed over different locations, including on different storage devices, and can exist at least partially on a system or network only as an electronic signal.

[0151] It is easy to understand that the components of the present application (as generally described and illustrated in the figures herein) can be arranged and designed according to a variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but only represents the selected embodiments of the present application.

[0152] Those skilled in the art will readily appreciate that the foregoing 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.

[0153] 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 is limited solely by the appended claims when considered together with the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.) to the appended claims.

Claims

1. A method for tracking data transmission, comprising: connecting, by the data owner node, to a blockchain network comprising a plurality of storage provider peer nodes associated with a plurality of cloud storage providers; selecting, by the data owner node, a storage provider peer node from among the plurality of storage provider peer nodes to serve as an approved storage location member node; as well as The smart contract is executed by the data owner node to: storing data on the cloud storage provider among the plurality of cloud storage providers that is associated with the approved storage location member node; and The movement of the data to the cloud storage provider is recorded on the blockchain.

2. The method according to claim 1, further comprising: The selected storage provider peer node is approved for membership based on a quality of service of the cloud storage provider associated with the selected storage provider peer node.

3. The method according to claim 1, further comprising: The copying or deletion of the data from the cloud storage provider associated with the approved storage location member node is recorded on the blockchain.

4. The method according to claim 1, further comprising: The relocation of the data from each of the cloud storage providers associated with the approved storage location member node to another location is recorded on a ledger of the blockchain.

5. The method according to claim 1, further comprising: The storage location member nodes are approved based on the location of the associated cloud storage provider, data access speed, and data storage cost.

6. The method according to claim 1, further comprising: Data access is revoked from the approved storage location member nodes.

7. The method according to claim 6, further comprising: The revocation of access to the data from the approved storage location member node is recorded on the blockchain.

8. A computer program product comprising instructions which, when read by a processor, cause the processor to perform the actions of the method according to any one of claims 1 to 7.

9. A system for tracking data transmission, comprising: The processor of the data owner node; A memory on which machine-readable instructions are stored, which, when executed by the processor, cause the processor to perform the actions of the method according to any one of claims 1 to 7.

10. A computer system comprising modules for executing the steps of the method according to any one of claims 1 to 7.

Images