A discussion of the oracle problem

A Solution to the Oracle Problem

The right architecture to safeguard users from oracles permits them to safely exit with their funds

Providing users a way to exit with their value

Would creating an insurance policy where policyholders are able to reclaim ownership of their premiums and walk away be a bad thing? Most people are convinced that such an insurance policy would create a moral hazard among the participants.

This comes from a naive assumption that as soon as someone else would open up an honest claim, selfish policyholders would decide to leave with their premiums. This would effectively give scumbag policyholders one months worth of coverage at zero cost to them (provided that they don’t come back). Some would assume that this selfish behavior would then lead to the systems inevitable collapse given the cost of these bad policyholders.

The point of this post is to highlight that failure to permit users to exit with their value is to fail to use a very important tool in incentive architecture. In decentralized architecture the problem of an oracle going rogue is known as the oracle problem.

Defections are the ultimate tool for keeping oracles honest. They are a powerful check on any oracle which might act corruptly or which might malfunction. They are also a valid means to allow a group to reach consensus. In this way the oracle would be forced to remain honest, because dishonesty could in some architectures prompt a wave of mass defections.

The goal of this post is to show how:

• Allowing users to defect with their value can keep an oracle honest
• The cost of selfish defections can be understood as being reasonably low

In this way defections can be a force for good rather than evil and an important tool for designing decentralized systems.

Rune discusses the oracle problem and Maker’s solution

Episode 28, Creating Stability out of Chaos — Advanced Maker Topics with Rune Christensen, Founder of MakerDAO — Mar 26, 2019

(72m 47s) Yes so the Oracle problem is definitely the number one problem of all decentralized systems. Our approach to solving that problem, which I think we have actually solved completely, is just fundamentally assuming that oracles are going to fail.

So the system fundamentally does not rely on the oracles never colluding or never attacking or never breaking and failing. Rather, it has this has built in defense mechanism that means that even if the oracles do fail or try to attack the system or whatever, whatever could happen theoretically the system is able to completely mitigate that without any sort of major damage happening. That’s just because that (scenario where the system fails) would be unacceptable.

If Maker wasn’t able to completely 100% shrug off an oracle attack, or Oracle failure it just wouldn’t be scalable. I mean it would not be a functional alternative to traditional finance. Because, you’re never going to want to be (willing to) put your money in a bank (where) there’s a small chance that it will all blow up.

That doesn’t work. Regardless of what (the circumstances are) the chance (it will blow up) has to be zero percent.

So the mechanism for protecting against this is twofold. So it is a combination of what we call the Oracle security module which is basically a smart contract that ensures that there is a delay on the Oracle data that’s input into the system.

So when the oracles input data into the system there’s a one hour delay in posting that data before it’s actually pushed into the core of the system logic and has any effect on the CDPs. In that one hour window, there is then an opportunity for the community to perform what we call the emergency shutdown. So the emergency shutdown is basically is the most important feature of the system.

It’s the feature that ensures that the worst thing that can happen to you as a DAI Holder is that you get to redeem the underlying value of your DAI directly from the collateral. From a UX perspective it’s not really a nice user experience in the sense that you don’t want to have to go and redeem collateral for your DAI and all of this stuff.

But, from kind of like a financial perspective and an economic perspective and a risk perspective it’s just incredibly important to have that fundamental guarantee in the system.

And there’s actually various ways it can be improved. There are various ways that the actual UX friction (for the end user can be alleviated). (This) means that in the end like for the system to undergo an emergency shutdown let’s say in the event of an oracle attack really what that just looked like is that if you’re a user of a decentralized wallet, you just have to click a button in your wallet.

If you’re a user of a centralized exchange or some sort of custodian service, you actually don’t even notice because the custodian service just takes care of the transition for you. That’s the basic gist of it. So, if the oracle is compromised, there is a way to basically gracefully shut down the system and mitigate any sort of damage from the tech (by) settling up people at the last honest oracle value.

Content was produced by Wyre Talks podcast, produced by Wyre. For more on this topic please see:MakerDAO Governance Risk Framework (Part 3)

Burning Bridges to Greener Grass: Incentivizing Tokenized Forking

In his blog post Simon de la Rouviere mentions how some systems naturally award defecting early. He doesn’t identify permitting defections as a type of decentralized design choice in this post.

Instead he indicates that defections naturally occur in economic systems and they provide benefits to both the defectors as well as the loyalists or remainers.

An eventual equilibrium will be reached when the bonus to leave is not as valuable anymore vs the value in staying.

Making it beneficial for early defectors to defect not only rewards those defectors in believing their new opportunity is a better choice, it also strengthens the value of the focal point of the existing group (think: “All the non-believers left. Thus, I can believe in those that are still here, more”).

He goes on further to tie the thought of permitting defections as allowing a faster way of reaching consensus by highlighting how it works in regards to signaling theory.

those that stay are actively signalling that (they) aren’t exiting. It thus reinforces the bonds of the groups who are staying. This is also apparent in relationships. Those who stay when they have options, is a strong signal to the partner of commitment.

