Patent Application
20190386968
Some embodiments disclosed herein relate to compute transactions and, more particularly, to blockchain enabled securely brokered trusted distributed compute transactions.
A device or application may want to perform a task that involves a set of compute transactions. For example, an image sensor might want to analyze a stream of images in connection with an image recognition algorithm. The device or application, however, might not have the compute resources (Central Processing Unit (“CPU”) speed, bandwidth, memory, bandwidth, etc.) locally available to perform that particular set of compute transactions. Note that there may be a substantial number compute cycles available on edge devices (Personal Computers (“PCs”), smartphones, robots, autonomous vehicles, etc.). With sufficiently high bandwidth connectivity and resource availability, the set of compute tasks might be shared between edge devices when an original requesting device is not able to handle the work. Note that the edge devices might be either physically located at the same facility (e.g., a local network) or separated around the globe. Note that various scenarios may be associated with unique problems about how to manage resource visibility, privacy (e.g., an edge device might not want to identify itself to a central authority that manages the distribution of tasks), latency, trust, etc.
It would therefore be desirable to provide systems and methods to efficiently and securely broker trusted distributed compute transactions.
According to some embodiments, an edge device may receive, via a secure, distributed transaction ledger (e.g., associated with blockchain technology), information about a task contract published by a publisher device including an indication of a benefit and encryption information. The edge device may evaluate the received information in accordance with resources locally available at the edge device, and, responsive to said evaluation, transmit to the secure, distributed transaction ledger an indication of acceptance of the published task contract. According to some embodiments, the edge device may execute the published task contract, and, upon completion, arrange to receive the benefit associated with the published task contract.
Some embodiments comprise: means for receiving, at an edge device computer processor from a secure, distributed transaction ledger, information about a task contract published by a publisher device including an indication of a benefit and encryption information; means for evaluating the received information in accordance with resources locally available at the edge device; and, responsive to said evaluation, means for transmitting to the secure, distributed transaction ledger an indication of acceptance of the published task contract.
Some embodiments comprise: means for transmitting, via a secure, distributed transaction ledger, information about a task contract published by a publisher device including an indication of a benefit and encryption information; means for receiving from an edge device via the secure, distributed transaction ledger an indication of acceptance of the published task contract; and, upon completion of the published task contract, means for arranging to provide the benefit to the edge device.
Technical effects of some embodiments of the invention are improved ways to efficiently and securely broker trusted distributed compute transactions. With these and other advantages and features that will become hereinafter apparent, a more complete understanding of the nature of the invention can be obtained by referring to the following detailed description and to the drawings appended hereto.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.
One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
A device might want to have compute transactions executed (e.g., associated with an Artificial Intelligence (“AI”) algorithm) but not have the compute resources available to perform the task. To solve such a problem, a system 100 includes a number of edge devices 110 each having a communication port to exchange information via a network 102 (e.g., the Internet). Similarly, a publisher device 120 may have a communication port to exchange information with the edge devices 110.
According to some embodiments, the edge device 110 and/or publisher device 120 record data in a secure, distributed transaction ledger 190. For example, the publisher device 120 might publish or post information about a compute task that it like to have performed via the secure, distributed transaction ledger 190 in accordance with any of the embodiments described herein. The transaction ledger 190 might be associated with, for example, blockchain technology that can be verified via a remote operator or administrator device. According to some embodiments, the distributed transaction ledger might be associated with the HYPERLEDGER® blockchain verification system. Note that the devices 110, 120 could be completely de-centralized and/or might be associated with a third party, such as a vendor that performs a service for an enterprise.
The edge device 110 and/or publisher device 120 might be, for example, associated with a PC, laptop computer, a tablet computer, a smartphone, an enterprise server, a server farm, and/or a database or other storage devices. According to some embodiments, an “automated” edge device 110 may automatically read and/or record information in the transaction ledger 190 via a blockchain verification process. As used herein, the term “automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.
As used herein, devices, including those associated with the edge device 110 and any other device described herein, may exchange information via any communication network 102 which may be one or more of a Local Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
The devices 110, 120 may store information into and/or retrieve information from data stores. The data stores might, for example, store electronic records representing compute tasks and contracts, compute resource requirements, payment details, etc. The data stores may be locally stored or reside remote from the devices 110, 120. Although a single publisher device 120 is shown in
Note that the system 100 of
At S210, an edge device computer processor may receive, from a secure, distributed transaction ledger, information about a “task contract” published by a publisher device (that is, a device that wants a task performed but is unable to do so itself). As used, herein, the phrase “task contract” might refer to, for example, a compute transaction task, such as a series of algorithms associated with artificial intelligence, image recognition, etc. As another example, a task contract might be associated with a physical task to be performed by one or more automated devices (e.g., one robot might weigh an item to be moved, another robot might then move the item from a first location to a second location, etc.). According to some embodiments a single task contract might include both compute transactions and physical tasks. The received information may include, for example, an indication of a benefit (e.g., a payment to be made in exchange for performing the task) and encryption information. According to some embodiments, the received information may further include an indication of at least one resource requirement associated with a compute transaction task (e.g., an amount of memory, CPU speed, etc.). The edge device might be associated with, for example, a PC, a tablet computer, a smartphone, a robot, a vehicle, an autonomous vehicle, a set-top box, etc. According to some embodiments, the secure, distributed transaction ledger comprises blockchain technology that is controlled by a single, centralized entity or by multiple, distributed entities. The received information about the published task contract might further includes, for example, a high-level task description, a deadline, a processing speed requirement, a computer memory requirement, an acceptance payment requirement, etc. Note that the information about the published task contract might be received via a subscription model (that is, the edge device might subscribe to receive such posts from the transaction ledger). As described with respect to
At S220, the received information may be evaluated in accordance with resources locally available at the edge device. For example, the edge device might determine if it capable of performing the task by the deadline, if the amount of payment is sufficient, etc. At S230, responsive to said evaluation, the edge device may transmit to the secure, distributed transaction ledger an indication of acceptance of the published task contract. According to some embodiments, the indication of acceptance transmitted to the secure, distributed transaction ledger includes a small payment (e.g., the payment may block other edge devices from agreeing to perform the same task). According to some embodiments, an edge device might simply ignore a task contract if it will not be accepted (that is, an explicit “decline” message from an edge device might not be required).
The edge device may then execute physical tasks and/or compute transactions associated with the published task contract. Upon completion of execution of the compute transactions, for example, the edge device may arrange to receive the benefit associated with the published task contract. Note that an edge device might receive information about a plurality of published task contracts and evaluation of one published task contract may be based, at least in part, on information about another published task contact. For example, the edge device might select a task contact associated with the highest payment for performing the task.
Thus, blockchain may be used to enable a secure brokering of distributed compute transactions. In this way, embodiments may allow for a formalized connection between devices that were not previously set up to talk to each other (that is, no formal network protocol was previously agreed upon by the edge and publisher devices).
Thus, embodiments may provide secure blockchain enabled brokerage of distributed compute transactions.
Thus, embodiments may let publisher and edge devices 620, 610 communicate the availability of tasks or resources in a trusted way without a central authority. Embodiments may use blockchain technology to develop a secure and trusted way for devices that have not previously communicated (i.e., “stranger” devices) to broker transactions (as described in connection with
Note that a blockchain contract may define a set of functions providing a “task-board” where a substantial number of edge devices can publish, subscribe, and purchase tasks. Digital currency may be provided as payment for the completion of a task. This money may be kept in “escrow” by the contract until the task is completed (or the task is canceled).
A device, as a publisher, may add a task with payment to the blockchain contract. This function may include a high-level task info, resources required, difficulty, and a public key for the device. When the task is purchased, the publisher device 620 may receive a public key of the edge device 610 purchaser from the blockchain contract. An edge device 610, as a subscriber, can subscribe to the task-board and see any tasks that have been posted. To buy a task and lock it out in the contract (so no one other devices can work on it), the edge device 610 might pay a small purchase fee. The purchaser edge device 610 may provide a public key to the contract along with the payment for a task. In return, the edge device 610 may receive the public key and IP address of the publisher device 620. This key can be used, according to some embodiments, to encrypt data exchanged between the publisher device 620 and the edge device 610 to start the task. Using the exchanged public keys though the blockchain contract, the two devices 610, 620 (who previously did not know each other) are now able to trust each other and communicate securely. After the task has been performed (and the result provided), both devices 610, 620 may acknowledge via the blockchain contact that the task is complete. The contract may then release the funds and pay the purchaser edge device 610.
Embodiments described herein may comprise a tool to help broker secure, distributed compute transactions and may be implemented using any number of different hardware configurations. For example,
The processor 910 also communicates with a storage device 930. The storage device 930 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 930 stores a program 912 and a transaction processing engine for controlling the processor 910. The processor 910 performs instructions of the programs 912, 914, and thereby operates in accordance with any of the embodiments described herein. When the processor 910 is associated with an edge device, for example, it may receive, via a secure, distributed transaction ledger (e.g., associated with blockchain technology), information about a task contract published by a publisher device including an indication of a benefit and encryption information. The processor 910 may evaluate the received information in accordance with resources locally available at the edge device, and, responsive to said evaluation, transmit to the secure, distributed transaction ledger an indication of acceptance of the published task contract. According to some embodiments, the processor 910 may execute the published task contract, and, upon completion, arrange to receive the benefit associated with the published task contract. Similarly, when the processor 910 is associated with a publisher device (instead of an edge device), it may publish task contracts, receive task results, facilitate payments, etc.
The program 912 may be stored in a compressed, compiled, uncompiled and/or encrypted format. The program 912 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 910 to interface with peripheral devices.
As used herein, information may be “received” by or “transmitted” to, for example: (i) the platform 900 from another device; or (ii) a software application or module within the platform 900 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to
The task contract identifier 1002 may be, for example, a unique alphanumeric code identifying a task that a publisher device wants to have executed. The task description 1004 may provide a high-level overview of the task and the resource requirements 1006 might specify the compute resources that are needed to perform compute transactions of the task (e.g., CPU speed, bandwidth, memory usage, etc.). The payment 1008 might indicate a benefit that an edge device will receive when the task is complement. The due date and time 1010 may comprise a deadline by when the task must be complete, a turn-around requirement, etc. The status 1012 might indicate fi the task was accepted, declined, completed, canceled, etc. The indication 1014 might specify whether or not a task event was recorded via a blockchain transaction ledger.
Note that keys must be trusted by each relying party to be of value (for example, a publisher must believe the subscriber's key is really associated with that subscriber and therefore the data signed by the subscriber's key). Normally, this is done by having a mutually trusted entity (called a “Certification Authority”) sign a certificate which states that the associated key is trusted. The owner of the key may then use the key to sign information and pass the information to a relying party along with key's signed certificate. The relying party may verify that the certificate is signed by the mutually trusted entity then verify the data. The signing party (e.g., the subscriber) would typically re-use the key again for a different transaction. This, however, might violate the anonymity principles associated with blockchain because someone observing the traffic could detect that two transactions were performed by the same entity.
To solve this, an entity (for example a subscriber) may create a key that is trusted (by having the certificate signed) by a commonly trusted entity (for example, a server managing contracts). That key is referred to herein as the “CertifyingKey.” When a transaction is agreed upon, the subscriber creates a new ephemeral key called the “XactionKey.” Using a device such as a TPM 1150 (or other hardware token), the subscriber uses the CertifyKey to sign the properties of the XactionKey creating “CertifyInfo.” This may be an internal operation and therefore trusted by the server managing the contracts. The public portion of the XactionKey may be sent along with the CertifyInfo to the server managing the contract. As the server trusts that the CertifyingKey will not produce CertifyInfo for a key which is not within the same device as the XactionKey, the server then signs a XactionKey certificate using its mutually trusted public key. Because the publisher trusts the mutually trusted public key, it can now trust that the XactionKey is bound to the subscriber.
During the above protocol, the binding of the negation steps with the XactionKey may be done by signing critical portions of the negotiation using the CertifyingKey (which is prior to its certification but once trust is established the binding can be proven). Other methods might include, for example, critical portions of the negotiations with the key generation process to the key's internal data which would be included in the CertifyInfo. Note that a new XactionKey and, therefore, new certification process, may be performed for each negation and transaction. That is, the XactionKey may be a “single use” or ephemeral key that will not let others determine task contracts that were performed by the same edge device. Thus, according to some embodiments, a publisher device public key may be associated with the publisher device and the publisher device public key, optionally along with information about the publisher device public key, may be signed by a certifying key trusted by the edge device. The publisher device public key may then be used to sign or encrypt transaction information (e.g., information about the task contract). Similarly, an edge device public key may be associated with the edge device and the edge device public key, optionally along with information about the edge device public key, may be signed by the certifying key trusted by the publisher device. The edge device public key may then be used to sign or encrypt transaction information (e.g., information about the task contract). Alternatively, key technologies such as Anonymous or Group signing keys can be used (in the TPM 1150 this is called Direct Anonymous Attestation (“DAA”)). In that case, a single group public key is bound to many private keys (e.g., over 50,000 private keys). Each signature is unique even when performed by the same key, and therefore traffic analysis will not be able to associate two transactions that came from the same subscriber. Here, the same XactionKey may be used (which can save the time needed to create a new XactionKey for each contract as in the other approach).
Embodiments may be associated with any type of distributed transaction ledger having a de-centralized consensus-based network that supports smart contracts, digital assets, record repositories, and/or cryptographic security. For example,
Thus, embodiments may provide a way for devices to publish, subscribe, and/or purchase tasks without using a centralized authority. The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.
Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., some of the information described herein may be combined or stored in external systems). Moreover, although embodiments have been described with respect to transaction information processing system, note that embodiments might be associated with other types of processing systems in general. Similarly, the configurations shown and described herein are provided only as examples, and other types of configurations, including display devices may support any of the embodiments. For example,
The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.
