With the HTTP and off-chain attestation capability, Fat Contract is a perfect platform to build flexible oracles. We have an oracle-workshop showing exactly how to do that.
To build a production ready oracle, there are still ways to go. The oracle workshop only shows how to verify the oracle data within the Fat Contract. We still need a way to serve the other blockchains.
Traditionally oracles are deployed as a smart contracts (e.g. ChainLink oracle contracts on EVM). Users can call the contract to query something, and get the response by a callback. In the context of Polkadot parachains, we may think about sending a query via XCM to the oracle Fat Contract, and receive a XCM with the response later, as asked by ioannis | StakeBaby in the discord chat:
An oracle that collects data from other parachains; we can use the internet access of a fat contract, but hmrp would allow the other parachain to make requests and centralize control
Road to production ready oracles
Option 1: Oracle over XCM
The idea is easy. We should allow any parachain to send a XCM request to the oracle Fat Contract. Once the contract has processed the request, it sends a XCM with the response data back. To do so, we need to have two things.
-
Enable XCM to (ink!) Fat Contract call path
Not hard. We have all the building blocks to enable that (i.e. MQ in pruntime). It’s just a matter of time to enable the path between onchain pallets and Fat Contracts. This is already on the short term roadmap of SubBridge.
The only annoying thing is the economics involved. E.g. Who to pay the XCM execution fee on the source & destination parachain. This can be probably handled in a similar way as SubBridge assets routing.
-
Query automation
This one is worth explaining.
In Fat Contract, HTTP requests is only allowed in queries, but XCM can only triggers a transaction call, where HTTP is disallowed. To trigger the oracle logic, we need to store the incoming requests in the contract storage when receiving the XCM, and then trigger the actual logic in a query later. So here, we need some assistance from the off-chain world. That’s why I call it “query automation”.
A naive way to do so is to run a script to invoke the query periodically. To make it more decentralized, we can incentivise a group of people to call the queries (like ChainLink Keepers) instead of having a single script.
It’s also not super hard to implement a query automation mechanism. There’s no blocking issue, and it has the potential to become a public service for more general use cases.
Option 2: Oracle via direct RPC
Instead of invoking the oracle via XCM, we can build an oracle to serve the target blockchain directly via RPC calls.
There can be a pending request queue in the caller chain. Whenever the caller wants to get some data, it pushes the request to the queue. The oracle watches the queue by sending HTTP requests to SubQuery or the RPC nodes directly. Once it found the jobs, it can execute them and post it back to the caller chain via full node RPC, by contract-crafted transactions.
So in this approach, we need two things.
-
Contract-crafted transactions
The Fat Contract is capable to generate a wallet inside. Then the oracle contract can directly craft arbitrary transactions and sign it with the wallet controlled by the contract. Finally, it can broadcast the transaction to the caller chain via normal node RPC.
This is a powerful tool that can basically enable Fat Contract to interact with ANY blockchain. So far, the team is working on EVM and Substrate chains. Fat Contract’s capability is already enough to build it, but there are still some tricky parts. E.g. Need to handle all the edge cases like chain reorg and fee spike.
-
Query automation: the same as Option 1
(WIP: maybe build a pallet / contract to maintain the request queue on the caller chain?)
Other considerations
(WIP: data aggregation & security, trusted data source, etc)