Oracles for Polkadot

[gautam]

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.

Oracle Hub?

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?

[lucasvo]

I think an oracle focused parachain and allowing other parachains to read from it is a great use case for Generalized Storage Proofs. I wanted to flag this for @burdges!

[sylvaincormier]

This post seems to suggest
that a new tokenless, common-good
parachain would be best suited to manage the business logic
invloving the stakes of a parachain oracle.
The parachain oracle should also take on the role
of delivering various parachain feeds in a configurable way.
Parachains should be able to provide data feeds
from their own oracle system
while staking in (DOT/KSM) and being managed by the
parachain oracle DAO.
Staking, feed management,
and the last level of aggregation
should happen on the common good parachain although consulting
previous aggregations from one specific chain should remain possible.
Ideally, customizable parts should be developed in ink! to be more open to the community.

[pascuin]

A lot of the topics mentioned here go into the direction of how we approach the challenge of bringing off-chain data and computation to parachains and the broader web3 space with Acurast.

On a high level in Acurast’s case, there are the two main components:

Data Transmitters/Processors

• Acurast Trusted Virtual Machine runs inside Trusted Execution Environments

These “oracle nodes”, are not only providing specific data but are infrastructure providers that give developers access to perform computation to e.g., fetch price feeds from APIs.

Acurast Parachain

• Acurast Execution Verification Engine
• Acurast Marketplace

The Parachain is responsible for the verification of the execution proofs of the Data Transmitters and is home to the Acurast Marketplace that brings together Data Consumers and Data Transmitters.

Example Flow

A simplified flow for the case of a DeFi platform that needs a price feed it looks like this:

That being said, let’s take a closer look at your thoughts:

@gautam

• 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.

This is the approach that we follow, by having Acurast as the dedicated Oracle Parachain. The Parachain with its Marketplace and reputation system is responsible for the disputes. Additionally, Acurast enables developers to interact with the Marketplace and the Parachain from their ecosystem, this means that the developer can e.g. create a Job for the marketplace on Parachain A that is communicated to the Acurast Parachain over XCM. Through that the developer doesn’t have to leave their ecosystem and go to Acurast solely to setup a Job.

@gautam

• 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.

Fee payments in Acurast can done in the asset that is defined by the consumer. Through that the developer can define the payment of the asset to be in e.g., a USD stablecoin, through that both sides have a clear understanding on what value they have to pay or receive without being subject to an asset that can fluctuate in price during the duration of the job. On the other hand there is no limitation, if both sides are comfortable to accept a payment in another asset such as the native Acurast token oder DOT.

In the case of a job that is run over a long period of time e.g. 30 days, the payment is done once by the developer and the transmitter can claim their reward upon completion, which drastically reduces the needed amount of transactions.

@gautam

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.

The Acurast Parachain can be seen as the Oracle hub with its marketplace where disputes etc. are handled.

@gautam

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?

We have already built an Oracle Pallet that can be integrated by other Parachains to receive outputs from Data Transmitters. Details about an integration can be found in our docs Substrate | Acurast Docs. Having treasury support for audits would be definitely something that would helpful.

Happy to share more details on Acurast and dive deeper into the approach, to better understand if this matches your thoughts.