We’ve been exploring integration of decentralized oracles with Polkadot parachains and related technical lift. Sharing some thoughts here based on some of the discussions we’ve had internally. Would be great to get some feedback and thoughts from the ecosystem.
From a oracle data request/response business logic perspective, this is relatively straight forward. However, for seamless fee-payment and dispute resolution in a multi-chain network seems a bit complicated. Here’s why:
Some of these decentralized oracles use a staking mechanism - oracle nodes (data providers) have to stake oracle’s native token before they could provide data. In case of a dispute this deposit could be slashed. In a multi-chain scenario, the question is where should we have this staking and disputes logic deployed. We can’t deploy this on each parachain because that would make it too difficult for oracle nodes to register and stake separately on many chains. If we deploy it on dedicated parachains for all oracles, that is too much effort for oracles to launch and maintain a parachain.
Second issue is with fee payment for oracles. Some of these oracles need fee payment to data providers in their native token. In that case each parachain using the oracle needs to have reserves of oracles’ native token and make payments for usage. One way could be to have a derived asset on Statemint and then doing fee payments using XCM. To make sure it does not make XCM too chatty, we could do delayed payments (once per session or once per era). I believe the Statemint DEX would be extremely helpful in this scenario.
Another issue is with dividing the stake from data providers for each parachain they are providing data to. If they are disputed on two chains at the same time, then we need to ensure there is a way to figure out the percentage stake per consumer parachain and the resulting slashing.
Would it make sense to have a oracle hub parachain similar to bridge hub? The oracle hub could be the home for the staking, disputes, and payment processing logic for several oracles. The challenge would be to align different oracles to use a unified runtime. This could involve having them make changes to their core business logic which would be a barrier to onboard them.
Smart contracts for staking/disputes?
Another option would be to encourage these different oracles to host their staking/disputes/payments logic on one of the smart contracts platforms on Polkadot. This way they could potentially deploy their existing smart contracts (on Moonbeam), and can communicate with consumer parachains via XCM. Considering the staking/disputes transactions are much less frequent than data request transactions, having this logic on smart contracts should not be a performance bottle neck. However, in this case, the oracle data provider nodes will have to use one more token for interacting with the smart contract platform.
Reading state across chains
For the decoupling of staking/disputes/payments and data requests to work, we would need a way for data requests logic to seamlessly read the values and configuration from staking and payments logic and state. There has been a discussion about having a inter-chain oracle which should allow this.
Parachains adding oracle pallets
Once we move in the direction of having data request pallets for oracles while keeping the staking/disputes/payment logic separately, one of these oracle pallets need to be added in the runtime of consumer parachains. Consumer parachains are parachains who need external data in their runtime. To make sure they can safely add these pallets, we need to get them audited while also keeping them maintained. Would it make sense to have these pallets audited and maintained via treasury funding?