The “Oracle Problem” isn’t a Problem, and why Smart Contracts makes Insurance better for everyone.
One of the many criticisms of the usefulness of smart contracts is known as the Oracle Problem. Plainly put, because a smart contract has no knowledge of reality it has to rely on a truth source, aka “an oracle” for it to receive external data. The “problem” is that while the execution of the contract may be trustless, as Jimmy Song puts it “A smart contract that trusts a third party removes the killer feature of trustlessness.” I believe this is wrong for a number of reasons:
Most importantly- the framing of the “oracle problem” as a problem for smart contracts is similar to saying that the speed of light is a problem for space travel, i.e. it’s a fact of reality that makes certain things impossible, but doesn’t disqualify the endeavor entirely. Any computer system cannot have knowledge of the outside world without some sort of I/O (input/output). As those of you with functional programming experience know, whenever you take input, or produce output, you leave the realm of mathematical certainty and enter the non-deterministic world of reality. But here’s the thing: a program isn’t very useful if it can’t produce input or output. If you’re not a logician or work on an assembly line, chances are you don’t use any programs that are completely deterministic. The oracle problem is just a statement that, at some point, you need to trust some outside source to accurately give input as to what the state of reality is. With different forms of I/O, from keyboard, to monitor, to network, to hard drive we’re always engaged in a fractal of trust relationships with varying levels of risk.
It’s also pretty easy to figure out if an oracle is bad, it’s way harder to figure out if accounting is wrong. Let’s take a sample insurance contract. The contract is simple: if your house burns down pay out $500,000 to the owner. Now I want you think of what elements go into this contract. There are basically three: check if the policy is active, check if the house burned down, and if it did, pay out the policy holder.
Let’s think about, in the current traditional system where the failure points can be. The first issue is the bank account, which bank account should the insurance company pay? Is the policy still active? Has the user paid their premiums? Is the person making the claim the one who owns the policy? Can the insurance company even afford to pay out? Only once all of these are answered, can they actually get to the meat of the issue: Did the house actually burn down? In that case they poll the local fire department to, confirm, yes, the house did actually burn down.
Let’s compare this to a second scenario that uses a smart contract: Because the smart contract keeps track of payments, has an address to dispense funds, and has built in state, it is only a matter of the local fire station pushing a state change, for the policy to activate and the payout to be made instantly to the individual. In fact, this makes an insurance agent completely unnecessary as the the fire department could simply push the state change directly, and give the funds to the victim as soon as possible.
If you believe the oracle problem is a problem, you would say “Well, the fire department could lie and fraudulently say your house didn’t burn down when it did.” Well, that’s more of an input/output problem than the contract’s problem. The contract can still be valid, and useful for maintaining the logic of the policy, even if your input, the fire department isn’t working. In fact, this is similar to saying that your program is broken because your keyboard isn’t working, for example it always inputs Y when you press N. The problem isn’t the computer or the program its running, it’s the keyboard which is providing the data, and like a bad oracle is easily replaceable.
What I personally like so much about smart contracts is that it isolates state changes, and makes it very clear when you are trusting an individual rather than a machine. If I am waiting for a claim to be processed, I don’t know if I’m waiting for a money transfer to go through, an agent to investigate, or if the insurance company doesn’t have enough funds to pay me out. The beauty of a smart contract is that it eliminates all of those other factors, and leaves only the input from the oracle as the factor. I can clearly see if my local fire department contradicted me and said my house didn’t burn down.
In fact, with Ethereum, everything the oracle does is directly tracked via the blockchain, so if an oracle makes a string of bad calls, the community can very clearly isolate them as being fraudulent and shun them from future smart contracts. Or have substantial evidence to sue the oracle in a court system, much the way we do today for insurance fraud today.
The solution to the oracle problem is always social rather than technical. As users of smart contracts we need to understand who our oracles are and hold them accountable for their role: taking information from reality and putting it into a digital realm. Sometimes mistakes happen, unintentional, or malicious, but to say that the oracle problem makes smart contracts unnecessary, is ridiculous in my opinion, and ignores the benefits of smart contracts for managing the complex arithmetic of receiving and dispensing payment under certain conditions.
If you’re interested in learning more: see AXA’s Flight Insurance contract that leverages all of these factors right now for flights in Europe:
