Content distributed on secure channels

Abstract

Example operations may include one or more of: transmitting a request for web page content to a network server, receiving a hypertext markup language (HTML) boilerplate file for the web page and a content delivery network (CDN) address of CDN content for the web page, retrieving the CDN content from a blockchain based on the CDN address, and displaying the web page at a client device based on the HTML boilerplate file and the CDN content retrieved from the blockchain.

Description

Technical Field

[0001] The present application generally relates to a content delivery system for delivering network content to client devices, and more particularly to a network that provides a secure channel for caching and delivering network content via a blockchain without requiring the client device to retrieve the content from a content delivery server. Background Art

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

[0003] However, centralized databases have significant drawbacks. For example, centralized databases have only a single point of failure. In particular, if there is no fault tolerance consideration and a hardware failure (e.g., hardware, firmware, and / or software failure) occurs, 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 connections. As a result, the slower the connection speed, the amount of time required for each database access will increase. Another disadvantage is that bottlenecks occur when centralized databases encounter high traffic due to a single location. In addition, since the database only maintains one copy of the data, centralized databases provide limited access to the data. As a result, multiple devices cannot access the same data at the same time without causing serious problems or risking overwriting stored data. In addition, since the database storage system has little or no data redundancy, it is difficult to retrieve accidentally lost data except by manually retrieving it from backup storage.

[0004] A content delivery network or content distribution network (CDN) is a geographically distributed network of proxy servers and their corresponding data centers. The purpose of a CDN is to provide high availability and high performance by distributing web content services spatially relative to end users. CDNs serve most of the Internet content today, including web objects (text, graphics, and scripts), downloadable objects (media files, software, documents), applications (e-commerce, portals), live streaming, on-demand streaming, and social media sites. However, some of the disadvantages of CDNs include: increasing bandwidth requirements due to richer content (such as 4K and virtual reality), the inability of web content to be cached at routers, proxies, ISPs, etc. due to the TLS protocol, low utilization of network resources due to redundant traffic, etc. Therefore, a solution is needed that can overcome these shortcomings and limitations. Summary of the invention

[0005] An example embodiment provides a system including a network interface and a processor. The network interface is configured to perform one or more of the following: transmit a request for web page content to a network server, and receive a hypertext markup language (HTML) boilerplate file for the web page and a content delivery network (CDN) address of CDN content for the web page. The processor is configured to perform one or more of the following: retrieve CDN content from a blockchain based on the CDN address, and display the web page at a client device based on the HTML boilerplate file and the CDN content retrieved from the blockchain.

[0006] Another example embodiment provides a method comprising one or more of transmitting a request for web page content to a network server, receiving a hypertext markup language (HTML) boilerplate file for the web page and a content delivery network (CDN) address of CDN content for the web page, retrieving the CDN content from a blockchain based on the CDN address, and displaying the web page at a client device based on the HTML boilerplate file and the CDN content retrieved from the blockchain.

[0007] Another 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: transmitting a request for web page content to a network server, receiving a hypertext markup language (HTML) boilerplate file for the web page and a content delivery network (CDN) address of CDN content for the web page, retrieving the CDN content from a blockchain based on the CDN address, and displaying the web page at a client device based on the HTML boilerplate file and the CDN content retrieved from the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1is a diagram illustrating a content delivery network implementing a secure delivery channel through blockchain according to an example embodiment;

[0009] Figure 2A is a diagram illustrating an example 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 permission network according to an example embodiment;

[0012] Figure 3B is a diagram illustrating another permission network according to an example embodiment;

[0013] Figure 4A is a diagram illustrating a content delivery system according to an example embodiment;

[0014] Figure 4B is a diagram illustrating a process of delivering content to a client device according to an example embodiment;

[0015] Figure 4C is a diagram illustrating content metadata that may be stored via a blockchain according to an example embodiment;

[0016] Figure 5 is a flow chart illustrating a method of retrieving web page content from 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 an example embodiment;

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

[0021] Fig. 7A is a diagram illustrating a process for adding a new block to a distributed ledger according to an example embodiment;

[0022] Figure 7B is a diagram illustrating the contents of a new data block according to an example embodiment;

[0023] Figure 7Cis a diagram illustrating a blockchain for digital content according to an example embodiment;

[0024] Fig.7D is a diagram showing a block structure that may represent a block in a blockchain according to an example embodiment; and

[0025] Figure 8 is a diagram illustrating an example system that supports one or more example embodiments. DETAILED DESCRIPTION

[0026] It will be readily understood that the components, as generally described and illustrated in the figures 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, apparatus, non-transitory computer-readable media, and systems, as illustrated in the figures, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0027] In one or more embodiments, the features, structures, or characteristics described throughout the specification may be combined or removed in any suitable manner. For example, the use of the phrases "example embodiments," "some embodiments," or other similar language throughout the specification refers to the fact that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment. Thus, the appearance of the phrases "example embodiments," "in some embodiments," "in other embodiments," or other similar language throughout the specification does not necessarily all refer to the same set of embodiments, and in one or more embodiments, the described features, structures, or characteristics may be combined or removed in any suitable manner.

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

[0029] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide a secure channel for content delivery via blockchain.

