Starting with the creation of platforms like Hyperledger, there has been a lot of excitement around the idea of putting real world assets ‘on the blockchain.’ In fact, this concept has really served as the core of the whole ‘blockchain not bitcoin’ movement. At this point, I'm sure many of you have taken part in a conversation that goes something like: “I don’t know about this whole ‘bitcoin’ thing - look at what its price has been doing over the past year! Blockchain as a technology sounds interesting though. That might be something I can get behind.” And yes, there are exciting use cases for blockchain that extend beyond Satoshi’s original vision of secure peer-to-peer cash exchange. But there are a couple of problems with the whole 'blockchain not bitcoin' narrative. First of all, saying you believe in blockchain but not crypto is a bit like saying you believe in the internet but not websites. Technically there are other ways you can use the internet (communication, information transfer, etc…)... but why wouldn't you use websites? Crypto and blockchain are fundamentally related to each other, and for reasons described later you really can't completely parse one out from the other. Secondly, and more importantly for the purposes of this article, there is a massive unsolved problem with translating real world assets onto a blockchain. We'll refer to this as "The Oracle Problem."
There is No Spoon
To understand the heart of the issue, let's do a quick review of the fundamental innovations introduced by blockchain. With the way the media covers blockchain, it can be easy to forget what this technology really is (which is NOT a silver bullet solution for any and every problem under the sun). Blockchain is a database technology that A) eliminates a single point of failure within a network and B) eliminates the need for a trusted third party to verify transactions. A single point of failure is eliminated due to the decentralized security architecture of a blockchain system. So, for instance, if a malicious party wanted to corrupt or otherwise alter information on a blockchain, he or she would have to overpower the majority of nodes in the system rather than just one central source. The need for trust is eliminated by a particularly clever bit of code that does not allow participants in a blockchain system to 'double spend' or transact in items they do not possess. You can check out a more complete explanation for how blockchains accomplish this here.
This all works very well for digital assets that have no real world correlates. The issue is that when we want to track physical assets on a blockchain, we need a robust solution for 'translating' these items into a digital state. Once the real world items are recorded onto a blockchain, they can be interpreted by smart contracts. And this is where we arrive at the need for an oracle.
The best way to conceptualize an oracle is a gateway between the real world and the world of a blockchain. Their purpose is to be a ledger for real world data that a blockchain needs to execute smart contracts. Maybe it would be helpful to use a concrete example of when an oracle would be necessary.
A Concrete Example
Let's say you are about to move into a new apartment in New York City and you have to pony up the cash for a security deposit. Rather than leaving that deposit to your landlord's discretion, the two of you decide to put the funds into a multi-sig wallet governed by a smart contract. The two of you get a lawyer to design a smart contract for you (this is a very digitally savvy lawyer who can write code) that will govern the terms for how this account pays out. You both agree on specific criteria that must be met in order for you to receive your security deposit (i.e no holes in the wall more than half an inch in diameter, no major paint discolorations, etc...). Then you shake on it and move on with your lives.
One year later, you decide to move out of your apartment and you revisit the smart contract between you and your landlord. What's the first thing you need to do? You have to determine if the criteria that you spelled out in code was followed in the real world. In this case, you need to physically check whether or not the stipulations you laid out (no holes in the walls, paint isn't messed up) were followed. The state of your apartment then needs to be translated into the digital world so that the smart contract that is in charge of your joint account understands how to distribute the funds.
Some of you might be starting to see the problem here. Remember, the primary innovations of a blockchain are A) no single point of failure and B) no need for trust. In this example, you can see that whatever system that translates the physical state of your apartment onto the blockchain is indeed a single point of failure. Suddenly, if a hacker wanted to corrupt the details of your transaction he wouldn't need to compromise the integrity of the blockchain, just whatever oracle you're using.
Now let's look at the need for trust. What is to stop whoever is doing the inspection of your apartment from lying? What if you had kept your apartment in pristine condition, but the person doing the inspection inputs dishonest information? The multi-sig wallet you have would then pay out (unfairly) to your potentially crooked landlord and there would be nothing you could do about it. Suddenly, we have the need for trust in a blockchain environment.
What's the Solution Here?
As of now, the jury is still out on a viable solution to the oracle problem. It's true that no one has found a solution as of yet, but there is a MASSIVE amount of talent and resources currently flowing into the blockchain ecosystem. So, if you ask me, it's just a matter of time before someone cracks it. Joey Krug and the team over at Augur have been working hard on a promising decentralized answer, which I definitely recommend checking out. What I think is interesting about a decentralized solution is that it probably wouldn't be viable until you have a sizable network of users. Essentially, the larger the network of users that are voting, the harder it would be to coordinate on an incorrect result. I think there's a possibility this dynamic could amplify the impact of the network effect and represent a sturdy moat against future competitors.
What is maybe MOST interesting about the oracle problem though is that no one is really talking about it! Least of all the folks who are are leading the charge of the whole 'blockchain not bitcoin' movement. Significantly, (and thank you to Jimmy Song for pointing this out) even IBM has yet to solve this issue. The Hyperledger, IBM's much toted blockchain solution, uses an oracle-like entity that they call their 'ordering service.' It's an innocuous enough name, but that doesn't change what it really means. So, as of now, Hyperledger does in fact have a central point of failure, which basically eliminates half of its value as a blockchain solution.
We'll have to wait and see what the leaders in the cryptosphere come up with. I have no doubt that a solution exists, it just may take a little while to crack. Maybe it ends up being the case that we need to compromise some degree of security, which is an answer I know bitcoin maximalists will hate. The reality though is that there are no perfect solutions. The world is a subjective place, which is simultaneously what makes purely objective systems like bitcoin so brilliant but also (probably) not ultimately scalable.