Dry goods | comprehensive overview decentralized predictor

I would like to thank our team at Fabric Ventures for their support of Joey Krug (Augur Core Developer), Tomas Bertani (founder of Oraclize), Hugh Karp (founder of Nexus Mutual), and James Ryan Moreau (Witnet Technology Community Leader). Gorka Irazoqui Apecechea (Witnet Fellow), Szymon Sypniewicz (Ramp co-founder) and Przemysław Kowalczyk (Ramp founder) gave us important feedback.

Distributed ledgers and smart contracts can eliminate the friction caused by the trust problem in the current human interaction and bring unprecedented innovation to the society. But before that, if the above smart contracts can't get extra-chain input without additional trust , the so-called innovation is just on paper.

The decentralized oracle is a gateway for smart contracts to interact with the outside world, and is designed to work without being overly dependent on a single source. How to let the decentralized prediction machine be implemented will also cause another wave of innovation.

This article aims to introduce the following points:

• Digital Money Hosting Alliance White Paper
• Getting started with blockchain | What is the difference between spot leveraged trading and futures contracts? Risk geometry?
• US Treasury Secretary: Libra is involved in “national security” and may be abused by terrorists

1. Why the prophecy service is decentralized technology
2. An important part of the stack for the need for trust-free services
3. The complex challenge and attack interface faced by the predictor
4. An overview of 8 projects dedicated to solving these challenges

I. Why do we need a prophecy machine?

Smart contracts on unlicensed chains (such as Ethereum, Dfinity) operate in an adversary environment, and their security is guaranteed by network-only deterministic transactions (that is, transactions verified by all nodes). The smart contract is designed to accept input → execution logic → update the corresponding blockchain state, and this process is irreversible , and there is no Ctlr+Z retracement in the world of blockchains.

Allowing smart contracts to obtain data from outside the blockchain system is a double-edged sword. It greatly expands the blockchain application scenario and enables the blockchain to interact with the outside world. It also introduces certain trust problems. The miners in the unlicensed chain are not sure that they can verify all external inputs, so they can only perform any operation that meets the smart contract pre-conditions without distinction.

To give a simple example: Alice and Bob bet on the price of Bitcoin at 2 pm on January 3, 2019 London time. They set up gambling with smart contracts, each depositing 1 Ethereum into the contract. If the bitcoin price is higher than $4,200, then Alice wins 2 Ethereums, otherwise Bob gets 2 Ethereums. Smart contracts don't understand the price of Bitcoin, and the outcome of a gambling game cannot be reversed once it is determined, so we must ensure that only the correct bitcoin price is reported to the contract. At this time, we need a so-called oracle (a component used to provide data).

A oracle is an entity that signs a statement of the state of the world. For example, the oracle can report the BTC/USD price of Coinbase on January 3rd and the Champions League. The final information is obtained by aggregation and reorganization of one or more trusted source messages received by one or more oracles.

Before delving into the many technical details of the trust-free oracle, let's look at five key use cases for smart contracts that have been dictated.

Financial product

Smart contracts are naturally compatible with many financial products: interest rate swaps, cash settlement options, decentralized leveraged trading, and more. All of the above financial products require a trusted data source to ensure the correct execution of the settlement on the chain.

Some projects have the ability to even apply such oracles to financial products, including: CDx, dYdX, MakerDAO, Vega Protocol, 0x protocol.

Smart contract insurance

Under the trust-free and reliable source of support, some insurance products can be programmed to be implemented in the form of smart contracts. The biggest cost in the insurance industry is fraud, so the importance of the prophecy is self-evident. Some current project examples of smart insurance include:

• Etherisc and Fizzy implemented automatic payments for flight delays.
• Nexus Mutual allows the motivated local oracle to verify local unpublished assertions and escalate them to the blockchain.
• FlyingCarpet implements new programmable insurance for artificial intelligence and geographic data.

Freight

GPS is not a reasonable source of data for dApps to automatically release payments based on geographic location, as it is a centralized system that is easily spoofed. Using the oracle can reduce this trust cost. Take FOAM as an example. It can reduce the trust threshold of dApp to the original data source, and trust depends on the decentralized network (in this scenario, it is a location predictor). Guarantee the credibility of the location information declared by the source.