[0030] In one embodiment, the present application utilizes a decentralized database (such as a blockchain) as a distributed storage system including multiple nodes that communicate with each other. The decentralized database includes an additional immutable data structure similar to a distributed ledger that is capable of maintaining 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 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 hash chains on these blocks. In order to maintain consistency, the process forms an account book by sorting storage transactions as needed. In various embodiments, permissioned and / or permissionless blockchains can be used. In a public or unpermitted blockchain, anyone can participate without a specific identity. Public blockchains typically involve native cryptocurrencies and use consensus based on various 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 businesses that exchange 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, there may be a dedicated chain code for managing functions and parameters, referred to as a system chain code. The present application may also utilize smart contracts, which are trusted distributed applications that utilize the tamper-proof properties of the blockchain database and the underlying protocol between nodes, which is referred to as 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 of the transaction in the form of a set of peer nodes required for 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, in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.

[0032] The present application may utilize nodes as 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 client or submitting client nodes, which 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, which can receive transactions submitted by clients, submit transactions, and maintain the state and copy of blockchain transaction ledgers. Although not required, peers may also act as endorsers. Ordering service nodes or orderers are nodes that run communication services for all nodes and implement 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, typically including 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 be caused by chaincode invocations (i.e., transactions) submitted by a participant (e.g., a client node, a sorting node, an endorser node, a peer node, etc.). Each participant (such as a peer node) may maintain a copy of the ledger. A transaction may cause a set of asset key-value pairs to be 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, which is constructed as 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 transactions of the block, and the hash of the header of the previous block. In this way, all transactions on the ledger can be sorted 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 before it on the chain, so that all peer nodes can be ensured to be in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage device, 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 referred to as the world state. Chaincode invocations 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 a state database. The state database may be just 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 on demand) at peer startup and before transactions are accepted.

[0036] Example embodiments provide a new type of content delivery network in which blockchain can cache web content in a secure manner that meets the requirements of the HTTPS protocol. When a client device retrieves web content from a proxy server during a first visit, the client device can store the web content via the blockchain. When the client device (or another client device) accesses the web content during a subsequent visit, instead of retrieving the content from one or more proxy servers, the example embodiments enable the client device to retrieve the web content from the blockchain.

[0037] In traditional (non-HTTPS / HTTP) flows, data can be cached at one of the intermediate points of the network. However, in HTTPS flows, since HTTPS traffic must be secure, content (primarily from the CDN, which may be the nearest CDN node) cannot be cached at the intermediate node. In other words, it is not safe to retrieve the content directly from the adjacent edge node because the node may be malicious. Therefore, all clients must retrieve the data completely from the CDN. Therefore, HTTPS-based traffic (unlike HTTP traffic) cannot be cached at higher levels in the network hierarchy. Therefore, if user A has downloaded a file from an HTTPS server, the file cannot be cached at any level in the network hierarchy. At the same time, if user B must obtain the same file, user B usually has to retrieve the file again from the HTTPS server. On the other hand, if this is an HTTP server, the file may have been cached at the intersection of the network hierarchies of the two users.

[0038] The example embodiments introduce a new mechanism by which client devices can securely cache and access content. In particular, blockchain can be used to create a secure channel for web page content that is usually only stored by a proxy server (and uses an off-chain cache). Here, the blockchain may not be used as a data store, but may be used as a way to ensure the correctness and integrity of the delivered web page content. In addition, naturally, content discovery and cache control can be enabled. Therefore, HTTPS content can be securely stored / cached by the blockchain and accessed by client devices without the client device retrieving the HTTPS content from the proxy server.

[0039] Some benefits of the solution described and depicted in this article include a new channel for securely serving HTTPS content. In this way, network traffic can be reduced and the burden on proxy servers can be reduced, without having to bear the entire content load. The client device can access the blockchain (i.e., by accessing a trusted peer node), or the client device can be a member of the blockchain, thereby storing a local copy of the distributed ledger. In addition, the client device can also act as a cache (off-chain storage device, etc.) for storing web page content.

[0040] Figure 1 A content delivery network 100 implementing a secure delivery channel via a blockchain 140 according to an example embodiment is shown. Figure 1 In the example of , content delivery network 100 includes client devices 110 capable of receiving web content (e.g., web pages, applications, media files, scripts, documents, etc.), such as from websites hosted by web servers 120. However, rather than delivering website content entirely from web servers 120, websites may rely on other content sources in content delivery network 100. Figure 1 In the example of , proxy server 130 can deliver some or all of the content of a website hosted by web server 120 to client device 130. This service is effective in accelerating the delivery of content for high-traffic websites and websites with global reach. The closer proxy server 130 is geographically to client device 110, the faster the content can be delivered to client device 110. Content delivery network 100 also provides protection against traffic surges.

[0041] However, retrieving data from the proxy server 130 may still be inefficient and time consuming. To facilitate improved content delivery, the content delivery network 100 also includes a blockchain 140 capable of managing the content of the websites hosted by the network server 120. The blockchain 140 can be accessed by many users (including the client device 110), who can first store the website content retrieved from the proxy server 130 in the storage device of the blockchain 140. Figure 1In the example of , the blockchain 140 may store the content off-chain in the content storage devices 142A and 142B, but the embodiment is not limited thereto. As another example, the blockchain 140 may store the content via its distributed ledger.

