How Flux Compares to Other Leading Oracles
A Comparative Framework Overview of Blockchain Oracles
While blockchains remain incapable of perceiving the world around them, there is no shortage of interfaces that not only enable them to see the world but also react to the outcome of specific events based on predefined conditions. These interfaces, known as oracles, feed data from external sources to the blockchain, drastically improving the capabilities and utilities of the technology through smart contracts.
With no one blockchain or consensus to rule them all, oracles platforms have been more or less as diverse and varied as the industry they serve. In this article, we will explore prominent oracle platforms and their approaches based on the following criteria:
- Network Model: Undoubtedly, blockchain-based oracles are susceptible to the same Sybil attack and collision risks inherent to the technology they are built on. The fact that running and maintaining most oracle services require specialised knowledge further exposes oracle service providers to centralisation risk. With this in mind, it’s imperative that the network design and implementation of oracles focus strongly on the reliability of data and the decentralisation of data providers. To do this, some oracles aggregate results from multiple oracles using the same data source or event, however, with large data streams this may increase the cost for users and also result in scalability issues.
- Security: Due to the pseudo-anonymous nature of most public blockchains, users tend to enjoy a high degree of anonymity on the network. If they avoid centralized exchanges and comingling addresses and assets, it becomes almost impossible to discern ownership and identity. This often leaves counterparties at the pointy end of a very sticky situation with nobody to hold accountable should something go south. The interaction between a nondescript on-chain actor and an unknown, off-chain data source is a fertile ground for a myriad of attack vectors from both ends.
- Data Source: Given time, there will always be a definite outcome to every event. If the outcome or a measured representation of it is stored, any oracle can fetch and relay it. However, data sources are often a hodgepodge of databases, sensors, human sources, other smart contracts, or a mixture of everything. To retrieve the true outcome, also known as the ground truth, Oracles must be able to verify truthfulness, be tamperproof, eliminate human errors, while filtering out noise from the source.
- Dispute Mechanism: When it’s all said and done, oracles are only as good as the quality of their final output. Therefore, safeguarding the truthfulness of that final output is critical to the reliability of the oracle and the robustness of the network. Implementing a dispute system not only safeguards the integrity of the data but may also eliminate the insertion of bad data. This can be further strengthened through economic incentives that gamify the dispute resolution in such a way that the cost of inserting and defending bad outcomes becomes prohibitively expensive with most of the fees paid by the bad actor (if not all of it) going to those that reported the bad data once the dispute is resolved.
- Accessibility: Due to its technical requirements, participating in most oracles’ ecosystems is often an intimating prospect for the average blockchain user. While this ensures that network participants are able to carry their own weight and contribute to maintaining network liveliness, it has the unfortunate side-effect of drastically deterring much of the external ecosystem from participating. However, not every module requires technical input. Interface whitelisting for data services, dispute resolution by staking on the correct outcome, registry curation, and delegating to known stakeholders to ensure liveliness are some of the features that could make the network more inclusive to the broader community.
As the first mover in the space, Chainlink has capitalised on its advantage as a pioneer to become the most widely used oracle resulting in a slew of partnerships and an enthused community. Chainlink successfully eliminated the single point of failure that had been plaguing the industry, leveraging credentialed data sources and aggregating results from multiple sources.
Service providers run nodes on a decentralised network to fetch and query data. Because the network isn’t its own native blockchain, Chainlink can quickly deploy across different blockchains without worrying about breaking consensus at the protocol level or tasking validators with also securing the blockchain. However though the network is decentralised, governance of the protocol remains centralised and its aggregation of data from multiple sources have led to claims of data redundancies.
Pivoting from being a token on Ethereum to its own custom blockchain within the Tendermint ecosystem, Band Protocol aims to position itself as a heavy-duty oracle at the heart of Cosmos’ Interblockchain Communication (IBC) protocol hub. IBC allows blockchains that have implemented the protocol to communicate with each other, bridging previously cut off environments.
By placing itself in the centre of this intersection through its own chain, BandChain, Band is unifying oracle data services and its accessibility, eliminating the cost and maintenance of multiple nodes across different chains. However, this also saddles validators with additional work to secure the blockchain by producing and validating blocks. Every node on the network is also expected to have access to the same data regardless of purpose due to the protocol’s inbuilt randomness. As the network state grows, so will the time it takes to sync and hardware requirement.
API3 is taking a different approach to oracle services by having the primary data source as the oracle data provider and providing them with an interface to connect to blockchains and smart contracts rather than relying on nodes to fetch the data from the source. By allowing first-party oracles to connect to on-chain data feeds, API3 aims to eliminate the centralisation, collusion, and manipulation risk associated with the existing system, banking on the real-world reputations of first-party oracles to ensure truthfulness.
API3 token holders can stake their token on the network, however, instead of also serving as a bonding mechanism for nodes, it only allows the users to share in the protocol’s operational risk while also incentivising them to minimise the risk and participate in the governance of the protocol.
Tellor launched a novel Proof-of-Work (PoW) model as an ERC20 token on Ethereum where data requests are turned into a PoW challenge and the requested data is returned as the median of the result fetched by the fastest five to solve the challenge. Every data request has a bounty that goes to the miners providing the data. Miners are also rewarded in TRB tokens for solving the PoW challenge. This challenge gets increasingly more difficult as more miners join the network and compete to fulfil data requests. The difficulty is meant to make the network extremely expensive to attack as it matures.
Predominantly regarded as an Ethereum-based oracle, Tellor is now pivoting to a cross-chain ecosystem through its v2.0 release, TellorX. TellorX changes the consensus from PoW to PoS, inheriting most of the salient features of current PoS systems including vote delegation, slashing, and asset bonding.
Flux Protocol is a blockchain agnostic oracle platform. Validators have to put up bonds to stake on the right data request outcome on the network. Though the outcome with the most bond is recognised as the right outcome, anybody can challenge this outcome by staking on a different outcome triggering an escalation game where the bond requirement cost for challenging outcome follows a geometric sequence for each successive round. Once the dispute is resolved, those who staked on the right outcome are rewarded from the bond put up by the wrong outcome.
The protocol’s approach to data services is more of a reflection of the interoperable evolution of the industry. Rather than being yet another entrant into the increasingly competitive oracle space, Flux Protocol allows users to also connect their existing oracle solution to the network. This way users can leverage Flux Protocol as a backstop for arbitrary data requests.
Read more on the Flux Blog!