Mortgage loan and stable currency

In the scenario of mortgage lending and stabilizing coins, it is necessary to access credible data that determines the value of the collateral to determine whether it is necessary to pay off the debt. When the stable currency value is too far from the design value, it is also necessary to obtain the currency value data through the predictor to determine whether it is necessary to take measures to stabilize the value of the stable currency. For example, Maker DAO's DAI is a stable currency endorsed by Ethereum (which will be upgraded to a multi-asset endorsement). It uses multiple oracles in the design to report the price of the Ethereum, so that when the stable currency is released Protect the entire system by triggering a liquidation operation when there are not enough collateral endorsements. These oracles are selected and funded by the holders of the Maker tokens.

There is a similar design in the trust-to-peer lending platform Ethlend and Dharma.

Forecast market

The decentralized forecasting market (Augur, Gnosis) takes human collaboration to an unprecedented level and takes full advantage of the wisdom of the group. These markets must rely on one or more oracles to determine the events under the chain.

II. Ensuring the honesty of the oracle

The blockchain deliberately isolates the outside world from third parties that require additional trust. However, most of the incidents occur outside the chain, so we need to bridge the blockchain and the extra-chain world without compromising the anti-censorship. In fact, dApp's trust-freeness depends on the most vulnerable of the in-chain world ties, so it is not enough to just have a source that may be corrupted.

Accessing multiple sources can achieve higher security in terms of probability, but this will add a lot of cost. The number of sources required for a specific application scenario may be more or less. In practice, we should adopt a risk-based design approach to determine how many sources are needed for different applications.

Take London's temperature data as an example. If you only use the data displayed on the mobile app, even if there is a problem with the data, there will be no serious consequences. It is enough to use a oracle (such as API); if the predictor is reported The temperature determines the outcome of a $10 million insurance contract, and we need to access many predictive machines, including satellite data, local sensor data, and more.

In general, it is necessary to balance the cost of the established oracle system according to the amount of funds involved, and find a propeller program suitable for your own scene in practical applications.

Swiss cheese model

It is very difficult to ensure that third parties have never done evil. Solving this trust problem in a centralized world requires multiple layers of protection: contracts, trusted companies, insurance, law, and more. As long as at least one of the layers of protection does not fail, the system is still considered to be honest. However, if all the protective layers are corrupted, the attack will take effect (Swiss cheese model).

– Fit Swiss cheese model (Source) –

The LIBOR scandal is a lesson from over-reliance on a centralized oracle. The London Interbank Offered Rate (LIBOR) is a commonly used interest rate reference for commercial and private loans, supporting about $300 trillion in loans. However, according to the sources, it can be traced back to 2005 or 2003, and the index was conspired by some swap traders. LIBOR is also an indicator of whether banks are performing well, so the manipulation of this rate has also led to some institutions appearing to be healthier than they actually were during the 2007-2008 financial crisis.

So here we re-emphasize that a single (unaudited) source is extremely fragile and affects the security of the systems it serves.

There is no perfect system in the world, but we can apply the concept of multiple barriers to the decentralized oracle system to minimize the trust mechanism.

A. Multiple data sources

The easiest way to reduce data errors is to use a oracle to aggregate multiple data sources. In this way, only two kinds of data that may be collected are outrageous: one is that most of the data sources are corrupted, and the other is that the predictor itself has been broken (becomes a single point of failure problem).

B. Multiple oracles

When increasing the number of oracles, most predictors will not be malicious according to probability, so as long as the majority of the system remains honest, the system is safe. However, whether it is intentional manipulation or unintentional (the information source itself fails), there is no possibility that all oracles will transmit error messages at this time.

C. Benefit sharing

Decentralized networks can develop specific incentives to ensure that the network participants' rules of conduct are consistent with the overall interests of the network. When network participants follow the rules, they will be rewarded. For example, miners can get block rewards for mining, and the rights certification system needs to be penalized to defend against witch attacks and non-discriminatory attacks.

