Decentralised Oracles: a comprehensive overview
After bringing smart contracts to the world, the world must be brought to smart contracts
I want to thank my team at Fabric Ventures, Joey Krug (Core Dev, Augur), Thomas Bertani (Founder, Oraclize), Hugh Karp (Founder, Nexus Mutual), James Ryan Moreau (Technical Community Lead, Witnet), Gorka Irazoqui Apecechea (Researcher, Witnet), Szymon Sypniewicz (co-founder, Ramp) and Przemysław Kowalczyk (co-founder, Ramp) for their valuable feedback.
Distributed Ledgers and Smart Contracts will bring unprecedented innovation by further removing trust-related friction in human interactions, but until these Smart Contracts can trustlessly take off-chain inputs, the innovation will be limited. Decentralised Oracles are gateways for smart contracts to interact with the outside world whilst limiting reliance on single source of truths, which will bring another wave of exciting innovation.
This post will aim to give a good introduction on:
- Why oracle services are vital components of the decentralised stack,
- The need for trustless services,
- The various challenges and attack vectors of oracles,
- An overview of 8 projects working on these issues
I. Why do we need Oracles?
Smart contracts on permissionless blockchain (e.g. Ethereum, Dfinity) execute in an adversarial environment where safety is guaranteed by only propagating deterministic transactions, i.e. transactions which can be verified by all nodes. A smart contract is designed to receive an input → execute a logic → update the blockchain state accordingly, and it does so irreversibly ; there is no Ctlr+Z in the blockchain world.
Allowing smart contracts to take inputs from outside its blockchain is a double-edged sword ; it increases the use cases exponentially by allowing interactions with the external world, but it also introduces an element of trust. The miners on a permissionless blockchain cannot deterministically verify all external inputs, and will therefore allow execution of anything which matches the predefined criterias of the smart contract.
Let’s take a very simple example: a smart contract allowing Alice and Bob to bet on the price of one Bitcoin on 3 January 2019 at 2 PM London time. Alice & Bob each deposit 1 ETH in escrow in this smart contract; Alice receives 2 ETH if Bitcoin is above $4,200, else Bob receives the 2 ETH. The smart contract has no notion of the price of one Bitcoin, so we must find a way to ensure only the correct price is reported, especially since the outcome of the bet is irreversible once settled. For that purpose, we need oracles.
An oracle is an entity which signs claims about the state of the world. For example, an oracle might report the price of BTC/USD on Coinbase on 3rd January or the 2019 European Champions’ League winner. The information may be retrieved or aggregated from one or multiple trusted sources by one or multiple oracles.
Before diving into the various technical challenges of trustless oracles, we would like to put forward 5 key use cases we foresee for oracle-powered smart contracts.
Financial Products
Smart contracts are a perfect fit for many financial products: interest rates swaps, cash-settled put option, decentralised leverage trading. All of them require trustless data feeds to ensure appropriate on-chain execution.
Example of projects that can or already do leverage such oracles for financial products: CDx, dYdX, MakerDAO, Vega Protocol, 0x protocol.
Insurance Smart Contracts
With trustless and reliable source of truth, some insurance products could be bought and settled programmatically with a smart contract. The biggest cost in insurances is fraud, so again, Oracles are critical here. A couple of examples of Smart Insurance include:
- Automatic payments if flight is delayed with Etherisc or Fizzy.
- Incentivised local oracles verify claim locally and report to the blockchain before claim is released with Nexus Mutual.
- Artificial Intelligence combined with Geospatial data for innovative and programmatic insurance with FlyingCarpet.
Shipment
GPS is not always suitable for a dApp requiring reliable location to automatically release a payment, because it is a centralised point of failure that can be spoofed. With FOAM for example, it is possible to lower this trust criteria and rely on a decentralised network, here acting as a location oracle, to guarantee a claimed location.
Collateralised lending and stablecoins
Need access to reliable data on collateral value to decide when to liquidate assets or when to re-stabilise the value of the stablecoin if it drifts too far from intended value. For example, Maker DAO’s DAI is an Ether-backed stablecoin (soon to become multi-asset backed) and it has multiple Oracles reporting Ether’s price to know when loans are insufficiently collateralised and should thus be liquidated to protect the system. These oracles are chosen and compensated by Maker’s token holders.
This is also relevant to trustless peer-2-peer lending platforms like Ethlend or Dharma.
Prediction markets:
Decentralised prediction markets (Augur, Gnosis) allow unprecedented level of human coordination, leveraging the knowledge of the crowd. These markets must rely on one or multiple oracles for off-chain event settlement.
II. Ensuring Oracles Integrity
Blockchains were deliberately built detached from the outer world and its trusted third parties. However, most events still occur outside blockchains, so we need a bridge without compromising censorship-resistance. Indeed, a dApp is only as trustless as its weakest link, so a single corruptible source of truth is unlikely to be sufficient. Involving multiple sources of truth is probabilistically safer, but equally more expensive. There is no one-size-fits-all solution and we can expect applications to take a risk-based approach to decide how many sources are necessary for different applications.
For example, the temperature in London may be relayed by a single oracle (e.g. API) if it is for a smartphone app where rough precision is tolerated, but if the reported temperature is used to settle a $10M insurance contract, we might want to involve several (many!) oracles: satellite data, local sensor data, and so on.
Consequently, there is likely to be a range of solutions offered by oracles with trade-offs between cost and decentralisation depending on the value at stake.
Swiss-Cheese Model
It is difficult to guarantee a third party will always be trustworthy. To solve this in the centralised world, we use multiple protective layers: contracts, liable companies, insurances, the law, … As long as at least one these layer works as intended, then integrity is preserved. However, if all layers were compromised, an attack would indeed be successful (Swiss cheese model).
An example of over-reliance of centralised oracle is the LIBOR Scandal. The London Interbank Offered Rate (LIBOR) is an interbank interest rates often used to extrapolate interest rates for professional and personal mortgages, in addition to other financial products, which in total is underpinning $300 trillion of loans. It was shown that swap traders colluded to manipulate this rate for many years, dating back as early as 2005 or 2003 depending on the sources. LIBOR is also used as an indicator of a bank’s health, and the manipulation of the rate leading up to the 2007–2008 financial crisis made some financial institutions appear stronger than they actually were…
The conclusion here again is that a single (unaudited) source of truth is a weak link and can compromise the entire system that depends on it.
There are no fail-proof systems, but we can apply the same concept of multiple barriers to decentralised oracles as trust-minimising mechanisms.
A. Multiple data sources
The simplest way to decrease the likeliness of false data reporting is to have an oracle aggregate multiple data sources. In that case, there are only two ways to receive erroneous data: the majority of data sources were compromised, or the oracle itself is compromised (leaving a single point-of-failure).
B. Multiple oracles
By increasing the number of oracles, they are probabilistically less likely to all be malicious, and therefore the system is safe as long as a majority is honest. However, the risk that all oracles are transmitting incorrect information, purposely or not (if the sources themselves were compromised), is still there.
C. Skin-in-the-Game
Decentralised networks can encode certain incentive mechanisms to ensure their actors behave in the interest of the network and are compensated for doing so. This is why miners receive block rewards, and this is why proof of stake needs slashing conditions to counter Sybil and nothing-at-stake attacks.
It can be dangerous to let decentralised anonymous actors play the role of oracles, especially given there are no legal recourse if their misbehaviour has financial repercussions. Using token engineering, decentralised oracle networks can force nodes to stake a bond/deposit, usually in the native currency of the network, for the opportunity to perform work for the network. If they behave well, they earn rewards for their work. If they misbehave, they lose a percentage of their stake. This ensures Oracles have the right incentives to propagate accurate data.
D. Trusted execution environment (TEEs)
Intel’s recent Software Guard eXtensions (SGX) or ARM’s TrustZone are good examples of TEEs. The mechanism is comparable, so we will use Intel’s solution as an example.
Briefly, SGX allows an application to be executed in an environment called an enclave that confers hardware protection on user-level code. First, enclaves protect the integrity of the application (its data, code, and control flow) against subversion by other processes. Second, an enclave protects the confidentiality of an application, meaning that its data, code, and execution state are theoretically opaque to the rest of the operating system. It can however read and write memory outside the enclave region. SGX seeks to protect enclaved applications even against a malicious operating system, and thus against even the administrator of the node on which an application is running.
Running an oracle in an enclave and distributing attestations can provide strong assurance that the oracle is executing a particular application, because it can be proven remotely that a system is running a legitimate SGX system.
It is worth mentioning that two successive vulnerabilities (March-2018 & July-2018) were discovered in Intel’s SGX, and more are being discovered. While the first vulnerability has been fixed since, this reinforces the feeling that using a TEE alone is a single point of failure, and that multiple protection layers against single point of failures are critical when a smart-contract is to execute solely based on an autonomously generated input from one or more oracles.
These protective barriers are not bulletproof when taken in isolation, but they are clearly stronger when combined. In the next section, we will cover the main attack vectors for decentralised oracles, and this will be followed by examples of actual projects leveraging these.
III. Sybil attacks and other vulnerabilities of decentralised systems
Creating an Oracle system is easy. It is the trustless component that will like cause many headaches.
Key risks: A game of incentive is played between parties relying on smart contracts, and anonymous oracles that cannot be prosecuted. When leveraging multiple oracles, they must reach consensus as a smart contract only takes one input. Therefore, to prevent attacks, a mechanism is required to ensure the oracles:
- have no way to identify each other.
- have no way to communicate with each other: an oracle with a significant voting power (e.g. 40%) could broadcast its answer and would not have to convince many nodes to ensure its vote has the majority. This is relatively trivial if other oracles know that this node has indeed such a strong voting power.
- have no way to prove the content of their claims to others: like the previous point, a mechanism must exist to hide submitted answers while oracles are still fetching their answers and reveal them only when everyone has participated.
The following attack mechanisms or vulnerabilities are applicable to decentralised oracle networks.
Majority attack: There is a risk that a significant number of nodes within a network are owned by a single entity, or form a cartel, in order to deliver false data and still belong to the majority. Precautions against this risk are critical in decentralised oracle network projects, usually relying on reputation and number of nodes involved.
Mirroring: this is a special kind of Sybil attacks in decentralised oracle networks. To reduce operating costs, a node can decide to collect the data once, and then share it off-chain with other nodes it might control. While this type of attack is not dangerous if it spreads true information, it can seriously degrade security by eliminating the error correction resulting from having multiple queries.
Freeloading is when one oracle maliciously replicates another oracle’s answer. This is usually addressed with a commit-reveal scheme, where each oracle commits its encrypted answer and is decrypted when enough oracles have submitted their answers.
Data corruption can be hard to detect, especially when there is only one data source (single-point of failure). The approach is generally to use multiple sources, and multiple oracles, to reduce the risk of corruption.
On-chain data confidentiality: If the request for data is sensitive and private, even though the request might be encrypted, the data reported by the group of oracles could involuntarily reveal what the request was. A potential solution is forcing nodes to decrypt requests within an TEE enclave, and instead publish a general answer to the blockchain that both the client and nodes will understand. For example, for a smart flight insurance, the user might not want to have transparently broadcasted that he was on the London to New York flight. The oracles must know which flights we are talking about, but they can broadcast the answer to a different question, such as “Has the flight been delayed or not?”, to which a yes/no answer suffice with no further information exposed on-chain.
IV. Projects working on Decentralised Oracles
There are multiple projects working on solving these challenges with varying degrees of decentralisation, by programming different incentive mechanisms to reduce single trusted intermediary reliance, and by introducing sophisticated attack-prevention mechanisms. An in-depth analysis of each project is outside of the scope of this post, and instead, a high-level description is provided.
The projects are split into 2 categories: Networks supplying oracle services, and Networks internalising oracle services.
1. Oracle-as-a-Service
ChainLink (LIVE)
Chainlink aims to build a fully decentralised network of oracle nodes compatible with Ethereum, Bitcoin and Hyperledger with modularity in mind: Every piece of the ChainLink system is upgradable. The main idea is to build a trusted marketplace for oracles where client and nodes are connected. Good behaviour is incentivised as performance and reputation is public, and bad behaviour will incur penalties. They are initially doing aggregation of data from oracles on-chain, but are looking to move it off-chain with an interesting design.
The security of any system is only as strong as its weakest link. Decentralisation is here to ensure availability at all times, but to counter the risk of faulty nodes delivering poor data, ChainLink puts forward two possible solutions.
Initial solution: On-chain aggregation
In-contract aggregation of all nodes’ value on-chain, which can be publicly audited, using a commit-reveal to avoid nodes observing other oracles’ responses and freeloading. The final value is thus decided on-chain once enough responses are public, but this has a significant computation cost: one transaction per node, one transaction to reach consensus, and one or more aggregation contracts deployed on Ethereum.
Medium-term strategy: Off-chain aggregation
Off-chain aggregation offers a more cost-effective way to reach consensus. Unfortunately, this does not suppress the problem of freeloading.
The proposed solution is to use Schnorr signatures: each oracle participating in a job receives a [public key, private key] combination specific to that job. They can use their private key to generate a partial signature which contains their solution to the data query (encrypted). One partial signature on its own is insufficient, but if enough partial signatures are combined (figure below), it yields a collective signature equivalent to the aggregation of all answers in a single transaction.
The key word is enough partial signatures, because this offers a relief mechanism when some nodes do not answer the query. The downside of this method is that if an honest node takes too long to send its answer, they will not be rewarded — thus inducing a time dependency for nodes. This does tackle freeloading though, because once answers are revealed, no additional submissions are taken.
You can find more information on ChainLink here. Illustrations were taken from their whitepaper.
Witnet
Witnet is a reputation-based decentralised oracle network: nodes running the Witnet software earn or lose reputation when they fulfil a data request correctly or incorrectly — where correctness is defined by a consensus algorithm analysing nodes’ answers. Nodes which disagreed with the consensus lose reputation (by being off-line or attempting to be malicious), which is split between honest nodes. If the consensus was a timeout, as long as a node agrees with the consensus, it remains unpunished.
The oracle nodes, called witnesses, are randomly chosen for jobs and to mine blocks based on their network reputation, making majority attacks more difficult. Good actors will thus quickly increase their reputation and acquire more responsibilities within the network, while inactive and malicious actors will rapidly lose all network credibility and with it their right to contribute to the network, making them inoffensive.
Since reputation is so valuable in Witnet, in addition to this transfer of reputation between good and bad nodes after an oracle job, there is also a constant redistribution of reputation at each block (90 seconds) between all active nodes to prevent A. reputation centralisation over the oldest honest nodes and B. exit scam (nodes stopping fulfilling jobs to collect mining rewards only).
The redistribution is performed by a demurrage function at every block: active nodes see their reputation diminished in a logarithmic exponential decay, and nodes that behaved well in that block earn an equal share of this reputation. In other words, reputation is at stake at all times and those with the biggest reputation have the most to lose. Therefore, in order to remain a top oracle on Witnet, you must participate well at all times.
Witnet is its own separate blockchain and can therefore provide decentralise oracle services anywhere via bridge nodes. This might become less relevant with interoperability solutions, but until then, it offers a scalable solution, with reduced on-chain operation fees, and allows to fix critical vulnerabilities in last resort.
You can find more information at https://witnet.io or you can read their whitepaper here.
Oraclize
Oraclize is a London-based cybersecurity company with a team of 9 people offering a centralised solution to blockchain oracles. They have the longest actively running and the world’s most widely adopted blockchain oracle service. While it is available on multiple blockchain platforms (Bitcoin, Ethereum, Monax, Rootstock, Corda and private networks), the majority of their customers are working on Ethereum.
Their approach is to leverage all TEE environment providers to minimise vulnerability. This is what they call sandboxing. Oraclize leverages the products of IT providers and manufacturers (including Amazon’s EC2, Google’s SafetyNet, Qualcomm’s QSEE, Ledger’s Nano S and Intel’s SGX) as key components of its own core service (the Oraclize technology). They are physically grouped within a unique environment and leveraged together: Oraclize has designed ad-hoc custom applications as well as a software layer connection for all of TEEs to make them interoperable. By recovering the data from multiple TEEs, even if one technology were to be compromised by a vulnerability such as Spectre for Intel’s SGX, the overall aggregation of value would still ignore the compromised data point. (assuming the vulnerability was architecture specific, and not a generic one hitting all processors)
To achieve distributed trust and the integrity of their data, Oraclize has been relying on TLSNotary to digitally sign TLS data from https websites. This comes at cost: Oraclize can in theory only deliver data as shown on the website with no post-processing off-chain, but this already covers many use cases. The main risk here remains that if too many data sources are compromised, there is no way to prevent wrong data from being propagated, but this risk is also present in the more “decentralised” solutions.
You can find more information about Oraclize here
Town Crier
The team behind this academic proposal is composed of 5 Cornell University PhDs and undergraduates.
Town Crier acts as a bridge between smart contracts on any blockchain and https-enabled websites with TLS layer handling handshakes for secure communication to deliver source-authenticated data. The approach taken is different to TLS-notary (security at software level only), allowing for more customisable data relaying.
The data is recovered by nodes running on Intel’s SGX (security at software and hardware level). This authenticated data feed is delivered from enclave to the blockchain, solely relying on the SGX protection to testify the node is indeed running the software as expected.
To protect confidentiality, messages are only decrypted inside the Trusted Execution Environment’s enclave, which can thus be used not only for safe data transfer but also for ingesting encrypted user credentials (e.g.: private API). In addition, custom requests are supported for potentially multiple web-scraping target.
Their approach to tackle single points-of-failure is to both aggregate data source as well as data oracles on multiple SGX platforms. The software has proven to be relatively scalable with throughputs of 15–65 transactions/sec.
You can find more about Town Crier here. The acquisition of Town Crier by ChainLink was reported during Devcon 4 by the CEO, Sergey Nazarov on 1 November 2018.
2. Internal Oracle Services
A. Prediction Markets
“Prediction markets are like betting markets. You bet on the outcomes, and the price for these reflects the probability for the outcome happening.” Stefan George, Gnosis
Augur and Gnosis are the two most well known decentralised prediction markets, as they are both dating back to 2015. They are leveraging the wisdom of the crowd and frictionless decentralised networks to create elegant prediction marketplaces. Both have to carefully design incentives to ensure markets are correctly settled. We will take a closer look at how Augur handles this.
Augur (LIVE)
Augur is a trustless, decentralised oracle and prediction market platforms, allowing distributed individuals to speculate on and report the objective outcome of any event. Creating a decentralised prediction market platform is the “easy” part in Augur ; the critical element is markets integrity by ensuring the most profitable option for rational Augur actors is to be honest.
Augur has a native token called Reputation (REP) which must be staked to create new markets and report/contest their outcomes — these behaviours are compensated with a share of the platform fees when uncontested. Speculation on the markets is not denominated in REP.
Augur allows anyone to create a market about any upcoming event. The market creator sets the event end time and chooses a designated reporter to report the outcome of the event. This outcome can be challenged by the community.
These are the successive protective measures Augur had to put in place to protect honest participants:
- There is a validity bond staked by the market creator: this is forfeited if the markets was not well-defined or had no possible objective and unambiguous outcome.
- There is a no-show bond staked by the market creator: this is forfeited if the market’s designated reporter does not report the event’s outcome within 3 days. If unclaimed, anyone can then submit their tentative event outcome.
- Once an tentative outcome is reported, there is a 7-day period during which any REP holder(s) have the opportunity to dispute the tentative outcome. A successful dispute requires a minimum dispute bond size proportional to the funds at stake in the market. If a dispute is unsuccessful, the REP staked are returned to their owner, and the market is settled.
- If the first tentative outcome is successfully disputed, the next step will depend on how much tokens were staked to dispute the round. The market will either undergo another dispute round if the dispute had <2.5% of all REP staked ($1.5M at today’s rate) or will enter the fork state (if >2.5%).
- The fork state is a last resort 60-day freezing period where all markets are temporarily frozen until they are migrated to the “new Augur universe”. If the market that generated all these challenges was a two-option market (Yes/No, Elected/Not-Elected, Win/Did not Win…), there will be 3 universe created, i.e. 3 potential truths: one where yes is the truth, one where no is the truth, and a final one where invalid is the truth. On each of these universes, the market will be settled accordingly.
Users will need to migrate their REP tokens to one and only one of these universe.
Users who migrate their REP tokens within 60 days commit to this outcome, and receive a 5% additional REP for taking that risk. The risk being that if they stake on the wrong universe, their REP is trapped there (REP in universe A/B/C are not fungible).
For users who do not wish to take that risk, they can migrate anytime after the 60 days on what has been decided by general consensus to be the true outcome of this market. While the parallel Augur universes can temporarily co-exist (e.g. Ether / Ether Classic), the expectation is that one will be the obvious winner, regaining most market activity, and become the accepted Augur.
We hope the reader can see how dangerous ambiguity is when creating a market, and how tricky and it can be to have decentralised oracles controlling an outcome with financial consequences.
Whilst the Augur oracles are reporting the outcome of real life events to settle Augur markets, we can imagine that if these incentives are strong and Augur keeps growing, then Augur’s markets once settled could become reliable oracles themselves. In other words, one could assume that ultimately a market on Augur will (probably) settle on the actual true outcome, and it can therefore be taken as input for another smart contract for example.
Learn more about Augur here.
B. Payment Services
Ramp
Ramp Network (@RampNetwork) | Twitter
Using open banking APIs to connect crypto with fiat.
twitter.com
Bank ledgers had historically been hardly accessible, but this is rapidly evolving as more jurisdictions are adopting open banking frameworks. For example in Europe, the PSD2 directive is an obligation for European banks to give API access to bank accounts to licensed third party providers, and Ramp has applied to become one.
Ramp is building a financial primitive for trust minimised interoperability between incumbent financial institutions and public blockchains. In practice, they are using PSD2 to offer p2p, fiat-to-crypto atomic swaps (Ramp Swaps). The process is the following:
- The seller creates a smart contract to lock a digital asset in escrow. The digital asset will either be released to a buyer that sends the right fiat amount in due time or returned to the seller if unsuccessful.
- The buyer sends a direct wire transfer to the seller.
- A payment oracle verifies the buyers’ payment and sends a Proof of Payment (PoP) to the network. The oracle has access to the buyer’s and seller’s account and can see the payment respectively being sent and received.
- The smart contract unlocks the assets in escrow and sends it to the buyer.
Data stored on a financial institutions’ ledger is obviously sensitive, so there are clear challenges when reporting such data compared to an oracle reporting on publicly available information (such as commodity prices or sport results, …):
- data is provided by a single source of truth — e.g: a bank.
- information about transfers are not immutable, as financial institutions may revert certain transactions.
- data is not publicly accessible nor easily verifiable.
- information about a given account (identity & transaction history) should remain private.
- ledger’s accessibility varies and is always dependent on user’s consent.
- bidirectional communication is sometimes possible — this could enable smart contracts to initiate transactions.
- data is structured — it forms a ledger with accounts, but the structure may differ from institution to institution.
Due to privacy requirements, one cannot simply pass information obtained from a bank to a blockchain. Raw information needs to be stripped from publicly identifiable information and matched to blockchain transaction. For these reasons the data needs to be processed off-chain and delivered to the network as a simple boolean answering a binary question (e. g. was a particular payment made?):
Ramp is currently working on further decentralising its tech and making it available in more jurisdictions. Ramp is also exploring usage of secure enclaves as an extra-layer of protection to eventually allow more authorised third parties to become oracles attesting bank transactions on blockchains. These development will remove the biggest points of centralisation: the fiat gateways. If you want to learn more about Ramp, check out their website.
C. Decentralised Insurance
“We can now trust code rather than profit driven insurance company, but that is pointless if the oracle can’t be trusted.” Hugh Karp, NexusMutual
Parametric Insurance is a special kind of insurance featuring a parametric trigger and payout condition (if Y happens, pay $X), such as a delayed flight, or a centralised cryptocurrency exchange hack for example. These products are an obvious fit for smart contracts. They require oracles services to provide reliable data on these events, either in-house (EtherRisk with defined data input, or Nexus Mutual through a voting process) via good economic incentives or when possible through a Decentralised Oracle-as-a-Service providers.
One can expect to eventually see more insurance products handled by smart contracts, especially as sophisticated IoT sensors, drones and satellites are leveraged with Flyingcarpet. For example, a farmer could buy an insurance with a smart contract where a meteorological satellite feeds the data through Flyingcarpet, and is analysed with AI models developed on the platform.
There will however be cases where an automatic detection and processing of claims are not possible without local coordination of input information. These cases require local oracles incentivised to act as independent claims agents, e.g. to quantify the damages in a car. These agents are used by insurance companies and can easily add a smart contract to the list of their potential employer. This is on the roadmap of both EtherRisk and Nexus Mutual who are using similar staking designs where good behaviour is earn fees but proven malicious behaviour is heavily penalised. As fraud has always been the biggest cost in insurance, it cannot be expected for the system to be impossible to game, but if it matches the reliability achieved by centralised insurance, the cost saving with a smart contract could be passed to the customer.
Eventually, these claim agents could also work together in a Decentralised Autonomous Organisation, using Aragon or Colony for example, to coordinate their specialised operations.
V. Conclusion
As often with decentralised networks, the challenges and opportunities associated with their immutable nature can be summarised in one word: incentives. Decentralised networks allow unprecedented global cooperation through well designed financial incentive mechanisms to ensure rational actors act in the interest of the network.
Eliminating dependence on trusted third parties is a challenge, as anything and anyone is theoretically corruptible, but instead one must reduce the risks to tolerable levels. Indeed, whilst there is always a risk for short term attacks, one should not undermine the long term incentives of network keepers to maintain what might become a significant source of revenue for them.
Bitcoin miners taken as a whole represent a trusted “entity” employed and trusted to secure the Bitcoin ledger. There have been occurrences where miners could have exploited vulnerabilities for short-term gains, but they rationally played the long-term game instead, thereby preventing their ASICs investment and future block-rewards to become worth significantly less. Furthermore, Ethereum is often criticised for its over-dependence on services like Infura or Metamask, and even though these are indeed point of re-centralisation through Consensys, they have a significant stake in Ethereum and therefore have little incentives to purposely become malicious. These intermediary solutions are tolerable risks on the path to wider decentralisation.
Interacting with the outside world is the next logical step for smart contracts, and again, rightfully designed incentives will have to be deployed to prevent attacks. The main challenge here is the potentially strong economic incentives to misbehave. However, as these networks grow, they will become a significant source of revenue for their contributors. Gradually, there will be enough oracle service providers with significant stake in these networks, which will translate in little reliance on a single party but extremely high confidence on the quality.
The financial incentive of carrots and sticks is powerful, and we look forward to seeing the development of all these projects. ChainLink through the use of both token staking and reputation, is in a good position to have reliable oracle services. There are many use cases that will be unleashed when we have provably working oracles, and we are most excited for decentralised insurance products, financial products, and prediction markets.
Disclaimer: Fabric Ventures has an investment in Ramp.
If you liked this article, please follow me on Twitter to be updated on my next posts!
