Web3 Oracles: Finality & The Cost of Latency

Without fast finality, the price of assets may change quicker than the refresh rate of oracle feeds, meaning that transactions may fail or be executed with stale data, resulting in lost capital for users.

The digital and analog world need to be on the same page if DeFi protocols are to function as intended. Blockchains function trustlessly according to algorithmic imperatives as closed networks, and they often do it well. That is, that their native ledgers are public and immutable, but only store and transmit data internally, making them closed networks.

For example, the Bitcoin network keeps a ledger of Bitcoin transactions and addresses; it does not keep a ledger on who is winning the NBA championship series, or have any information on Ethereum’s transactions, or any other blockchain’s ledger data, for that matter. Once dApps are developed to allow for the minting and trading of off-chain assets, these blockchains must find ways to secure that data and keep it constantly refreshed. Therefore, oracles must be trusted to provide accurate, secure, and timely data in order to know exactly the right moment to execute transactions based on off-chain data.

Oracles retrieve, authenticate, and constantly update external data for blockchains to use in the execution of on-chain smart contracts. For example, oracles can be used to settle wagers on Augur in betting on sports outcomes when the appropriate conditions are met offline; once the oracle signals the off-chain conditions to the smart contracts its data feeds into, the appropriate transactions are then carried out according to the blockchain’s algorithm.

To further illustrate, oracles can track the stock price of Tesla or MicroStrategy, and trigger limit orders on an exchange which deals in synthetic assets, meaning that one can trade the aforementioned stocks in their tokenized, crypto-asset forms. You could say that oracles make off-chain data, like the results of an NBA game, interoperable with on-chain data, like smart contracts.

Reaching Fast Finality Is Crucial

Oracles refresh their external feeds periodically to check on real-world conditions, take smart contract price requests, confirm data veracity, and finally form a consensus among their nodes before signaling to the requested smart contract that their conditions have been met. This precipitates the contractual algorithms to execute and trigger the release of assets to all parties involved. Clearly, oracles need to constantly refresh themselves and keep price deviations to a minimum. 

DeFi protocols are thus faced with tradeoffs when choosing which oracles to run their nodes: including both security and speed, among others. The problem essentially boils down to the consensus algorithm of various oracle nodes and the underlying blockchain which executes the contract at the base layer.

In most cases, there must be a threshold consensus among the oracles’ nodes to validate the off-chain data and subsequently trigger the execution of an on-chain contract, but if it takes too long to validate requests, off-chain conditions might change. This can cause deviations between the intentions of smart contracts users and the actual outcomes they experience. More will be covered on slippage in a later section. 

Another important concept to understand regarding the consensus mechanisms of oracles is that of finality. Finality here refers to the point at which an already-confirmed block either cannot be reversed or is too costly for malicious actors to do so with agency. Finality is an important concept for users exchanging digital assets because it provides parties to a transaction clarity regarding the ownership of assets following its execution.

Furthermore, if there is a long enough time-lag between a transaction and its reaching a state of finality, there could be legal disputes over property ownership at a specific moment in time or if assets were legally transferred or not. If oracles either do not provide full finality or otherwise take too long to reach such a state, then they may not be considered suitable for Web3 applications. 

To further delineate the concept of finality, it is important to comprehend both probabilistic and absolute finality. Probabilistic finality is found in the proof-of-work blockchains like Bitcoin and Ethereum, and essentially means that a single block does not manifest finality, and so it is recommended to wait for multiple blocks to be produced before confirming a transaction.

Probabilistic finality is the reason Bitcoin users experience hour-long wait times for transactions, since several rounds of blocks must be confirmed before funds may safely be released. This, of course, is not suitable for transactions which require the speedy exchange of assets or most practical applications.

On the other hand, absolute finality tends to be found on proof-of-stake (PoS) blockchains, and provides finality along with each block produced on-chain. These blocks cannot be reversed, and thus do not necessitate multiple rounds of block confirmations in order to ensure finality. It is a democratic system in which a leader proposes a transaction and a majority must vote for its confirmation with typically a ⅔ consensus. These blocks are produced in as little as 3-6 seconds and may make more practical sense for use by oracles, if they can hold up to security and centralization threats. 

Volatile Assets: Liquidity, Latency, & Slippage

For users placing their capital at risk on a DeFi protocol, they may require rapid liquidity for transactions, particularly in cases where assets of fluctuating value are exchanged. This would be especially useful when exchanging volatile crypto assets on a DEX like Uniswap. If a transaction were initiated based on the specific pricing of assets, and there was a significant time-delay between the initiation and execution of the transaction, slippage would occur.

Slippage refers to the phenomenon in which traders are not able to execute desired transactions due to periods of high volatility or network downtime, or a combination of both. In small transactions, this can be tolerated; when the transactions are in the millions of dollars, every basis point is significant.

