Oracle Communication Layer

[dcorral]

Summary

• Communication layer between the different VMs in DeFiChain to fetch Oracle data.
• Implement the ability to fetch Oracle's data directly from SCs removing the need to use external tools to fetch and import this data into SCs.

Rationale

• Price feed from Oracles is a fundamental feature for developing DeFi products in DMC.
• Enhance interoperability of the current dToken System.

[cuongquangnam]

Is this the plan to replace the current StateRelayer I'm working on?

[dcorral]

Hi Cuong!
This is not meant to replace any existing work, this is a feature request from the community. Could you update us on what the StateRelayer is and point us to where we can find the progress of the development?

Thanks!

[cuongquangnam]

StateRelayer is in its final state of development, I am trying to finish several last pull requests.
You can take a look at this repo: https://github.com/BirthdayResearch/StateRelayer

[prasannavl]

Hey @dcorral, thanks for making an issue on this.

The current ecosystem level solution: The state relayer project https://github.com/BirthdayResearch/StateRelayer (and any other community projects of the same nature). It's a just a dApp solution, so anyone should be able to redeploy the same according to their parameters or tweaked versions of this as needed.

The protocol level solution

The DeFiChain protocol will eventually have it's own set of intrinsic contracts (The current DFIIntrinsics is just the bare skeleton for this). Most of the chain's info will eventually be exposed by similar intrinsic contracts handled automatically by the chain with dedicated and transparent contract addresses.

Key challenges to be resolved first

1. Many of the current data-sets required are heavy on IO. So we will have to finish a storage revamp before even enabling this as it's be very expensive for the node to perform these lookups on every block / TXs required to expose these into intrinsics.
2. We are also exploring the possibility of an asynchronous on-demand update of the EVM storage trie just before a look up of a specific storage slot, rather than updating all the storage slots of intrinsics on each TX, so this can enable even more efficient handling allowing us to open up more possibilities.

Depending on which of these we tackle first, the timelines for these would change. So, the more effective route is to focus on transparent state oracle projects on EVM side that can bridge the gap, until the protocol based solution is ready.

[sambP]

Hi @prasannavl, thank you for the update. The StateRelayer example is not an option. We are looking for a trustworthy source of the DeFiChain Oracle data, we can't push the updates ourselves. This would remove any decentralisation.

I mean we could deploy something like https://tellor.io/ on the dmc, but this feels completely wrong because we would build around the native defichain oracles, which is one of the main features of the chain...

A bridge solution is also not really an option if the protocol should be immutable. There is no way to swap the price feed after deployment.

Is it possible for you to specify the timeline a bit? Are we speaking about Q1-Q2 2024, or is it more about Q1 2025?