[0042] That is to say, Figure 1 In the example of , the actual web content can be stored separately (off-chain) and provided to the requester. This is an off-chain storage device, and can even reside on a completely independent server. On the chain (blockchain 140), metadata for the content can be stored in multiple blocks, including identification metrics such as content ID, content hash (for integrity checking), list (location where the content is stored), and trust value (the trustworthiness of each data store, which can be measured in different ways). This metadata will be stored in the state database built by blockchain transactions.

[0043] The first access to the website content can come from the proxy server 130 (or other CDN server), just like for any cache-based system. For all content, the client device 110 can first query the blockchain 140 to find out whether the content is hosted by any edge node on the blockchain 140. For the first request, the client will not be able to find any metadata for the same in the ledger, and will subsequently request the content from the proxy server 130.

[0044] Over time, blockchain 140 may acquire web content for many websites accessed by client devices that are members of blockchain 140. Each time a client device 110 attempts to access a website (such as a website hosted by web server 120), client device 110 may transmit a request 111 for website content. In response, web server 120 may provide a link (e.g., URL, etc.) to a boilerplate template (e.g., HTML) for retrieving the content of the website to populate the boilerplate template. According to various embodiments, client device 110 has multiple options for retrieving website content. Here, client device 110 may retrieve website content from blockchain 140 (stored in content storage 142A and / or 142B). As another option, client device 110 may retrieve content from proxy server 130. The URL received from web server 120 may be the URL of proxy server 130. In this case, blockchain may use the URL of proxy server 130 as the ID of the content on blockchain 140.

[0045] In an example embodiment, the edge source mechanism for storing network content involves two different services (both of which can be provided by the same node or different nodes of the blockchain). The edge cache stores and provides content, and the blockchain peer stores content metadata and runs smart contracts for trust management, content discovery, cache control, etc. In some embodiments, the client device 110 can be a blockchain peer node and implement one or more of the edge cache and blockchain peer roles. For example, the client device 110 can choose to run one service, run two services, or run no service. If the client device 110 does not run any service, the client device 110 can access the blockchain 140 via at least one blockchain peer node to successfully store CDN content in edge sourcing. Similarly, the client device can find edge cache nodes within the blockchain 140 that can access content storage devices 142A and 142B to retrieve CDN content. In this case, the client device 110 may submit the CDN content (having been received from the CDN) to the edge cache server and submit corresponding metadata to the blockchain peer to track the storage location of the CDN content on the content storage devices 142A and / or 142B.

[0046] In some embodiments, the edge cache server may even be running on the same LAN as the client device 110. Generally, this can be seen to be closer to the client device than the proxy server 130, thereby providing data more efficiently. However, even in the rare case that the proxy server 130 happens to be closer, the actual decision of whether to use the edge cache or the proxy server 130 can be left to the client.

[0047] According to various embodiments, the client device 110 can query a trusted blockchain peer (which itself can run) to access content stored via the blockchain 140. The blockchain peer can perform a "content discovery" job and return a list of edge cache servers that contain (host) desired content near the client and corresponding trust metrics. The client device 110 can make a call as to which option to proceed. For example, if the client device 110 finds a trusted edge cache list (because its trust value is high, other clients have endorsed the correctness of the content, or it has processed the server before), it can request the content directly from that server. If the client device 110 does not like the trust value of any option, it can fall back to retrieve the content directly from the proxy server 130 (and optionally, contribute the content to edge tracing at one of its trusted edge cache servers). Similarly, if the client device 110 believes that the proxy server 130 is closer than the edge cache server, it can fall back to the proxy server 130 again.

[0048] In some embodiments, it may be unwise for the client device 110 to blindly retrieve otherwise secure content from a neighboring edge node because the node may be malicious and provide corrupted content to the client. To address this issue, the blockchain 140 can provide more than just a simple content discovery service. For example, the blockchain 140 can provide the client device 110 with the same trust guarantees as those obtained using an HTTPS secure CDN server. In particular, the blockchain can implement a trust calculation that assigns a trust index to each list (hosting node) of content (e.g., a list can identify an edge node that hosts content with certain metadata). Moreover, performing trust calculations on the blockchain can ensure that it is reliable and tamper-proof, meaning that a malicious party cannot modify the trust indexes associated with various lists. Among all the lists available for a particular content, the client device 110 can select the best possible list based on factors such as the trust index, the cost of obtaining the content, or even decide to obtain the content directly from the CDN if no list is acceptable.

[0049] 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 verification processes (consensus). 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 the blockchain immutable ledger stored in the blockchain layer 216, a copy of which may also be stored on 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 customized 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-210 via attachment to the distributed ledger.

[0050] 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 necessary to process program code and use the physical infrastructure 214. Cryptographic trust services 218 may be used to verify transactions such as asset exchange transactions and keep information private.

[0051] Figure 2A The blockchain architecture configuration of can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and 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-210 in the form of smart contracts and associated chain codes, which have conditions or other code elements subject to their execution. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications subject to changes, updates, etc. The smart contract itself can be used to identify rules associated with the authorization of the ledger and the requirements and use of the ledger. For example, a content request 226 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The result 228 can include retrieving the requested content from a storage device (e.g., off-chain) and delivering it to a client device. The physical infrastructure 214 can be used to retrieve any data or information described herein.

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

[0053] 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 various logical operations to the blockchain. The code can be used to create temporary data structures in virtual machines or other computing platforms. 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 deleted once the data required by the blockchain is identified.