So why can’t oracles deliver price data quickly and securely? In short, for validation to be done quickly risks the integrity of the data. If oracle nodes are not validating their information with other nodes on the blockchain thoroughly, corruption of one or more nodes might be exploited; this would leave users vulnerable to losing their capital by being liquidated unjustly or other highly negative side effects. A major critique of status quo oracles is the threat of validator node collusion, in which operators find ways to game the system.

There may not be collusion taking place at this specific time, but unless a system is designed to make this sort of behavior impossible, collusion will inevitably become manifest if given enough time. To reduce corruption, nodes should be rotated and selected randomly each time so they can’t ‘know’ each other, and must therefore be randomly reshuffled after validating requests. Unfortunately, this may not be the case with status quo oracles as of Q4 2021.

At present, this means that nodes may either be actively validating data or become unavailable following validation while they randomize themselves again. This, of course, means that the oracle protocol suffers from downtime, slowing down validation speeds, and potentially resulting in slippage from price inaccuracies derived from the aforementioned time lag.

Other oracles simply use federations of ‘trusted nodes’ which should provide reliable data based on a set of deterministic economic incentives. Ideally, oracle nodes would be able to constantly randomize themselves while also maintaining a high data throughput as they refresh their API feeds without downtime. Such a protocol would reach a rapid global consensus, minimize latency, and retain its decentralized properties. 

Latency, or time-lag, is indeed a critical factor that currently requires workarounds like using price aggregates, in the case of Chainlink, but has the potential to bring significant losses to DeFi users until oracle bottlenecks improve. If, for example, oracles cannot effectively track the price of a volatile asset and fail to fill orders placed on the protocol, it would be rendered useless and bring devastating losses for its users. The success of DeFi applications may thus hinge on the success of oracle developers in securing this technology. 

Chainlink & Verifiable Randomness Functions

Chainlink’s Verifiable Randomness Function (VRF) has been able to generate randomness designed for smart contracts through a complex series of on-chain signature and proof verification requests. The VRF system has fundamentally prioritized security and transparency over speed, thus limiting its usefulness for time-sensitive applications.

Therefore, VRF is most suitable for the assignment of NFT prizes and other blockchain-based games, the generation of random tasks or duties to individuals (think jury duty), or selecting representative samples of larger populations for consensus mechanisms (like picking nodes for price feeds). 

Essentially, Chainlink receives a seed from a smart contract to generate a random number, and its oracles generate that randomness in response using their own secret keys. The random number is then written on-chain and verified by the oracles’ public keys along with the original seed from the contract request. This function could also be used to effectively randomize the node validators chosen for price feed requests, adding an element of decentralization to the protocol. 

On Chainlink, if a node is compromised, it would be unable to supply false data. That is to say, that the ledger would reject either the failed validation of the smart contract seed and public encryption key. At worst, nodes may only fail to reply to a validation request. In such circumstances, its non-response subsequently becomes permanently recorded on the blockchain, the node operator receives no crypto reward, and suffers reputational damage as smart contract users would subsequently avoid using the identified nodes. Conversely, node operators of integrity are financially incentivized with LINK tokens for providing consistent and accurate validations.

The aforementioned incentives-based system seems logical on the surface level, since it mirrors the kind of reputational, trust-based systems humanity has known in our fiat, legacy economies. Certainly, status quo oracle providers have leveraged the immutability of various blockchain ledgers to galvanize and perpetuate honest node validators. However, blockchain purists and decentralization advocates argue that trusting incentives flies in the face of the burgeoning, trustless “cryptoeconomics” of the next generation.  

Needless to say, Chainlink operating on the Ethereum base layer is not only costly, but creates a significant time-lag in which the price feeds coming in from each node may actually deviate from the real world spot price. It is industry standard for nodes to deviate between 1-5% depending on a number of factors, including price volatility among others. Such price deviations could either cause traders to miss their trades on limit orders, falsely trigger smart contracts to execute, or force-liquidate collateral, resulting in heavy capital losses. 

Crypto veterans know very well that a lot can happen to prices in just a few minutes, not to mention some sort of black swan event such as a DDoS attack against either the nodes themselves or the already-congested Ethereum network. Chainlink protocol therefore uses price aggregates with lag times measured in the minutes, hoping that the aggregation of many sources will keep their oracle spot price deviations to a minimum.

Another consideration is that Ethereum uses a probabilistic finality consensus mechanism. If, for instance, oracle nodes provide latent price data based on a reversion of the blockchain, legal liability is not entirely clear since the system functioned precisely as it should, despite creating headaches for unfortunate users.

Practical Byzantine Fault Tolerance & Rapid Finality

