The DAPP Network Just Added Powerful New Features for EOS dApps
Why Web Oracles, Inter-Blockchain Communication, Scheduled Tasks, and Randomness Matter — and How the DAPP Network Can Help
Blockchains are blind to the outside world.
This is a feature, not a flaw.
Predictability is central to how blockchains work. Everything must be predictable.
After all, one of the central points of a blockchain system is that everyone can verify the blocks being produced. But most data from around the Internet and other blockchains is essentially random, oscillating from one moment to the next. Data points change frequently, trends flip, and websites sometimes go down. Some resources may even be completely unavailable in the verifier’s area.
If data from the Internet or another blockchain is involved, a verifier checking a transaction might get a different piece of data than the data the block producer obtained while including the transaction. The verifying node can’t possibly hope to query the Internet resource at the same exact time and from the same exact location as the block producer!
Since code run on blockchains must be deterministic — completely predictable — you cannot call any source of off-chain information from within a smart contract.
By the time a transaction is processed for addition to the blockchain, all of the data must be decided upon already.
How can we solve this oracle problem in an efficient, decentralized way?
So far, there are two main solutions:
- Applications can build their own oracles — connectors that provide information to their contract that has been gathered from the Internet. This requires trust in the application team and oracle code. It may be in the financial interest of many dApp teams to game their own system, whether imperceptibly over time or in one fell swoop to execute an exit scam.
- Or, applications can rely on third-party oracle services. However, this could be a problem if the dApp grows to a significant size or gains adversaries. Someone on the inside of the oracle service or someone skilled at man-in-the-middle attacks may desire to alter the data in their favor and steal funds from the dApp.
Lack of access to oracles isn’t the only limitation that dApp developers face.
A second problem is scheduled tasks.
Deferred transactions on EOS are not guaranteed to run.
To accommodate this, dApps often utilize server CRON jobs to handle essential actions. Or, they allow users the option to trigger these actions in case they fail. Needless to say, the reliability of a centralized server is no guarantee, and putting an extra burden on users and their resources is less than ideal.
Yet another problem is random numbers.
For the same reason that blockchains cannot get external data from the Internet or other blockchains, they cannot simply get random numbers, as the results of smart contract code execution must be completely predictable.
Complicated solutions involving multi-party secrets have become the standard for contracts seeking trustless randomness. But these solutions are not lightweight, nor are they easy to securely implement. Multiple dApps have been attacked and had funds stolen from them simply because assailants learned how to predict the dApps’ random number generation.
With the DAPP Network’s new features, DAPP Service Providers (DSPs) can now offer decentralized solutions to all of these problems.
LiquidApps just introduced web oracle, IBC/XIBC oracle, CRON, and randomness services to the DAPP Network. DSPs can now offer these services —and dApps, users, and watchdogs can verify that DSPs are being honest.
Let’s take the DSP solution for web oracles as an example:
- Your selected DAPP Service Providers obtain the requested info and serve it to you.
- At the same time, your own in-house DSP obtains the same info.
- The results are compared on chain.
- If one third-party DSP provides information that is suspect, you lose trust in that DSP, especially if the issue is a recurring one.
- If all of the DSPs provide information that is suspect, you suspect collusion by those DSPs. This is an unlikely scenario — especially since the DAPP Network’s Proof of Stake economically incentivizes DSPs to be honest. But it is detectable, meaning that your dApp can prevent groups from gaming the system even if all DSPs are dishonest.
Trustlessly retrieving data from the Internet is now possible.
And with the new Chain Oracle XIBC options — one-way cross-blockchain communication — DSPs on the DAPP Network can also provide information from other blockchains.
Chain Oracle XIBC has already successfully read from Bitcoin, Ethereum, Tron, Cardano, Litecoin, and Bitcoin Cash. One-way IBC can read Telos, WORBLI, Meet.one, BOS, and the Kylin testnet. These are only the beginning, as this service could potentially read information from many more blockchains.
If DSPs begin to offer the IBC and XIBC services, and dApps begin to use them, we could see a revolution in inter-blockchain communication, with EOS potentially having access to the entire world of other blockchains, whether they run on EOSIO or not.
LiquidApps envisions this as only the first step. The community can now build more robust inter-blockchain communication, including trustless verification of other blockchains — and beyond.
Blockchains are by default blind to the outside world, and even to other blockchains, but through the eyes of LiquidApps’ DAPP Network, EOS dApps can now see.
All of this means that EOS smart contracts can potentially have access to quick, straightforward information like:
- Anything retrievable over HTTPS. Smart contracts can now safely “see” the Internet!
- Transactions on the Ethereum blockchain (or on Bitcoin, Ripple, Bitcoin Cash, Cardano, and many more)
- Wolfram Alpha data, like the dimensions and weights of things, sports numbers, social science statistics, and even anagram lists and lottery odds
- Random numbers*
- Scheduled and recurring transactions
* Important: the current DAPP Network random number generation release still requires a trusted oracle. Production applications are advised to use code that encrypts DSP random number submissions.
Though vRAM was the DAPP Network’s launch offering, and vAccounts could provide a solution to a critical challenge to adoption, they were only the beginning. Now, DAPP Service Providers can offer trustless access to so much more.
DSP service packages can enable full-featured dApps with all of the major capabilities of traditional apps — while nullifying many of the opportunities for corruption, censorship, collusion, and coercion.
There are now many potential combinations of DAPP Network services. Here are some ideas:
A pricing service could retrieve the BTC/EOS price and stash it in vRAM, creating securely-stored but cheap and responsive price history.
Prices from different DSPs can vary slightly since access times will not be perfectly in sync, but they can be verified to be within acceptable levels of tolerance and/or averaged when appropriate. (Services used: CRON, Blockchain Oracle, IPFS/vRAM)
A dApp could reset a 2-minute timer with every user action.
As long as the user keeps using the dApp, regular RAM is used, enabling minimum latency. But when the user goes idle for 2 minutes, the data is moved out to vRAM — enabling a balance between usability for users and economy for developers. (Services used: CRON, IPFS/vRAM)
A PvP trivia game could create multiple-choice time-limited questions.
The questions are OCR-resistant images of semi-random queries to Wolfram Alpha created from templates loaded in from vRAM (and algorithmically refined or discarded if they cause bilateral complaints from players), resulting in a range of questions like:
- How long was the Jurassic Period?
- What was the 2005 lending interest rate in Argentina?
- What is the temperature of the ocean at 1000 feet?
- What was the birthplace of the director of Bram Stoker’s Dracula?
Then, first-time winners are onboarded via vAccounts so they can collect their prizes. (Services used: Randomness, Wolfram Alpha, IPFS/vRAM, vAccounts)
An even more cheat-resistant variant on the above could offer a prediction market.
Valid questions are those that Wolfram Alpha will be able to answer in the future.
- Who is the ruler of India? (query on May 30, 2019)
- What was the mean temperature in Washington, DC in 2019? (query on January 1, 2020)
- What is Mike Trout’s batting average for 2019? (query on October 1, 2019)
Data on predictions does not need to remain in RAM for months or years but can be evicted to vRAM, with cryptographic proof of its integrity remaining on chain. (Services used: Wolfram Alpha, CRON)
We said above that “you can’t call an oracle, any source of off-chain information, from within a smart contract.” But in effect, the DAPP Network makes this possible.
You still can’t technically call an oracle directly from a smart contract: EOSIO will throw an error. Now, though, DSP-enabled EOS endpoints can recognize these errors as requests, fulfill the requests with information, and re-submit the transactions with all of the pieces in place.
The DAPP Network has suggested solutions to RAM congestion and account creation difficulties — and now it has also introduced solutions for the problems of web oracles, blockchain oracles, randomness, and scheduled tasks — by enabling a new decentralized layer the blockchain is unaware of and allowing the seamless integration of its functions into dApp contracts.
We at LiquidApps envision programmers, and ultimately users, using these features as if they were a natural and integral part of the EOS platform.
Visit liquidapps.io to learn more or to start up a DSP of your own.
