According to the definition in the CoinMarketCap glossary, “cross-chain is a technology that enhances the interconnection between blockchain networks by allowing the exchange of information and value”. We have created a multichain Web3 world in which some chains are competitors whilst some serve different purposes. It is hard to predict if the future will be multichain as well but we need to provide tooling for the current situation. This is why many products, RedStone Oracles included, position themselves as cross-chain.
Cross-chain oracles
A question that often arises is how do oracles become cross-chain? Oracles are not responsible for exchanging information between networks but they can provide the same data to different blockchains at the same time. This is not a trivial problem because each network requires additional work and integration. What is more, if oracles are using storage contracts to keep up-to-date values usable for smart contracts, it gets extremely expensive. In this situation, scalability is severely limited and for this reason, most current oracle implementations concentrate on one network.
In order to create truly cross-chain oracles, RedStone decided not to use storage contracts. This decision is one of the crucial factors in opening up a way to unparalleled scalability. So, how can we provide data to smart contracts since:
- they cannot natively communicate with the external world;
- there isn’t any other contract with the necessary information?
We can achieve this by implementing a chain-specific connector that is applied on both the contract and client sides.
RedStone’s approach
Speaking of contracts, we have prepared our own which should be inherited by the user’s contract. In our contract, there are functions responsible for four major functionalities:
- data extraction from calldata,
- data provider validation,
- timestamp validation,
- aggregation of data from multiple providers.
These functionalities allow us to use verified data from multiple providers in smart contracts. The only question here is how information appears in the contracts’ calldata.
On the client side, we prepared a library that is responsible for attaching specially prepared data to transaction calldata. Currently, it is mostly focused on ethers.js and works as a wrapper on a contract instance. Each time you interact with the wrapped contract our library fetches information from the RedStone cache layer and adds it at the end of the transaction data. Later, the transaction is sent to the contract which, if extended by our contract, can extract information and use it for any on-chain purpose.
The whole process described above is presented on the graph:
At RedStone we strongly believe that getting rid of the storage contract is the right way forward to build the next-generation of oracles that offer cross-chain functionality by design and unparalleled scalability. However, this process of passing data to contracts is not the only thing that differentiates us from other oracle providers. Check out our other articles and follow our socials to learn more!
Join us on the journey to build the next generation of Oracles!