[0054] The 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 where it is executed and validated by chain validators together in a consensus process. The chaincode receives the hash and retrieves from the blockchain a hash associated with a data template created using a previously stored feature extractor. If the hash of the hashed identifier matches the hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain.

[0055] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain is shown according to an example embodiment. Figure 2B , a transaction flow may include a transaction proposal 291 sent by an application client node 260 to an 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 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, 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 sorting service node 284. The sorting service node 284 then delivers the sorted transaction as a block to all peers 281-283 on the channel. Each peer 281-283 may validate the transaction before submitting to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct assignment of the specified peer has signed the result and authenticated the signature against the transaction payload 293.

[0056] Reference again Figure 2B, the client node 260 initiates a transaction 291 by constructing a request and sending it to the peer node 281 as 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 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 package the transaction proposal into a format of the appropriate architecture (e.g., protocol buffers over remote procedure calls (RPCs)) and generate a unique signature for the transaction proposal using the client's cryptographic certificate.

[0057] In response, the endorsing peer node 281 can verify that: (a) the transaction proposal is formatted correctly, (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) has been properly authorized to perform the proposed operation on the channel. The endorsing peer node 281 can 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 have been made to the ledger at this time. In 292, the set of values ​​and the signature of the endorsing peer node 281 are passed back to the SDK of the client 260 as a proposal response 292, which parses the payload for application consumption.

[0058] In response, the client 260 application checks / verifies the endorsed peer signature and compares the proposed response to determine if the proposed responses are the same. If the chaincode only queries the ledger, the application will check the query response and generally 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 specified endorsement policy has been implemented (i.e., whether all peer nodes required by the transaction endorse the transaction) before submitting. Here, the client can include only one of the multiple parties to the transaction. In this case, each client can have its own endorsement node, and each endorsement node is required to endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forward unendorsed transactions, the endorsement policy will still be enforced by the peers and maintained during the submission verification phase.

[0059] After successful checks, in step 293, client 260 assembles the endorsements into a transaction and broadcasts the transaction proposal and response within a transaction message to ordering node 284. The transaction may contain a read / write set, the endorsing peer signature, and the channel ID. Ordering node 284 does not need to check the entire contents of the transaction in order to perform its operations, but rather ordering node 284 can simply receive transactions from all channels in the network, sort them chronologically by channel, and create transaction blocks per channel.

[0060] 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 ledger state of the read set variables has not changed since the transaction execution generated the read set. The transactions in the block are marked as valid or invalid. In addition, in 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 invalid.

[0061] Figure 3A An example of a permissioned blockchain network 300 is shown, featuring 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, or the like. 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.

[0062] 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 permissioned 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 to conduct transactions on the permissioned blockchain 304. At the same time, users who attempt to use chaincodes may be required to verify their certificates 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.

[0063] Figure 3B Another example of a permissioned blockchain network 320 is shown, featuring a distributed, decentralized peer-to-peer architecture. 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, or the like. 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, while clients may be authorized to deploy, call, and query certain types of chaincodes.

[0064] Blockchain developers 330 write chaincodes and client-side applications. Blockchain developers 330 can deploy chaincodes directly to the network through an interface. To include certificates from traditional data sources 332 in chaincodes, developers 330 can use out-of-band connections to access 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 to conduct transactions on permissioned blockchains 324. At the same time, users attempting to use chaincodes may be required to verify their certificates on traditional data sources 332. To confirm the user's authorization, chaincodes can use out-of-band connections to that data through traditional processing platforms 338.

[0065] Figure 4A A content delivery system 400 is shown according to an example embodiment, and Figure 4B A process 450 of delivering content to a client device 410 included in a content delivery system 400 is shown according to an example embodiment. Figure 4A and 4B , content delivery system 400 includes a client device 410 running a web browser 412 configured to access web content from a website hosted by a web server 420. In 451, web browser 412 of client device 410 may submit a request for content (e.g., a page request, etc.), and in response, in 452, may receive a boilerplate HTML page from web server 420. The response from web server 420 in 452 may also include address information of a host server (e.g., content server 430) that hosts and provides the content. According to various embodiments, client device 410 has two options (A and B) for retrieving web content for populating the boilerplate HTML page.

[0066] For example, in 453, client device 410 may query blockchain 440 for the content of a webpage. In this example, client device 410 may be a peer of blockchain 440 and may therefore include peer node software 444. Here, client device 410 may query local blockchain peer 444 to check whether the content may be edge sourced. In response, in 454, the smart contract performs content discovery and retrieves available peer hosts that can access the content. Here, when multiple peers have access / hosted content, the smart contract may select peer 444 to retrieve the content based on lookup time and network status.

[0067] In 455, the client device 410 may determine whether any of the hosts found are acceptable. For example, the client device 410 may make a determination based on a trust calculation of the available peer hosts. If the available blockchain host is acceptable, then in 456, the client device 410 triggers the retrieval of content from the node of the blockchain 440. In addition, in 457, the client device 410 may vote (up, down, etc.) on the content received from the host of the blockchain 440.

