WO2019126385A1

WO2019126385A1 - Method and system for a proof of stake oracle

Info

Publication number: WO2019126385A1
Application number: PCT/US2018/066597
Authority: WO
Inventors: Kurosh Santos KHAJVANDI; Monis Rahman
Original assignee: Mochi, Inc.
Priority date: 2017-12-19
Filing date: 2018-12-19
Publication date: 2019-06-27

Abstract

A method of executing a digital smart contract includes receiving a stake of predetermined value from an oracle. After receiving the stake from the oracle, a first data set originating from a data source is received from the oracle. Whether the first data set includes a second data set authenticating the first data set and provided by the data source is determined. If the first data set includes the second data set, the stake is returned to the oracle. If the first data set does not include the second data set, the stake is retained.

Description

METHOD AND SYSTEM FOR A PROOF OF STAKE ORACLE

PRIORITY CLAIM

[1] The present application claims priority to U.S. Prov. Pat. Appl. No. 62/607,818 filed December 19, 2017, the contents of which are hereby incorporated by reference as if fully set forth herein.

BACKGROUND

[2] Blockchain is ignorant of real-world data. Blockchain is a walled garden with no access to outside data. Everything from property ownership to financial instruments to family arrangements can now be implemented as a piece of code on a publicly verifiable shared ledger known as a blockchain. This code is "smart" in many ways: it is self executing, modular, and able to drastically lower the transaction costs associated with contracts. However, it is less adept in its ability to receive and verify information from the outside world. For example, an insurance contract can be programmed to pay a car owner some amount if their car is damaged, but it cannot independently assess such damage.

[3] Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. The most interesting use cases require data from the outside world. This limits smart contract use cases.

[4] An oracle, in the context of blockchains and smart contracts, is an agent that finds and verifies real-world occurrences and submits this information to a blockchain to be used by smart contracts. Blockchains cannot access data outside their network. An oracle is a data feed provided by a third-party service - designed for use in smart contracts on the blockchain. Oracles provide external data and trigger smart contract executions when pre defined conditions are met. Such condition could be any data like weather temperature, successful payment, price fluctuations, etc.

[5] The original blockchain was designed with trust as being unnecessary. Additionally, any data consumed by a smart contract on a public blockchain was public and anyone, anywhere would be able to view or use it. As such, there are two major issues that must be overcome: oracle trust and the oracle free rider problem.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[6] The details of the present invention, both as to its structure and operation, can best be understood by referring to the accompanying drawings, in which, where applicable, like reference numbers and designations refer to like elements.

[7] FIG. 1 is a graphical illustration of oracle functionality according to an embodiment;

[8] FIG. 2 is a graphical illustration of uses of a proof of stake oracle according to an embodiment;

[9] FIG. 3 illustrates an exemplary oracle quality rating according to an embodiment;

[10] FIGS. 4-6 illustrates arbitration of a smart contract according to an embodiment;

[11] FIG. 7 illustrates a centralized oracle arbitration;

[12] FIG. 8 illustrates multiparty oracle arbitration; and

[13] FIGS. 9-10 illustrates a tiered federated byzantine agreement according to an embodiment.

DETAILED DESCRIPTION

[14] This patent application is intended to describe one or more embodiments of the present invention. It is to be understood that the use of absolute terms, such as“must,” “will,” and the like, as well as specific quantities, is to be construed as being applicable to one or more of such embodiments, but not necessarily to all such embodiments. As such, embodiments of the invention may omit, or include a modification of, one or more features or functionalities described in the context of such absolute terms.

[15] Embodiments of the present invention may comprise or utilize a special- purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer-readable medium, (e.g., a memory, etc.), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein.

[16] Computer-readable media can be any available media that can be accessed by a general purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.

[17] Non-transitory computer-readable storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSDs") (e.g., based on RAM), Flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special-purpose computer.

[18] A "network" is defined as one or more data links that enable the transport of electronic data between computer systems or modules or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special-purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

