FinTech

How to Build Truly Decentralized Oracles, and Why We Need Them

By Sam Kim, founding partner of Umbrella Network

There is something good growing among us. In the coming years, it will remove a layer of intermediaries that controls our most precious assets, governs our access to our own data and charges us for the privilege in a variety of ways. This group of technologies will change the way we bank, transact, borrow and save. They will let us interact with each other directly and trustlessly. Collectively, these applications are known as decentralized finance, or DeFi. And if you haven’t heard of them yet, you will. 

When most people think of blockchain technology, they equate it with Bitcoin. But a few years ago, with the advent of Ethereum and smart contracts came the ability to program the blockchain to perform actions far more complex and potentially far more beneficial than just sending and receiving crypto funds. DeFi projects are visceral examples of this transformation. 

DeFi applications essentially perform a market-making function, but unlike traditional lenders, exchanges or insurers, they use the blockchain and smart contracts to provide these services transparently, peer-to-peer, without involving banks or other central authorities. As a result, they have become hugely popular, exploding over the last year from a tiny industry to one eclipsing over one hundred billion dollars in value as of the current writing. 

But in order for DeFi applications to work and to provide value to people and organizations around the world, they require information from the non-blockchain world -- like pricing data for derivatives or weather information for insurance contracts or, really, almost anything you can imagine. Without access to accurate data, these applications would be of little use. This is what oracles do -- they serve as connective tissue for accessing, processing and transmitting critical data. But not any kind of oracle system will do. To ensure the integrity of the data, they must be fully decentralized.

Perhaps the easiest way to explain oracles is that they are analogous to the application programming interfaces (or APIs) that traditional applications use to retrieve data. For example, let’s say Kayak wants to retrieve flight schedules and prices from a number of different airlines. By accessing the APIs for those airlines, it can easily retrieve that information to share with its clients in real time. But for a blockchain-based project looking for the current price of BTC/USD, the information provided by API endpoints is unusable. Oracles solve that problem. They verify, query, and authenticate those external sources and then make the data available on the blockchain. 

As we learn about oracles, it’s very important to recognize that although all of them aspire to be the bridge that connects vital external data from the existing web to blockchain-based based applications, they don’t all function the same way. Some oracles are not blockchains themselves and don’t benefit from blockchain’s internal economics. The ones that are have different architectures, different ownership, and different consensus mechanisms. Decentralization is important in the context of oracles because while oracles allow DeFi smart contracts to take inputs from the outside world and enable endless use cases, they can also pose a huge structural risk. Oracles with centralized formats have the vulnerability of a single point of failure. If their central authority makes an error or becomes corrupted, the entire system is at risk. Many existing oracles describe themselves as decentralized and, technically, they are, but as in anything, the devil is in the details. When you dig in, you find that some oracles are more decentralized than others. 

For example, the most well-known oracle networks retrieve information from a variety of different outlets. Their validators vote on which data points will be added to the feed it sends out. In that sense they are decentralized. However, in some of those systems, a central authority chooses certain data sources and rejects others. It’s not trustless because users must first trust that the oracle has picked the right data providers and second, they must trust those providers. 

Data sources are just one of the places where the details matter. A decentralized oracle must include a group of independent oracle nodes. But merely integrating a group of oracle nodes is not sufficient to meet the level of decentralization required to provide high quality data. To avoid the vulnerabilities discussed above and fulfill the basic promise of blockchain’s peer-to-peer technology, a truly decentralized oracle network must be one where the data sources are chosen by the community, validators are elected by the community and the rules around staking, including rewards and slashing penalties, are set by the community, not by a central authority.

The ideal way to ensure that oracle nodes operate independently and with integrity is for the oracle itself to employ a delegated proof-of-stake (DPoS) consensus model on its own blockchain. This model allows everyone holding the native tokens of the network to elect representatives to govern it. As a result, those governing the network are beholden to the community, not private investors or other stakeholders. A DPoS protocol is also constructed so that all participants of the network are economically incentivized to accurately validate the data they provide.

But if full decentralization is such a clear solution, why doesn’t every oracle adopt it? Like many things, decentralization is easier said than done. Decentralized structures are difficult to execute in a way that is efficient, cost-effective, and scalable enough to support fast-paced next generation applications. To make the solution scalable, before being brought on chain, the data from all of these nodes must be aggregated, validated, and formatted to respond to on-chain requests for that particular data point. One innovative solution is to utilize a system of Merkle Trees to bundle multiple transactions into a single hash. Applying this Level 2 solution, each node would be able to validate thousands of transactions for the price it would normally take to validate one transaction on other networks.

The optimal oracle architecture described here would satisfy blockchain applications on both security and scalability grounds. It would have a fully decentralized architecture but also provide a secure, lower cost solution that promotes high volume scalability as well as a broad diversity of data. The end result would be a robust, decentralized oracle service that is economically viable and scalable. 

The potential of decentralized applications is limitless and oracles are an essential part of enabling them to democratize our institutions. The key is to implement them in a way that doesn’t undermine the most important part of the revolution they promise.

About Umbrella Network

The Umbrella Network is a scalable and cost-efficient decentralized oracle supporting the blockchain and decentralized finance (DeFi) ecosystems. Its Layer 2 solution leverages the latest advances in Merkle Tree technology to consolidate multiple data points in a single on-chain transaction in order to ensure secure, cheap, and accurate data for smart contracts. Learn more at https://umb.network/

The views and opinions expressed herein are the views and opinions of the author and do not necessarily reflect those of Nasdaq, Inc.

Other Topics

Blockchain