[0068] Client device 410 may retrieve the content from blockchain 440 via the identification of the content. Figure 4C In the example of , content metadata 470 for each piece of content can be stored on blockchain 440. Here, content metadata 470 can be used to identify content. In this example, content metadata 470 includes a content ID 471 as a unique ID of the content, a URL 472 of a proxy server as the source of the content. In addition, content metadata 470 includes multiple lists (or hosts) storing / caching copies of the content. Each list may include an address 473 of an edge cache on the blockchain, a hash 474 of the content (for integrity check), a list (where the content is stored), an expired TTL 475 identifying the cache, a trust value 476 indicating the credibility of each data storage, and a cost 477 (such as network bandwidth) required to access the data. Content metadata 470 can be stored in a state database established by a blockchain transaction.

[0069] If the client device determines in 455 that no host is acceptable (or no host is available), then in 458, the client device 410 may retrieve the content from the CDN server 430. Additionally, in 459, the client device 410 may determine whether to share the content with other participants of the content blockchain 440. If the client device 410 determines to share the content, then in 460, the client device 410 may trigger storage of the content via one or more blockchain peers 444. Thus, subsequent access to the same content may be retrieved by the client device 410 (and other client devices that are participants of the blockchain 440) without having to retrieve the content from the CDN server 430.

[0070] Figure 5 A method 500 of retrieving web page content from a blockchain according to an example embodiment is shown. Figure 5 At 510, the method may include transmitting a request for web page content to a network server. For example, the request may include a page request for web content such as a page, graphic, script, application, media file, etc. At 520, the method may include receiving a hypertext markup language (HTML) boilerplate file for a web page and a content delivery network (CDN) address for CDN content for the web page. The boilerplate file may include a link to a CDN server (e.g., a proxy server, etc.) from which the content is to be retrieved.

[0071] At 530, the method may include retrieving the CDN content from the blockchain based on the CDN address. Here, the method may include retrieving the CDN content from the blockchain storing the content instead of a proxy server, etc. At 540, the method may also include displaying a web page at the client device based on the HTML boilerplate and the CDN content retrieved from the blockchain. In some embodiments, the method may also include determining to retrieve the CDN content from the blockchain instead of the CDN server identified by the CDN address in response to detecting that the CDN content is stored at the blockchain.

[0072] According to various embodiments, the retrieved CDN content may include Hypertext Transfer Protocol Secure (HTTPS) content. In some embodiments, the method may further include: determining a trust level of a blockchain peer based on at least one of a vote and a weight provided by a plurality of clients of the blockchain; and retrieving the CDN content from the blockchain peer in response to determining that the trust level meets a predetermined threshold. In some embodiments, the retrieval may include querying the CDN content in the blockchain based on a uniform resource locator (URL) of a CDN content source of the CDN content. In some embodiments, the CDN content may be retrieved from a distributed ledger locally managed by a client device. In some embodiments, the CDN content may be cached by the blockchain in response to a previous access to the CDN content by another client device. In some embodiments, the CDN content may be stored by the blockchain in an off-chain storage device of the blockchain, and the blockchain maintains metadata for the CDN content.

[0073] Fig. 6A An example 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) that can perform any operation steps 608 (in the module 612) included in any example embodiment. The step / operation 608 may include one or more embodiments described or depicted, 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.

[0074] 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) that can perform any operation step 608 (in module 612) included in any example embodiment. Step / operation 608 may include one or more embodiments described or depicted, 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.

[0075] Figure 6C 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 according to an example embodiment are shown. Figure 6C , configuration 650 may represent a communication session, asset transfer session, or process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract execution may be managed by a server 654. The contents of the smart contract 630 may need to be digitally signed by 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.

[0076] Fig.6D A system 660 including a blockchain is shown according to an example embodiment. Fig.6D In the example of , an 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 has a copy of the world state and the distributed ledger to allow clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where depending on the smart contract 630 and the endorsement policy, the endorsing peer will run the smart contract 630.

[0077] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. The computer program may be embodied in 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.

[0078] 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 with 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.

[0079] Fig. 7A A process 700 of adding a new block to a distributed ledger 720 is shown according to an example embodiment, and Figure 7B The content of a new data block structure 730 for a blockchain according to an example embodiment is shown. Fig. 7A , a client (not shown) can submit a transaction to blockchain nodes 711, 712, and / or 713. A client can be an instruction received from any source to enact an activity on blockchain 720. As an example, a client can be an application that takes action 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) can maintain the state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes / peers can exist in the blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients, and submission peers that verify endorsements, verify transactions, and submit transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 can act as endorser nodes, submitter nodes, or both.

[0080] 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. There can be one distributed ledger 720 per 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 that is structured as hash-linked blocks, where each block contains a sequence of N transactions. A block may include, for example, Figure 7B The various components shown. A link to a block can be generated by adding the hash of the previous block's header to the current block's block header ( Fig. 7A ). In this way, all transactions on blockchain 722 are ordered and cryptographically linked together to prevent tampering of blockchain data without breaking the hash link. In addition, due to the link, the latest block in blockchain 722 represents every transaction that came before it. Blockchain 722 can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0081] The current state of the blockchain 722 and the 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. Chaincode invocations execute transactions against the current state in the state database 724. In order to make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database 724. The state database 724 may include an indexed view into the transaction log of 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 needed) at the initiation of a peer before a transaction is accepted.