[19] Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM or to less volatile computer storage media (devices) at a computer system. Thus, it should be understood that non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.

[20] Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general-purpose computer, special- purpose computer, or special-purpose processing device to perform a certain function or group of functions. In some embodiments, computer-executable instructions are executed on a general-purpose computer to turn the general-purpose computer into a special-purpose computer implementing elements of the invention. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.

[21] According to one or more embodiments, the combination of software or computer-executable instructions with a computer-readable medium results in the creation of a machine or apparatus. Similarly, the execution of software or computer-executable instructions by a processing device results in the creation of a machine or apparatus, which may be distinguishable from the processing device, itself, according to an embodiment.

[22] Correspondingly, it is to be understood that a computer-readable medium is transformed by storing software or computer-executable instructions thereon. Likewise, a processing device is transformed in the course of executing software or computer-executable instructions. Additionally, it is to be understood that a first set of data input to a processing device during, or otherwise in association with, the execution of software or computer- executable instructions by the processing device is transformed into a second set of data as a consequence of such execution. This second data set may subsequently be stored, displayed, or otherwise communicated. Such transformation, alluded to in each of the above examples, may be a consequence of, or otherwise involve, the physical alteration of portions of a computer-readable medium. Such transformation, alluded to in each of the above examples, may also be a consequence of, or otherwise involve, the physical alteration of, for example, the states of registers and/or counters associated with a processing device during execution of software or computer-executable instructions by the processing device. [23] As used herein, a process that is performed“automatically” may mean that the process is performed as a result of machine-executed instructions and does not, other than the establishment of user preferences, require manual effort.

[24] The present oracles according to at least one embodiment address the gap between the world of blockchain code and real-world events. An oracle, in the context of blockchains and smart contracts, is an agent that finds and verifies real world occurrences and submits this information to a blockchain to be used by smart contracts. Aspects of this agent can be software, hardware, human or a combination of two or more of the same.

[25] Uses of the present proof of stake oracle protocol according to at least one embodiment, and as illustrated in FIG. 2, include:

[26] Verification of Bank & Retail Payments:“Did Alice deposit the money?”

[27] Web APIs

[28] Market Data:“What price is Alibaba stock right now?”

[29] IoT Sensor data:“What is the temperature in Beijing today?”

[30] Real World Events:“Did Hillary get elected president?”“Did the package get delivered?”

[31] Coordinating Supply Chain?

[32] Smart contracts process data automatically. Oracles are important for automating data processing on blockchain. This may all be done without any human intervention. As Bitcoin nodes cannot measure arbitrary conditions, users must rely on an oracle. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.

[33] An oracle according to an embodiment functions as illustrated in FIG. 1. Step 1 : Smart contract chooses an oracle. This choice-making requires the smart contract to trust the oracles to deliver actual data on time and accurately /honestly from a source.

[34] Step 2: The oracle fetches data from a data source and transmits to the smart contract on the blockchain.

[35] Step 3: The smart contract consumes the data and then resolves the contract. It may also evaluate the data provided.

[36] Oracle Free-Rider Problem: [37] Any data that is consumed on a public blockchain became public and accessible to everyone. This led to bootleg oracles that copied this data and provided it to other smart contracts. Bootleg oracles have the same accuracy but much lower costs. This destroys any incentive the original oracle has to do the hard work of getting actual data from the actual source honestly onto blockchain.

[38] The solution for this is that the data may just be consumed off-blockchain or on a private/permissioned blockchain. Data that is trivially consumed and is only valuable once, like payment receipts, may be consumed on public blockchain. Data must be provided off-blockchain, on a private or permissioned blockchain or a side-chain with governance.

[39] Centralized Data Provider

[40] When there is a single source of data (e.g. NASDAQ provides market data; FEC certifies election winners, etc), you have to go to the source to verify the data (e.g., NASDAQ, the Federal Election Commission). The source data may be easily accessible but it needs to be provided into the blockchain honestly. Data therefore may be digitally signed to be authenticated. The correct data is signed by the oracle and submitted to the blockchain. This may be accomplished as follows:

[41] An oracle according to an embodiment provides data from a centralized source.

[42] 1 : oracle stakes some coins (Mobi).

[43] 2 : If the signed data provided is authenticated, the oracle gets paid.

[44] 3: If authentication fails it loses its stake.

[45] The data is given to the smart contract along with authenticity proof, which serves as a cryptographic guarantee proving that such data was not tampered with.

[46] As illustrated in FIG. 3, a marketplace for oracles according to an embodiment provides a quality rating for each oracle.

[47] Even if one can prevent bootlegging, some oracles will provide bad data while claiming they are providing high quality data. This is a huge problem in the absence of trust. If quality is difficult to ascertain due to information asymmetry, then lower quality oracles will seek to masquerade as higher quality oracles. Smart contracts will take this adverse incentive into consideration and assume that the quality of oracles as a whole is uncertain. Smart contracts would then only pay mobius considering the overall average quality of oracles. Thus, in case the market fails to distinguish between higher and lower quality oracles, this leads to the higher quality oracles being underpaid and driven out of the market. To overcome this issue one can have segmented auctions where only oracles above a predefined quality threshold would be allowed to participate.

[48] Oracle Transaction with Staking

[49] According to one embodiment, and as illustrated in FIGS. 4-6 a smart contract wants to buy data from an oracle. As illustrated in FIG. 4, the smart contract and oracle settle on $100 for the data with $10 stakes. The stakes and transactions are in digital coins.

[50] Trade is ideally settled at $100 net. But other cases may apply. In case of a Time Out: $100 returned, the stake goes to staking pool. Or if there is Mutual Cancellation: All amounts returned to original funders. In case of dispute, and as further discussed below, arbitration may occur. According to one embodiment, arbitration moves real world data on to blockchain and so the arbitrators are also oracles.

ARBITRATION ON BLOCKCHAIN

[51] Referring to FIGS. 7-9, note that the blockchain world is a trustless environment. A dispute may occur between an oracle and a data buyer who signs an agreement. Such an arrangement can be between two computer programs. In this case, the data provider and the data consumer. The one providing data is the oracle. The seller in this case is the oracle. The data buyer is another computer program (i.e.. smart contract, algorithm, etc.)

[52] The dispute is about money, fidelity of the data, or quality of the data. There are different dispute scenarios: The oracle does its job but the data consumer does not want to pay for any reason and/or no reason at all. In case of a dispute: if the transaction is for 1000 coins, the problem reduces to essentially who bribes the arbitrator first. If the minimum increment is 1 coin, the end result will be that the arbiter gets 999 coins and one of the participants will get 1 coin. Such is the case because the arbiter must resolve the dispute, if not all money is stuck in escrow. This environment is entirely trustless. All the power is in the arbiter’s hand. This represents a single point of failure. The centralized arbitrator may be hacked before getting bribed. [53] As will be discussed in greater detail herein, a Tiered Federated Byzantine Agreement (FBA) is useful here because it introduces a decentralized arbitration consensus protocol - so there are generally multiple arbiters. The arbiter(s) will make their decision in a manner that maximizes each of their own respective money. Whoever pays more to the arbiters wins. However, there is a system of ranking oracles and arbiters based largely on reputation known as tiers (i.e., age, number of trusted nodes associated with it, number of transactions, etc.).

[54] A single central arbiter may be replaced with multiple arbiters which vote to come to a decision. A quorum may be implemented for voting to be considered as valid. Most importantly in this case the data transmission to blockchain problem is an arbitration consensus problem. This solves the issue of having a single point of failure. Oracle/arbiters may be bribed. This leads to collusion.