It is very dangerous to let anonymous participants in the decentralized network act as predictors. In the decentralized system, once they do evil to obtain economic benefits, there is no legal provision to pursue those ill-gotten gains. With the design of the token project, it is possible to force a node in the decentralized network to pledge part of the deposit/deposit, which is usually the original currency in the system. When the node works well, it will get a certain amount of compensation, and if the node does evil, it will lose the pledge of assets in a certain proportion. The above mechanism ensures that the oracle system has a positive incentive mechanism to facilitate the participants to generate accurate data.

D. Trusted Execution Environment (TEE)

Intel's recent SGX (Software Guard eXtensions) and ARM's TrustZone are both trusted execution environments. Because they are similar, we will introduce Intel products as an example.

In short, SGX allows programs to be executed in the CPU's enclave, giving the user-level code hardware-level protection. First, the circle avoids the application (data, code, and control flow) being corrupted by other processes. Second, the circle protects the confidentiality of the application, that is, the program's data, code, and execution state are theoretically opaque to the rest of the operating system, but the program can still read and write memory outside the bounding area.

SGX hopes to protect the programs in the perimeter on a malicious operating system, and thus even protect the application from being compromised by the system administrator on the node. Running the oracle program in the circle and distributing the data strongly ensures the safe operation of the oracle program because it can be detected from the far end that the system is running on a legitimate SGX system.

However, it is worth noting that two vulnerabilities (March-2018 & July-2018) have been discovered since the release of SGX, and there are still studies exploring other vulnerabilities. Although the first vulnerability has been fixed, it warns that we will still cause a single point of failure with only TEE. When the execution of a smart contract relies on input automatically generated from one or more oracles, multiple layers of protection must be designed to avoid single points of failure.

The above-mentioned protective barriers are not completely foolproof, but when they work together, they can have a stronger protective effect. In the next section, we will introduce the main attack interface in the decentralized oracle system and give examples of corresponding defenses.

III. Weakness of witch attacks and other decentralized systems

It is not difficult to build a prophecy system. What is difficult is the design of the trust component.

Key risks: There is a conflict of interest between the parties relying on smart contract rulings, and the anonymous oracle has no litigation risk. When running a multiple oracle system, each oracle must reach a consensus because the smart contract accepts only one input. Therefore, in order to defend against attacks, a design mechanism is needed to ensure that the predictor meets the following requirements:

• Unable to recognize each other
• Unable to communicate with each other: A prophecy with considerable voting power (say 40%) broadcasts its own answers, and does not need to deliberately convince other nodes that their own results are mainstream answers. However, if other nodes already know that this node has such a large voting power, then this requirement is relatively meaningless.
• Unable to prove to other nodes that they are the answer to their own: Similar to the previous point, a design mechanism is needed to hide the answers submitted by each node, and only the source node is exposed after everyone has submitted the answer.

The following attack strategies or vulnerabilities are valid for decentralized predictor networks.

Most people attack: There is a risk that most nodes in the network are controlled by one entity or one alliance. At this point the network is still controlled by the majority, but it has been maliciously manipulated. In the decentralized oracle network project, pay special attention to such risks, and the power of the nodes needs to be determined according to the reputation of the nodes and the total number of nodes.

Mirror: This is a special witch attack in the decentralized predictor network. In order to reduce the cost of running a node, the controller of a node can collect data only through one node, and then pass the data under the chain to other nodes that it controls. When the data he passes is still true, the attack is not very harmful, but if there is a problem with the data being transmitted, it will greatly reduce the security of the whole system, because the mechanism for refining the data accuracy through multi-party query is destroyed.

Eating empty: When a prophecy machine maliciously copies the answers of other oracles, we call him empty. This problem can be solved by the "commit-reveal" mechanism, in which the answer submitted by the oracle is encrypted, and only when enough oracles have submitted the answer, the answer is decrypted.

Data corruption is difficult to detect, especially when there is only one source of information (single point of failure). The solution to this problem is usually to set up multiple sources of information and multiple oracles to reduce the risk of data corruption.

Data confidentiality on the chain : If the request for data is both sensitive and private, even if the data request is encrypted, the request information will be unconsciously revealed when the final data is reported. The solution to this problem is to force the node to perform decryption in the TEE circle environment and report to the blockchain the generic answers that all users and nodes can see. For example, for a flight insurance, the user may not want others to know that he is flying from London to New York. Therefore, after knowing the specific flight, the oracle will only answer “whether the flight is delayed?” on the blockchain, or other questions that need to be answered with yes/no without further disclosure.