[0082] The endorsing node receives the transaction from the client and endorses the transaction based on the simulation results. The endorsing node saves 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 peers must endorse the transaction". Different channels can have different endorsement policies. The endorsed transaction is forwarded to the sorting service 710 by the client application.

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

[0084] The sorting service 710 may consist 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 these transactions are submitted to the distributed ledger 720. The architecture of the blockchain network may be designed to make a specific "sorting" implementation (e.g., Solo, Kafka, BFT, etc.) a pluggable component.

[0085] 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 the transactions are submitted to the network. Unlike cryptocurrency blockchain systems where ordering is performed by solving cryptographic puzzles, in this example, the parties to the distributed ledger 720 can choose the ordering mechanism that best suits the network.

[0086] 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 in 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 in 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 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.

[0087] 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 the various blocks depicted and their contents (such as Figure 7B The new data block 730 and its contents shown are examples only and are not intended to limit the scope of the example embodiments. The new data block 730 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750. The new data block 730 may also include a previous block within the block header 740 (e.g., Fig. 7A In 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 may be assigned in various orders, such as an increasing order / sequential order starting from zero.

[0088] 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 following: transaction type, version, timestamp, channel ID of the distributed ledger 720, transaction ID, epoch, payload visibility, chaincode path (deploy TX), 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 (a list of keys and versions read by a transaction, etc.), write set (a list of keys and values, etc.), start key, end key, key list, Merkle tree query summary, etc. The transaction data may be stored for each of the N transactions.

[0089] In some embodiments, the block data 750 may also store content metadata 752, which may include Figure 4C Thus, the system can store content metadata 752 within blockchain 722. Content metadata 752 can identify web page content (e.g., HTTPS content, etc.) to be delivered to a web page from a content delivery network. However, in this case, blockchain 722 (or an off-chain storage device accessible to blockchain 722) can store the content and provide the content to the web browser of the client device. Content metadata 752 can be stored in an immutable log of blocks on distributed ledger 720. Although in Figure 7B , content metadata 752 is described in block data 750 , but it may also be located in block header 740 or block metadata 760 .

[0090] The block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at block creation, a reference to the last configuration block, a transaction filter identifying valid and invalid transactions within the block, the last offset persisted by 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 710. Meanwhile, the submitter of the block (such as a blockchain node 712) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 750 and a verification code identifying whether the transaction is valid / invalid.

[0091] Figure 7CAn embodiment of a blockchain 770 for digital content according to embodiments described herein is shown. The digital content may include one or more files and related information. The files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of the blockchain may serve as a safeguard to protect the integrity, validity, and authenticity of the digital content to make it suitable for use in legal proceedings where admissibility rules apply or in other settings where evidence is considered or otherwise of interest in the display and use of digital information. In this case, the digital content may be referred to as digital evidence.

[0092] 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 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:

[0093]

[0094] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store a cryptographic hash of the contents of each block without any digital content. The digital content may be stored in another storage area or memory address in association with the hash of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area, or 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 content in the storage area with the value stored corresponding to the actual digital content. For example, this operation may be performed by a database gatekeeper. This may be illustrated as follows:

[0095]

[0096] exist Figure 7C In the example 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, 7872, ..., 778 N The encryption may be any one of a plurality of keyed or non-keyed hash functions. In one embodiment, blocks 7781, 7872, ..., 778 NThe blocks 7781, 7872, ..., 778 may be cryptographically linked by a function other than a hash function. N For purposes of illustration, the following description is made with reference to a hash function such as SHA-2.

[0097] Blocks 7781, 7872, ..., 778 in the blockchain N Each of the blocks includes a header, a file version, and a value. Due to the hash 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.

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

[0099] The header 7721 may include one or more initial parameters, 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 may be manually generated by a blockchain participant. N Unlike the header in , header 7721 in the genesis block does not reference the previous block, simply because there is no previous block.

[0100] The original file 7741 in the genesis block can be, for example, data captured by a device that processes or does not process it before including it 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 in association with the original file 7741.

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

[0102] 1) SHA-2 calculation hash value of the original file

[0103] 2) Originating device ID

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

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

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

[0107] Other blocks in the blockchain 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 N Each of the blocks includes the hash value of the immediately preceding block. The hash value of the immediately preceding block may be just 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 remaining block, as shown by arrow 780, tracking can be performed block by block from the Nth block back to the genesis block (and the associated original file) to establish an auditable and immutable chain of custody.

[0108] Headers 7722 to 772 in other blocks N Each of the 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 typically associated with the corresponding file and / or blockchain.

[0109] 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 genesis block, for example, depending on 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 file in the previous block, such as editing information or otherwise changing the contents of the file, taking information away from the file, or adding or appending information to the file.

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

[0111] Each of the other blocks 7762 to 776 N The values ​​in each of the blocks 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. The value of the block thus provides an indication of the processing performed in the block and also allows tracing back to the original file through the blockchain. This tracking confirms the chain of custody of the file throughout the blockchain.

[0112] For example, consider a situation where portions of a file in a previous block are redacted, masked, or pixelated to protect the identity of the person shown 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 redaction was performed, who performed the redaction, a timestamp of when the redaction was performed, etc. The metadata may be hashed to form a value. Since the metadata for the block is different from the information that was hashed to form the value in the previous block, the values ​​are distinct from each other and can be recovered upon decryption.

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

[0114] a) If the file has been manipulated in any way (for example, if the file has been edited, copied, changed, accessed, or other actions have been taken), then a new SHA-2 hash is calculated

[0115] b) The new storage location of the file

[0116] c) Identify new metadata associated with the file

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

[0118] Participants

[0119] Fig.7D An embodiment of a block that can represent the structure of a block in blockchain 790 according to one embodiment is shown. i ) including header 772i 、File 774 i The sum is 776 i .

[0120] Head 772 i Including the previous block (block i-1 ) and additional reference information, which can be, for example, any type of information discussed in this article (e.g., header information, including references, features, parameters, etc.). Of course, except for the genesis block, all blocks reference the hash of the previous block. The hash value of the previous block can be just the hash of the header in the previous block, or it can also be the hash of all or part of the information in the previous block, including files and metadata.

[0121] File 774 i The system includes a plurality of data, such as data 1, data 2, ..., data N. The data are tagged with metadata (metadata 1, metadata 2, ..., metadata N), which describe the content and / or characteristics associated with the data. For example, the metadata of each data may include a timestamp indicating the data, processing data, keywords indicating characters or other contents depicted in the data, and / or information that may be helpful in establishing the validity and content of the file as a whole (especially its use of digital evidence), as described below in conjunction with the embodiments. In addition to metadata, each data may use references (reference 1, reference 2, ..., reference N) to identify the content and / or characteristics of the data. N ) to previous data to prevent tampering, gaps in the file, and sequential references through the file.

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

[0123] Value 776 i is a hash value or other value computed based on any of the types of information discussed previously. For example, for any given block (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 actions or information to be added. Although the value in each block is shown as being separate from the metadata of the file and header data, in another embodiment, the value can be based in part or in whole on the metadata.

[0124] Once the blockchain 770 is formed, at any point in time, the immutable chain of custody of the file can be obtained by querying the transaction history of the values ​​across blocks in the blockchain. This query or tracking process can start by decrypting the value of the currently 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 restored. Decryption can also include decrypting the header and file and associated metadata at each block.

[0125] Decryption is performed based on the type of encryption that occurs in each block. This can 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 can use a predetermined algorithm to generate a public and private key pair. The public and private keys are related to each other through some mathematical relationship. The public key can be publicly distributed to be used as an address to receive messages from other users, for example, 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 sure that only the sender can send the message.

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

[0127] Figure 8 An example system 800 is shown that supports one or more example embodiments described and / or depicted herein. The system 800 includes a computer system / server 802 that can operate with many other general or special computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with the computer system / server 802 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or portable 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.

[0128] Computer system / server 802 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 802 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.

[0129] like Figure 8 As shown, the computer system / server 802 in the cloud computing node 800 is shown in the form of a general-purpose computing device. The components of the computer system / server 802 may include, but are not limited to, one or more processors or processing units 804, a system memory 806, and a bus that couples various system components including the system memory 806 to the processor 804.

[0130] 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.

[0131] Computer system / server 802 generally includes various computer system readable media. Such media can be any available media accessible to computer system / server 802, and includes removable and non-removable media of volatile and non-volatile media. In one embodiment, system memory 806 implements the flow charts of other figures. System memory 806 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 810 and / or cache memory 812. Computer system / server 802 can also include other removable / non-removable volatile / non-volatile computer system storage media. As an example only, a storage system 814 can be provided for reading and writing non-removable non-volatile magnetic media (not shown and generally referred to as "hard drive"). Although not shown, a disk drive for reading and writing a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading or writing a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media) can be provided. In this case, each can be connected to the bus through one or more data media interfaces. As will be further depicted and described below, memory 806 may include at least one program product having a set (eg, at least one) of program modules configured to perform the functions of various embodiments of the present application.

[0132] As an example and not limitation, a program / utility 816 having a set (at least one) of program modules 818, as well as an operating system, one or more applications, other program modules, and program data can be stored in memory 806. Each of the operating system, one or more applications, other program modules, and program data, or some combination thereof, can include an implementation of a networking environment. Program modules 818 generally perform the functions and / or methods of various embodiments of the present application described herein.

[0133] 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 following forms: complete hardware embodiments, complete software embodiments (including firmware, resident software, microcode, etc.) or embodiments combining software and hardware aspects, which may generally be referred to herein as "circuits", "modules" or "systems". In addition, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media containing computer-readable program codes thereon.

[0134] The computer system / server 802 may also communicate with: one or more external devices 820, such as a keyboard, a pointing device, a display 822, etc.; one or more devices that enable a user to interact with the computer system / server 802; and / or any device that enables the computer system / server 802 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 824. However, the computer system / server 802 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 826. As shown, the network adapter 826 communicates with other components of the computer system / server 802 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 802. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems, etc.

[0135] Although illustrated in the drawings and described in the foregoing detailed description, exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media, it should be understood that the present application is not limited to the disclosed embodiments, but can be rearranged, modified, and replaced as described and defined in the appended claims. For example, the capabilities of the systems of the various drawings can be performed by one or more of the modules or components described herein or in a distributed architecture, and can include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by each module can be performed by one or more of these modules. In addition, the functions described herein can be performed at various times and in relation to various events inside or outside the module or component. Moreover, the information sent between various modules can be sent between various modules via at least one of the following: data network, Internet, voice network, Internet protocol network, wireless device, wired device, and / or via multiple protocols. Moreover, the message sent or received by any module can be sent or received directly and / or via one or more other modules.