[55] According to one embodiment, a tiered federated byzantine agreement (FBA) system improves the trust of the present oracles. Tiered FBA represents a bridge of trust between transacting parties. All transacting parties choose some trusted arbiters, based on these choices quorum slices are filled to achieve a quorum that can come to decisions in case of any dispute. The quorum usually represents all the stake holders. These are templated in advance depending on the transaction. Tiers introduce ranking of arbiters and oracles to reduce the risk of rogue agents. This creates a reputation-based marketplace. Ranking can be determined based on important factors like: age, transaction history, number of nodes, etc. The transacting parties choose a few oracles they trust. There are rules that apply to what oracles the end user must choose. These are designed to lower the amount of trust required and build a quorum that can come to a consensus. For example, you have to choose at least two from the top tier (A1-A6) and three from a lower tier (A7-A9 & A10-A11).

[56] A quorum of oracles (or arbiters) is a set sufficient to reach an agreement. Such an agreement may be based on whether the data is good or not, on whether the transaction goes through or not, on whether events actually occurred or not, etc. Since there is no master authority deciding on which oracles get to participate in a consensus, the network’s structure inherently allows for growing decentralization. As more and more oracles are added to the network more and more quorum slices form. To summarize, quorum slices allow for open membership. A slice is the subset of a quorum convincing one particular oracle of agreement. [57] Oracles belong to different tiers (with different weights) and slices. Weights may be determined based on, for example, oracle transaction history, age, number of data buyers that include the oracle and/or arbiter(s) on its list of validators, number of successful transactions, number of disputes, amount of MOBI or other coin or cryptographic token staked at any given time, etc. Oracles and arbiters are listed in the same market of competing oracles. In a Tiered Federated Byzantine Agreement (FBA), there is no recommended oracle/arbiter list chosen by a central authority. Rather, each programmatic data buyer (i.e., smart contract) decides which oracle(s) and arbiter(s) to trust. A buyer’s list of trusted arbiters/oracles, no matter the tier position, is their quorum slice. The quorum slices of different buyers overlap to form different quorums or network-wide consensus on a data transaction without the need for one centralized authority or arbiter.

[58] Both oracles and arbiters compete to maximize value. Oracles can provide fake, incorrect, correct, or no data to a data buyer. An arbiter can be bribed or judge fairly. Ultimately, in the network there are many participants of these agents. Over, the long run more participants for data sellers (oracles) creates competition for ones that have a good track record of transactions and the least number of disputes. Arbiters will also face the same situation. It’s an open network; anyone can become an oracle or arbiter in case there is a disagreement and participate in consensus.

[59] End users have the ability to choose whom they trust. Each participant independently selects a set of oracles to trust. Other oracles are automatically selected to fulfill a quorum. There is no single party staking, but a large number of smaller stakes. There can be multiple oracles and buyers involved in business dealings.

[60] Both parties, buyer and seller in the simplest example, need to stake MOBI (or another other cryptographic token) in escrow in order to buy and sell data and participate in the data marketplace. This means oracles and data buyers alike need to own and use MOBI and put it in escrow as a form of transaction insurance until the transaction is successfully settled. Once the transaction is successfully settled the MOBI (or any other cryptographic token for that matter) is returned to both buyer(s) and seller(s). However, if there is arbitration the MOBI that is staked in escrow by both parties (or multiple parties) will remain in place until a consensus is reached by a decentralized arbitration protocol. Here, arbiters evaluate the dispute and charge MOBI token. The losing party loses MOBI to the other harmed market participants and payment to the oracle. All money is returned to the non-harmed party minus fees from the network and arbiters. Payoffs from cheating are lower than the cumulative stake.

[61] Referring to FIG. 10, oracles may ratify a chain of events or statements made by the oracles. These statements could be data such as the price of gold at a particular time, temperature reading of a sensor from a crop, GPS location of a particular device, etc. Each oracle may only ratify statements consistent with its past statements. This allows for the coordination of a chain of events. Suppose we want to ship some goods from Supplier to Buyer. A top tier oracle may include a shipping logistics coordinator. Lower tier oracles include the port authority, air cargo company, even smart trucks relaying GPS tracking data.