IV. Project dedicated to decentralized oracles

Many projects with different degrees of decentralization are committed to solving the above problems, or writing multiple incentives to reduce dependence on a single trust intermediary or to introduce a mature attack-resistance mechanism. For the sake of space, this article cannot introduce the depth details of each item one by one, so the following is a high-level description of various items.

All projects can be divided into two categories: providing predictive machine services over the network, and the network's own predictive machine services.

1. Prophecy machine as a service

ChainLink (LIVE)

The goal of Chainlink is to build a fully decentralized network of predictors that are compatible with Ethereum, Bitcoin, and Hyperledger, and support modularity: every part of the system supports upgrades. The main idea is to create a credible market for the prophecy machine. Prophet nodes with good behavior are motivated, their performance and reputation will be made public, and nodes with malicious behavior will be punished. Chainlink initially aggregates the data of the oracle on the chain, and then proceeds through an interesting design to aggregate data under the chain.

– Chainlink Schematic –

The security of any system is determined by its shortest board. Decentralization guarantees availability at all times, but there is a risk that the failed node will pass the wrong data, for which ChainLink offers two solutions.

– Chain aggregation (graph source) –

Initial solution: chain aggregation

The contract aggregates the data of all nodes on the chain (can be publicly audited) and uses the commit-reveal method to prevent the nodes from obtaining the results of other oracles and plagiarizing each other. The final result after the aggregation will be determined after enough results have been published on the chain, but this will bring a lot of computational cost: each node will initiate a transaction, each transaction needs to reach a consensus, and it needs to be in the ether. The workshop deploys one or more aggregation contracts.

Medium-term strategy: chain aggregation

Under-chain aggregation can improve the economics of consensus, but it cannot solve the problem of eating empty.

The under-chain aggregation scheme takes advantage of Schnorr signatures: each predictive opportunity to participate in a task receives a [public key, private key] combination for this task. The predictor uses the private key to generate a partial signature for the (requested) data result (encrypted). A single partial signature cannot be used directly, but when a sufficient number of partial signatures are combined (as shown in the following figure), a collective signature is formed, which is equivalent to a chain transaction that aggregates the data results.

-Under chain aggregation (graph source) –

The keyword here is a sufficient number of partial signatures, which also means that the scheme provides a fault tolerance mechanism (when some nodes are unable to respond). The downside of this approach is that even if it's an honest node, if the message spreads too long, they won't be rewarded – this makes the node dependent on response time. This solution also solves the problem of plagiarism, because when the results are revealed, it is no longer possible to submit new answers.

You can find more information about ChainLink here. The diagram in this article shows the white paper from it.

Witnet

Witnet is a reputation-based decentralized oracle network: whether the node running Witnet software correctly responds to the data request determines whether it acquires or loses the reputation value , and the correctness is determined by the consensus algorithm analyzing the result set of the node. . Nodes that are inconsistent with the consensus lose their reputation values ​​(such as they are inconsistent due to node downline or attempting to do evil) and are thus separated from the normal node area. When the process of reaching a consensus times out, as long as the final node results are consistent with the consensus, it will not be punished.

The oracles, known as witnesses, are randomly assigned tasks and excavated based on their network reputation, making them less susceptible to "majority attacks." A well-behaved node can quickly increase the reputation value and assume more responsibility in the network; on the contrary, the failed and malicious nodes will quickly lose their credibility in the network, and thus can no longer contribute to the network, and ultimately become insignificant. .

Because the reputation value in Witnet is so important, in addition to the change in reputation value between good and bad nodes (after completing a task), the system also designs a mechanism for fixed value redistribution among all nodes. The redistribution interval is one block at a time (90 seconds), thus avoiding: A. Centralization caused by the reputation value concentrated in the oldest integrity nodes; B. The cadaver meal (the node no longer responds to the task, just acquires mining income).