In a later post he shows how designers of decentralized protocols can consciously use defections to organize participants around a shared goal.

The Moloch DAO: Collapsing The Firm

In another post Simon looks at how the Moloch DAO team consciously decided to build defections into the protocol.

Moloch DAO incentivizes coordination by collapsing traditionally separate parts of a company into one process, and by creating additional incentives for defectors to defect and exit … Making it easier for people to leave reduces coordination costs.

Their whitepaper specifically identifies this as a key part of the architecture:

Game Theory: By allowing Guild members to ragequit and exit at any time, Moloch protects its members from 51% attacks and from supporting proposals they vehemently oppose.

When participants defect it comes at an opportunity cost where they forgo the chance to built out the Ethereum ecosystem

When users defect/exit with capital, they are leaving with profit for themselves, never to return

Coordination about how to use a shared resource has a cost. Moloch DAO seeks to reduce that cost by setting clearly defined rules in a smart contract. These rules become a schelling point to the participants which condition their behavior. If the participants view the proposed actions of the DAO as conflicting with these rules then this might lead many to defect. This might mean that the DAO is held to account to a rigid set of predefined rules. This would limit what the DAO could do but it would also limit the time required for the participants to reach consensus.

How to build communities upon zero-fraud architecture

In a previous blog post I highlight that the same strategy works for effectively vetoing the approval of a fraudulent insurance claim.

The smart contract allows people to make a choice:* Finalize their premium payment by sending it directly to the claimants* Defect with their premium payment and walk away from the Tanda* Do nothing in which case their payment is still sent to the claimants

Providing policyholders with the option to defect allows them to

veto decisions made by a secretary simply by walking away from the tanda with their insurance premium.

A secretary is an oracle which informs the smart contract which policyholder is eligible to receive a claim award. Without the power of defection given to the policyholder the power of the secretary to approve any claim for payment would go unchecked. Used in this way, defections solve the oracle problem because they provide the ultimate protection against fraud for policyholders. Defections guarantee that an oracle (secretary) can never determine that a fraudulent claim will be paid. Even if a fraudulent claim is approved for payment, the power of participants to defect would deny a fraudulent claim from receiving payment.

Now that we’ve established strong guarantees for policyholders, how can we provide assurance to honest claimants that their claims will be paid? How can we make sure that the cost of selfish defections are kept in check?

Guaranteeing that honest claims are paid is determined by the strong social bonds within the community, “the stronger the social bonds are between people in a society, the fewer defections there will likely be.” TandaPay doesn’t seek to create trust that doesn’t already exist within a community.

It simply provides communities tools to negate bad behavior if it occurs. Since the power of dissolving a community is divided equally among all the participants, an exit strategy assures those who approve claims that they will never profit from bad behavior.

Enabling defections has a net positive impact on deterring bad behavior by administrators. The real question is if it promotes more selfish behavior leading to defections against honest claimants? This is where subgroups and overpayments are added to deter bad behavior against honest claims.

The dynamic of overpayments and subgroupsA subgroup is 4–7 policyholders

As discussed in previous blogs, the average initial size of a TandaPay coverage group is 50 people. Since a subgroup is between 4–7 policyholders, this implies that the average number of subgroups per TandaPay group is likely to be around 10.

Overpayment: This is effectively a bet that no one in your subgroup will become scumbag defector (defection against an honest claim). This bet is anywhere between 33%-16% of a users premium and you always get it back if one of the following conditions are true:

• You become a defector
• You have zero defectors in your subgroup in a monthly coverage period

Subgroups: Groups of 4–7 TandaPay members who impact each other when one of them decides to defect. The penalty of single defections is incurred via the loss of a groups overpayments. All the overpayments in a subgroup equal one full payment. To be allowed to participate in coverage you must join a subgroup.

When combined together these two effectively encourage a group to defect or remain together as a group. A scumbag defector will cause their friends to loose their overpayment, but the overpayment prevents a negative financial impact to the honest claimant.

The friends therefore have adequate incentive to be upset at the scumbag defector because they decided to remain in the Tanda. But the penalty is not so large that the friends will decide to beat up on their friend for being a scumbag defector.

If fraud occurs and this becomes known to the group, the group should reach consensus to defect together. If an entire subgroup defects together then everyone gets both their premium payment and overpayment returned to them. This incentivizes a shelling point around their being either 0 defectors or everyone defecting.

Sustained cooperation by running away from bad behavior

This is a title of an Article in Evolution and Human Behavior · January 2016 which reached the following conclusion

Conditioning one’s current behavior … was a pattern almost entirely due to players who had recently cooperated.

In other words they found that participants were more willing to cooperate in a persistent environment of cooperation. So if we can create architecture that permits defection but conditions cooperation then cooperation should win out.

Conclusion

Defections provide a powerful check on oracles. Overpayments and subgroups provide a powerful check on defections. These work together to provide strong guarantees to both policyholders and claimants.

A discussion of the oracle problem was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.