[62] Consider an example where firm A from the semiconductor industry where a California-based design firm buys some OEM components from Applied Materials, to be shipped to TSMC foundry where they are processed and shipped to the buyer Firm B who is based in Beijing.

[63] In the illustrated embodiment, TSMC and Applied Materials would be trusted by the Firm A and FedEx and other shipping providers are trusted by firm B.

[64] Essentially the banks in the transaction, e.g., Citibank, and Insurance provider (Munich RE) and other public institutions are trusted by both parties. This allows one to create a localized trust-based quorum and coordinate the supply chain between these two parties. This is essentially a quorum slice. It’s a bridge of trust between transacting parties. A quorum occurs when a set of nodes can reach agreement with no problem. A quorum slice is a subset of that quorum that can convince one node (programmatic data buyer— smart contract) about agreement— e.g., agreement can be something like if the data is good, the price of gold hit $1,245 on a certain time, etc. A chain of events is thusly coordinated.

[65] Each step in the process is tracked and recorded on blockchain using the present proof of stake oracle protocol. The physical flow of goods between parties, the transfer of ownership of the components and the stream of forecast data can all be tracked in a synchronized manner. Both data seller and data buyer must effectively“stake” MOBI or any other cryptographic token. If their reputation is higher they can stake fewer MOBI. If there is a dispute, the losing party loses MOBI. If there is no dispute, the staked MOBI in escrow goes back to the corresponding buyers and sellers of data. There can be multiple parities in a transaction, one in which you can have multiple data buyers approaching the same highly trusted oracle for data.

[66] This is a complex supply chain coordination example using Tiered FBA for arbitration. Each party and others (completing the quorum) are represented in the diagram. For example, if the product is lost at sea, then the shipping or insurance is at fault. The system of arbitration will find out the party responsible and they will be charged. The system is designed with the payments as per the smart contract and transaction insurance in Mobius (MOBI) or some other cryptographic token. So, in case of failure, the party(s) that is (are) responsible are charged their staked MOBI.

[67] While the present disclosure has been described in terms of particular embodiments and applications, summarized form, it is not intended that these descriptions in any way limit its scope to any such embodiments and applications, and it will be understood that many substitutions, changes and variations in the described embodiments, applications and details of the method and system illustrated herein and of their operation can be made by those skilled in the art without departing from the scope of the present disclosure.

Claims

What is claimed is:

1. A method of executing a digital smart contract, comprising the steps of: receiving a stake of predetermined value from an oracle; after receiving the stake from the oracle, receiving from the oracle a first data set originating from a data source; determining whether the first data set includes a second data set authenticating the first data set and provided by the data source; if the first data set includes the second data set, returning the stake to the oracle; and if the first data set does not include the second data set, retaining the stake.

2. The method of claim 1, wherein the oracle combines the second data set with the first data set.

3. The method of claim 1, wherein a level of compensation is set for the oracle to provide the first data set to the smart contract; if the first data set includes the second data set, the oracle receives the compensation; and if the first data set does not include the second data set, the oracle does not receive the compensation.

4. The method of claim 1, wherein the first data set comprises financial market data.

5. A system for arbitrating disputes involving a digital smart contract between first and second parties over a network, comprising: a smart contract resolution element; at least one set of top-tier arbiter elements coupled to the resolution element; at least one set of lower-tier arbiter elements coupled to the resolution element and the at least one set of top-tier arbiter elements, wherein each arbiter element contributes to the resolution element a stake of predetermined value.

6. The system of claim 5, wherein at least one of the top-tier arbiter elements is selected by both the first and second parties as being a trusted element.

7. The system of claim 5, wherein at least one of the lower tier arbiter elements is selected by only one of the first and second parties as being a trusted element.

8. The system of claim 5, wherein the arbiters comprise oracles.