In each block production, the latent amount function is used to realize the redistribution of the reputation value: the reputation value of the effective node is reduced by the logarithmic function each time, and the reduced reputation value is shared by all the well-behaved nodes. In other words, the reputation value of all nodes will continue to decrease, while those with the most reputation value will lose the most. Therefore, in order to stay on top of Witnet, you must always behave well .

Witnet has its own blockchain network, so decentralized oracle service can be provided through the bridge node. With an interoperability solution, it is possible that (bridging nodes) this mode is not as useful, but before the interoperability solution was developed, it provided an extensible solution that reduced the operation of the chain. Costs and help resolve critical vulnerabilities.

You can find more information at https://witnet.io or read the white paper here.

Oraclize

Oraclize is a centralized blockchain oracle solution provided by a 9-person network security company in London. They have the most widely used and longest running blockchain oracle service in the world. The service supports multiple blockchain platforms (Bitcoin, Ethereum, Monax, Rootstock, Corda and private networks), while the most important customers are on the Ethereum platform.

Their approach is to use all TEE suppliers to reduce vulnerability, a practice known as sandboxing. Oraclize leverages IT vendors and manufacturers' products (including Amazon's EC2, Google's SafetyNet, Qualcomm's QSEE, Ledger's Nano S and Intel's SGX) as key components of their core services. These products are physically separated into separate groups and can be used collaboratively through software: Oraclize has designed a custom program that supports ad-hoc as a software access layer that supports all TEE access and collaboration. When a technical means is affected by a vulnerability (such as Intel's SGX ghost vulnerability), the overall data aggregation can still ignore the affected nodes and get the correct data from multiple other TEEs. (This assumes that the vulnerability is based on a specific architecture, not a generic vulnerability that affects all processors)

To ensure distributed trust and data correctness, Oraclize uses TLSNotary to sign TLS data for https sites. There is a price to do this: Oraclize can theoretically only transfer the data displayed on the website (not uploaded after pre-processing in the chain), but this is enough to cover common scenes. The main risk of the solution is that when most data sources are destroyed, there is no way to prevent the continued distribution of erroneous data, but this risk exists in most “decentralized” solutions. You can find out more about Oraclize here.

Town Crier

Behind this academic project are five teams of doctoral and undergraduate students at Cornell University.

Town Crier acts as a bridge between smart contracts (on any blockchain) and https-enabled websites, and it secures communication between the two through the TLS layer to transmit authenticated data. This solution is different from TLS-notary (just the security of the software layer), which allows for more customized data transfers. Data is decrypted by nodes running on Intel SGX (both hardware and software security levels). The authorization data is eventually sent from the enclave to the blockchain, relying solely on SGX to ensure that the node software is operating as expected.

To ensure confidentiality, message data is only decrypted in the enclave in a trusted execution environment, so it can not only secure data transmission, but also obtain encrypted user credentials (such as private APIs). In addition, it also supports custom requests to crawl multiple targets.

To solve the problem of order failure, their approach is to perform data source aggregation and oracle deployment on multiple SGX platforms. The software has proven to be scalable and can support 15-65 transactions per second throughput.

You can find out more about the Town Crier. In the fourth developer conference on November 1, 2018, CEO Sergey announced the acquisition of Chain Crier by ChainLink.

2. Internal oracle service

A. Forecasting the market

“Predicting the market is like the gaming market. You bet on the outcome and the bet price is determined by the probability of the outcome.”

Augur and Gnosis are the two best known decentralized forecasting markets, both founded in 2015. They use collective intelligence and a less decentralized decentralized network to build an elegant forecasting market. In order to ensure the correct operation of the market, both have to rely on well-designed incentives. We will take Augur as an example for further analysis.

Augur (LIVE)

Augur is a trust-free, decentralized predictor and predictive marketplace that allows geographically dispersed individuals to speculate and report on the objective outcome of any event. For Augur, it is easier to create a decentralized forecasting market. The key is how to ensure the integrity of the market (guaranteeing honesty can be the most profitable choice for rational Augur nodes).

Augur has its own token (REP), whether it is creating a new forecasting project or reporting/arguing the forecasting results, you must first pledge a part of the REP – these will be part of the platform after the forecast event is settled. The fee is used as compensation. The betting behavior in the market is not priced by REP.

– Predicting the life cycle description of the market (source) –

Anyone can create a forecast market for upcoming events on the Augur platform. The creator sets the end time of the event and specifies the reporter for the event result. This result allows acceptance of community questions.

Here are a series of measures that Augur aims to protect honest participants:

• Market creators are required to hold valid bonds : these bonds will fail and return to zero when the market definition is imperfect or if the results are unlikely to be objective and accurate.
• Market creators hold unproductive bonds : When the creator-designated result reporters do not give a result within 3 days, the bonds will lapse. At this point, anyone can submit a temporary result of this event.
• Once an interim result is reported, any REP holder has the opportunity to challenge the tentative result within 7 days (initiating a bid). The bidding margin accounts for the smallest proportion of the forecasted project market value, and the bidding victory can be obtained. Once the bid fails, the pledge of the REP will be returned to the owner; then the entire market enters the settlement.
• If the first temporary result is successful, the next steps will depend on the amount of the quality deposit for this round. When the quality deposit is less than 2.5% of all REP (currently $1.5 million), the market will start the next round of bidding; otherwise (more than 2.5%) will enter the fork state.
• The forked state will last for 60 days, during which all markets will be temporarily frozen until they are moved to an "Augur New World". If all markets have only two options (yes/no, checked/unselected, win/loss, etc.), then 3 worlds will be generated, for example there will be 3 possible truths: one truth is yes , one The species is no , the last one is invalid . The market will be divided into the corresponding world. Users can and can only migrate their REP tokens to one of the worlds. If the user completes the migration of the REP token within 60 days (to one of the results), an additional 5% of the REP can be obtained as a risk compensation. The risk here is that when users move to the wrong world, their REP will be trapped (REP is not interchangeable in the world of A/B/C). If users don't want to take risks, they can migrate after 60 days, and the market has reached a correct consensus. Because the parallel Augur world can coexist (for example: Ethereum/Ethernet Classic), the obvious winner who won most of the market will become the real Augur.

We hope that readers will recognize the dangers of unclear definitions when creating predictive markets, and how weird economic consequences can be caused by decentralized oracles to control the outcome of the broadcast.

When the Augur predictor completes the forecasting of the Augur market by reporting the results of real-life events, we can imagine that the Augur market's results can be used as a reliable predictor when incentives are sufficient and Augur continues to grow. In other words, we can assume that the Augur market will eventually (possibly) give a real result and use it as input to another smart contract.

More information about Augur can be found here.

B. Payment service

Ramp

Bank books have historically been difficult to access externally, but things are changing rapidly, and more regulators are accepting the open banking framework. For example, in Europe, the PSD2 Directive requires European banks to open API access to bank accounts to authorized third-party vendors, and Ramp is one of them.

– (Ismail Chaib and OpenBankProject coverage) –

* Ramp * is building a financial infrastructure to ensure trust between traditional financial institutions and public blockchains to minimize communications. In practice, they use PSD2 to provide p2p's legal currency and cryptocurrency atom exchange service (Ramp Swaps). The process is as follows:

1. The seller creates a smart contract that locks a certain amount of digital assets in third-party supervision. When the buyer sends the legal currency as scheduled, the digital asset will be released to the buyer, otherwise it will be returned to the seller.
2. The buyer pays the seller by remittance.
3. A payment oracle verifies the buyer's payment and sends a payment voucher (PoP) to the network. The oracle can access the accounts of buyers and sellers and check their payment status.
4. Smart contracts unlock assets in third-party supervision and send them to buyers.

The data in the books of financial institutions is extremely sensitive, so reporting such information is an obvious challenge relative to reporting publicly available information (such as commodity prices or sports outcomes):

• Data is provided by a single, trusted source—for example, a bank.
• The transfer information is variable and the financial institution may cancel the transaction.
• Data is not publicly accessible and is not easy to verify.
• The given account information (identity information and transaction history) needs to be kept confidential.
• The books have different access methods and usually rely on the user's permission.
• Two-way communication is not guaranteed to be always smooth – there is two-way communication, and smart contracts can initiate transactions.
• The data is structured—the books are made up of accounts, but the specific organizational structure is different from institution to institution.

Because of the privacy requirements, it is not possible to simply spread the information obtained from the bank to the blockchain. The raw information needs to be desensitized to fit the blockchain transaction. Therefore, the data needs to be sent to the network in a simple yes or no form (eg, whether a transaction is filled?) after processing in the chain.

Ramp is further expanding its technology and making it accepted by more regulators. Ramp is also exploring the use of secure enclaves to act as an additional layer of protection to accommodate more authoritative third parties as oracles to verify bank transactions on the blockchain. These developments will eliminate the biggest centralization needs: the French currency gateway. If you want to learn more about Ramp, please move on to their website.

C. Decentralized insurance

“We trust the code more than a profit-driven insurance company, but if there is no credible oracle, nothing can be said” Hugh Karp, NexusMutual

– Decentralized insurance products provided by Etherisc –

Parametric insurance is a special type of insurance with parameter triggers and payment terms (or $X if Y occurs), such as a late flight, the hacking of the exchange. Obviously, these products are suitable for smart contracts. They require predictive machine services to provide reliable data for these events, either internally through economic incentives (using EtherRisk-defined data entry, or using Nexus Mutual's voting process), or through decentralized predictor services (Oaas) Provider obtained.

It is expected that we will see more and more insurance products handled by smart contracts, especially FlyingCarpet, which utilizes complex IoT sensors, drones and satellites. For example, farmers can purchase insurance through smart contracts, and then the weather satellite transmits the data to Flyingcarpet and is analyzed by the AI ​​model built on its platform.

In some cases, if the input information is not coordinated locally, the results of the declaration will not be automatically detected and processed. In these cases, a local (incentive) oracle is required as an independent claiming agent, such as quantifying the damage of the car. Insurers can take advantage of these agents, which are also easy to add Moog Smart Contracts as their potential employer. This approach has been used in the roadmaps of EtherRisk and Nexus Mutual, which use similar equity designs to punish good. Fraud is usually the biggest cost of insurance. It is impossible to expect that a system can be absolutely free of fraud, but if the smart contract can achieve the reliability of the centralized insurance, the saved success can be returned to the customer.

Ultimately, these declarative agents can work in decentralized autonomous organizations, such as Aragon or Colony to coordinate their respective operations.

V. Conclusion

The opportunities and challenges brought about by the non-tamperable nature of decentralized networks can be summed up in one word: incentives . Through well-designed economic incentives, decentralized networks enable unprecedented global collaboration and ensure that rational participants' actions are in line with the interests of the network. Eliminating reliance on trusted third parties is a challenge, and anything and anyone can theoretically go bad, and the risk must be reduced to a tolerable level. Indeed, the risk of short-term attacks has always existed, but it should not undermine the long-term incentives of network maintainers, who can make huge profits.

Bitcoin mining work is employed and trusted as a whole to be trusted as an “entity” to ensure the security of Bitcoin books. There have been incidents in which miners exploited vulnerabilities for short-term gains, but they are more willing to engage in a rational long-term game to ensure that their ASIC mining investment and block rewards will not depreciate significantly. Furthermore, Ethereum has been criticized for over-reliance on services like Infura or Metamask (which are indeed centralized by Consensys), but because these services have great benefits in Ethereum, they can remain unscrupulous. The risks of these intermediate schemes are tolerable in the further decentralization process.

Interacting with the outside world is the next step in the smart contract, which also requires the deployment of properly designed incentives to avoid attacks. The main challenge here is the misconduct caused by strong economic stimulus. As the network evolves, these incentives will become a huge source of revenue for network contributors. Over time, there will be enough predictive machine service providers in the network and have great benefits, which will reduce the reliance on individual (predictor) nodes while at the same time fully guarantee the quality of service.

The incentives for radish sticks are strong and we look forward to seeing the development of all these projects. ChainLink has been able to get reliable predictive machine services by using token and reputation mechanisms. When we have a predictive machine that can really work, there will be many usage scenarios, the most exciting of which includes decentralized insurance products, financial products, and forecasting markets.

Disclaimer: Fabric Capital invested in Ramp

Original link: https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841

Author: Julien Thevenard

Translation & Proofreading: Anzai Clint, wuwei & Ajian

This article was authored by the original author to translate and republish EthFans.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!