[0136] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a cell phone, a tablet computing device, a 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.

[0137] 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, a module can be implemented as a hardware circuit that includes a custom very large scale integrated circuit (VLSI) circuit or gate array, an off-the-shelf semiconductor such as a logic chip, a transistor, or other discrete components. A module can 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, or the like.

[0138] Module can also be realized at least in part with the software executed by various types of processors.Identified executable code unit can for example include one or more physical or logical blocks of computer instructions that can for example be organized as objects, processes or functions.However, the executable file of identified module does not need to be physically located together, but can include different instructions stored in different locations, which include modules and realize the above-mentioned purpose of modules when logically combined together.In addition, module can be stored on computer readable medium, and this computer readable medium can be for example hard disk drive, flash memory device, random access memory (RAM), magnetic tape or any other such medium for storing data.

[0139] In practice, a module of executable code may be a single instruction or multiple instructions, and may even be distributed over multiple different code segments, between different programs, and between several storage devices. Similarly, operational data may be identified and illustrated herein as being within a module, and may be embodied in any suitable form and may be 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 different storage devices, and may exist at least in part only as electronic signals on a system or network.

[0140] It will be readily understood that, as generally described and illustrated in the drawings herein, the components of the present application may be arranged and designed in a 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.

[0141] Those skilled in the art will readily appreciate that the above content can be practiced with steps in different orders and / or with hardware elements in configurations different from the disclosed configurations. Therefore, although the present application has been described based on these preferred embodiments, it is clear to those skilled in the art that some modifications, variations and alternative configurations will be clear.

[0142] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely exemplary and that the scope of the present application is limited solely by the appended claims when considering all equivalents and modifications thereof (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A computing system comprising: A network interface configured to transmit a request for web page content to a network server, and receive a hypertext markup language HTML template file of the web page with a content delivery network CDN address for the content of the web page; as well as a processor configured to determine whether to obtain the CDN content from the blockchain based on the blockchain query and the CDN address, and in response to determining to obtain the CDN content from the blockchain, retrieve the CDN content from the blockchain based on the CDN address, and display the webpage at the client device based on the HTML boilerplate and the CDN content retrieved from the blockchain, The CDN content is stored by the blockchain in an off-chain storage device of the blockchain, and the blockchain maintains metadata of the CDN content.

2. The computing system of claim 1 , wherein the processor is further configured to, in response to a query response from the blockchain indicating that the CDN content is stored at the blockchain, retrieve the CDN content from the blockchain instead of the CDN server identified by the CDN address. 3 . The computing system of claim 1 , wherein the retrieved CDN content comprises Hypertext Transfer Protocol Secure (HTTPS) content.

4. The computing system of claim 1 , wherein the processor is further configured to: determining a trust level of a blockchain peer based on at least one of votes and weights provided by a plurality of clients of the blockchain, and Responsive to a determination that the trust level satisfies a predetermined threshold, retrieving the CDN content from the blockchain peer.

5. The computing system of claim 1 , wherein the processor is configured to query the blockchain for the CDN content based on a uniform resource locator (URL) of a CDN content source of the CDN content.

6. The computing system of claim 1 , wherein the CDN content is retrieved from a distributed ledger managed locally by the client device.

7. The computing system of claim 1 , wherein the CDN content is cached by the blockchain in response to a previous access to the CDN content by another client device.

8. A method comprising: Transmitting a request for web page content to a web server; Receiving a hypertext markup language HTML template file of the webpage with a CDN address of a content delivery network CDN content for the webpage; Determining whether to obtain the CDN content from the blockchain based on the blockchain query and the CDN address; In response to determining to obtain the CDN content from the blockchain, retrieving the CDN content from the blockchain based on the CDN address; as well as displaying the webpage at a client device based on the HTML boilerplate and the CDN content retrieved from the blockchain, The CDN content is stored by the blockchain in an off-chain storage device of the blockchain, and the blockchain maintains metadata of the CDN content.

9. The method of claim 8, wherein the method further comprises, in response to a query response from the blockchain indicating that the CDN content is stored at the blockchain, determining to retrieve the CDN content from the blockchain instead of the CDN server identified by the CDN address.

10. The method of claim 8, wherein the retrieved CDN content comprises Hypertext Transfer Protocol Secure (HTTPS) content.

11. The method according to claim 8, wherein the method further comprises: determining a trust level of a blockchain peer based on at least one of votes and weights provided by a plurality of clients of the blockchain; as well as Responsive to a determination that the trust level satisfies a predetermined threshold, retrieving the CDN content from the blockchain peer.

12. The method of claim 8, wherein the retrieving comprises querying the blockchain for the CDN content based on a uniform resource locator (URL) of a CDN content source of the CDN content.

13. The method of claim 8, wherein the CDN content is retrieved from a distributed ledger managed locally by the client device.

14. The method of claim 8, wherein the CDN content is cached by the blockchain in response to a previous access to the CDN content by another client device.

15. A non-transitory computer readable medium comprising instructions which, when read by a processor, cause the processor to perform a method comprising the steps of any one of claims 8 to 14.

16. A computer system comprising modules configured to perform the steps of the method according to any one of claims 8 to 14.

Images