Band Protocol seems to have opted for speed as a priority, as transactions reportedly settle in just 2-3 seconds per block. This is due to the faster block production on its native BandChain based on a Cosmos-SDK Tendermint blockchain. Cosmos is a network of parallelblockchains using PBFT consensus algorithms for speedier node validations.

Cosmos uses the term ‘parallel blockchains’ to describe its inter-blockchain communication abilities at its hub, while independent chains run parallel to each other. It may be better described as a blockchain train station or airport customs checkpoint (not as pithy, unfortunately). As for its PBFT PoS consensus, the developers set a threshold at around ⅔ for the number of validators to form a consensus and validate a new block on-chain. 

Ethereum is, of course, notoriously congested and the network on which Chainlink is most commonly deployed. Another key difference is that Band utilizes open APIs and does not curate trusted nodes for smart contract users, as opposed to Chainlink which connects with private APIs as well as paid, centralized APIs and whitelists its preferred nodes. Instead of creating a whitelist of trusted node operators, all Band nodes are trusted and provide data to the protocol. This adds to the decentralization of the network, though there have been concerns raised regarding the quality of some of the nodes.

Furthermore, though Bandchain escapes the high fees and congestion of Ethereum, its throughput is nevertheless limited. In fact, the Tendermint BFT consensus has an upper bound of 100 nodes to service oracle data queries, and multi-chain support relies on a yet-to-be-released token bridge under development by Cosmos IBC. Consequently, Bandchain has scalability issues even more detrimental than Chainlink currently suffers from by operating on Ethereum’s main net.

Therefore, Bandchain is likely to suffer from bottlenecking under high volumes of data requests or potential DDoS attacks. Bandchain’s increased block speed does not compensate for its shortcomings and therefore has yet to overcome the market dominance of its rival. The market is wide open for a faster and more secure competitor to enter the space.

Conclusion: Need for Speed

The top oracles both provide price-feed data to smart contracts through APIs, but the real action takes place in how each protocol sets its priorities. Chainlink offers a robust and secure network of oracle nodes built on the Ethereum network, but its consensus mechanisms and layer one blockchain (ETH) has scaling and congestion issues, creating significant time lags unsuitable for time-sensitive price feeds.

It has also been heavily criticized for using a limited number of trusted nodes. On the other hand, Band Protocol uses a faster blockchain at its base layer, and utilizes a quicker PBFT consensus mechanism, which suggests its developers have decentralized exchanges (DEXs) in their sights as their fluctuating prices demand the data be constantly refreshed, though its oracles are mostly centralized and run by their own foundation at this point.

An alternative to the status-quo solutions would make better use of decentralized nodes selected via cryptographic randomness, where LINK is deficient, and use a more efficient blockchain without the limited scalability of Bandchain or Ethereum. It would also offer a more thoughtful incentive system which prevents the monopolization of power by node operators and perpetuates affordable and efficient throughput at the base layer.

In other words, instead of punishment for malicious behavior, better make malicious behavior impossible. Such an oracle provider would deliver near-perfect off-chain data to smart contracts sans network downtime or centralization issues. It should also provide quick and absolute finality in order to reduce uncertainty when the transfer of volatile assets is taking place. 

Finally, the tokenomics must be reasonably conservative in order to avoid spooking investors or creating hyperinflation, driving capital away from the protocol. That is to say, that the ideal distribution of governance and node incentives must create safeguards for perpetuating stability in the power dynamics either at both the base layer and oracle itself. It should also avoid high energy consumption consensus methods found in PoW.

Instead, a PBFT consensus mechanism paired with robust decentralization safeguards built into the incentive structure would be more philosophically congruent with the trustless and decentralized ethos of Web3 culture than what is currently on offer, not to mention provide more legal clarity for disquieted investors to deploy capital.

References

1. Abadi, J., & Brunnermeier, M. (2018). Blockchain economics [Working Papers, 25407]. Princeton, NJ: Princeton University.
2. Band Protocol (2020). BandChain whitepaper. Band Protocol Documentation.
3. Greene, R., & Johnstone, M. N. (Eds.). (2018). An investigation into a denial of service attack on an Ethereum network. In proceedings of the 16th Australian Information Security Management Conference (pp. 90-96). Perth, Australia: Edith Cowan University.
4. Smart Content Publication. (2020, 8 Aug.). Band Protocol and Chainlink: A comparative analysis. Medium.
5. Wall, E. (2021, 8 May). What’s wrong with the Chainlink 2.0 whitepaper? Medium.

Related Articles

• A Critique of Existing DeFi Oracles
• What are Blockchain Oracles?
• UMA Deep Dive: Perils in Trading Synthetic Assets with Priceless Oracles

Learn More

• Asset Tokenization & Financialization Using Decentralized Oracles
• Oracles, Web3 Interoperability, & the Emergence of IoT
• Stateless Money: Lessons from the Free-Banking Era and Wildcat Bankers