August 25, 2023 - 5 min read
Fetching and validating external data for use by smart contracts is not a simple task, and it is not exactly free either.
The operating costs of decentralized cross-chain data validation are not immediately obvious. How do blockchain oracles trustlessly and securely validate data, and what incentives are there for the entire mechanism to function seamlessly? Perhaps it would be more self-explanatory if centralized models were used, but the old trends don’t hold anymore with the emergence of Web3.
In fact, the operations of a decentralized oracle network require a meticulous design, and thereafter the skillful management of many moving parts. In addition to the usual incentive models for operating the consensus protocol of a decentralized network, there are additional on-chain and off-chain costs to consider.
That is, fetching, validating, and publishing reports on a variety of data doesn’t come easily, and maintenance of the network incurs costs as well. This, of course, is all without scratching the surface of how many resources are poured into research and development, but let us not digress. Here is a high level overview of some of the economics supporting the linchpin of Web3 interoperability and what could become the IoT.
Recording data on-chain incurs gas fee costs for oracle networks. That is to say, in order to incentivize a network’s validator nodes to participate in the consensus mechanism and therefore validate data in the form of new blocks, someone must be paid for the work.
While gas fees on some networks are lower than others, there will always be an associated cost to write anything on-chain. Each blockchain and use case will have differing costs, but it’s intuitively obvious that a chain which can securely validate more data economically for each block will lend itself to more activity taking place on-chain. The results are more transparency and a more detailed history for audits.
For push-based Oracle data feeds, publishing frequency is determined either by triggering a deviation threshold, like a significant price change, or a predetermined cadence parameter. That would have the oracle publishing reports every few seconds, minutes or days, depending on the needs of the application consuming the data.
A more customized approach is a pull-based Oracle feed which publishes data upon request, a la carte. This would allow projects to self-modulate their data needs and budgetary constraints in real time. Alas, there will always be varying needs and as to how often data needs to be written on-chain for differing use cases.
Furthermore, Oracle nodes have off-chain costs to consider as well. For example, nodes need to own and operate the hardware required to run the necessary Oracle node software. These nodes need to take on requested jobs to fetch certain data, connect to the relevant API or other resource, propose to publish data on-chain, and participate in the voting mechanism which ultimately validates and writes it on-chain for consumption by smart contracts.
Node operators either run their own nodes directly on their own bare-metal servers or otherwise rely on cloud infrastructure. Either way, there will inevitably be initial investments in hardware and then ongoing hosting fees to utilize shared servers.
While using cloud services is undoubtedly more convenient, there are also centralization risks inherent to the use of cloud infrastructure to run nodes. After all, the high costs, not to mention the trouble with the initial setup, of bare-metal servers make it more likely that nodes will opt for cloud computing providers. Too many applications choosing to go this route would therefore add to the risk of a single-point-of-failure event.
Oracle RPC nodes need direct communication access to a network of fully-synced blockchain nodes so they can publish data for use by smart contract agreements being recorded on that blockchain. Connecting to an externally managed RPC provider would allow for a more plug-and-play experience, but would again increase the chances of a single point of failure.
Requiring Oracle nodes to have redundancy connections safeguards the network even further. High-throughput blockchains will often require more resource expenditure from Oracle nodes since they need to handle more concurrent transactions while remaining synced with the ledger- and with so little time before the next block is proposed.
Finally, Oracle nodes will be needing subscriptions to a variety of premium API sources so they can reliably fetch data to be used on-chain by smart contracts. APIs will charge annual, monthly, or pay-per-use fees (in order of least to most expensive). Drawing upon multiple API subscriptions for redundancy makes for a more robust standard operating procedure for Oracle nodes, even though it runs up the cost a bit more to do so.
Of course, none of this can just be automated without any maintenance costs. As we know, crypto asset prices can fluctuate wildly when liquidity is low, and Oracles need to respond to dynamism both in the marketplace, when it comes to hardware or software malfunctions, or whether it be changing conditions in the real world upon which the Oracle is reporting data.
That is to say that, we have to constantly optimize Oracle node performance when it comes to availability, accuracy, and use of resources. That means a node will need either an individual or a team of individuals to track and analyze their Oracle node’s performance. This is not a small task, and requires sophisticated personnel, hardware, and software.
A whole new world is made possible once you can connect external data with a sophisticated, transparent, and decentralized financial system that never sleeps. With the combination of AI and Web3 technologies, we can just about set the whole world on auto-pilot while we spend our time optimizing the rest of our lives. Seamless interoperability is what took the calculator and made it into a mobile phone that can do it all, meaning things are looking bullish if we extrapolate this analogy as remaining applicable moving forward.
In order to provide the opportunity for interoperability amongst disparate ecosystems, it’s crucial that participants are given a sustainable foundation via the proper incentive structure. If blockchains each operate in their own siloes, the amount of human willpower and the computing power they command will be capped in each individual circumstance.
By bringing ecosystems together naturally, they can reimagine their roles as cooperative rather than competitive. This will naturally lend itself to rapid innovation and a renewed focus on delivering quality services rather than user acquisition. Blockchain oracles will thus be the lifeblood of the financial system which holds Web3 and the physical world together.
RECENT POSTS
註冊Supra新聞通訊,獲取最新消息、更新、行業洞察等內容。
©2024 Supra | Entropy基金會(瑞士註冊號:CHE.383.364.961)。保留所有權利。