6

After reading the question General approach for allowing multiple smart contract transactions per block I'm wondering how an oracle can guarantee update rates respectively uptime.

If too many transactions want to consume the oracle eUTxO, wouldn't this prevent the oracle provider itself from calling its update endpoint because the eUTxO will often be consumed before he can do it?

Improve this question

4 Answers 4

Reset to default
1

If "too many transactions want to consume the oracle eUTxO", you can implement a deadline and after deadline the oracle's utxo is no longer usable(or consumable) and can only be updated by oracle operator.

Improve this answer
0

If they are consumed, the provider would just create new UTXOs from the fees they have collected.

Keep in mind, an oracle would have to consume all of its UTXOs anyway to update the price.

Improve this answer
3
  • 1
    The oracle validator in the Plutus Pioneer Program example is programmed in a way that a user has to provide the exact same datum (which contains the oracle information) at the new oracle eUTxO: Use -> traceIfFalse "oracle value changed" (outputDatum == Just x) So the provider does not create a new eUTxO but ensures through the validator that the consumer does.
    – Johannes Sirsch
    Commented May 27, 2021 at 21:07
  • That an oracle would have to consume its own (or by a user) provided eUTxO is exactly the problem that I am stating in the question. I'm wondering if the oracle provider could often be to late because someone else submitted a transaction for use first.
    – Johannes Sirsch
    Commented May 27, 2021 at 21:14
  • If an oracle provides multiple eUTxOs, it can update the provided values one by one. So there is no need to do that all at once. And because of the same reasons, that I'm discussing here in this question, I doubt that an oracle provider can guarantee that all oracle eUTxO (if he provides multiple) datum values will always be in sync.
    – Johannes Sirsch
    Commented May 27, 2021 at 21:18
0

In the Plutus Pioneer example in lecture 6, the oracle's UTxO is identified by an NFT. Any transaction that wants to consume this, whether it be a transaction wanting to access the information in the oracle, or whether it be a transaction created by the oracle provider to update the value, would first find the UTxO by looking for the NFT.

If another transaction has consumed the oracle UTxO as an input, it must have created a new oracle UTxO as an ouput. This new UTxO may have the the same Datum, or an updated Datum depending on the reason for consumption, but as part of the transaction constraints, it must also contain the NFT.

The next transaction that tries to consume the oracle UTxO will then find this new UTxO rather than the previous one, as this is now where the NFT is sitting.

Improve this answer
0

After CIP-31 is implemented, none of this will be an issue.

This Cardano Improvement Proposals adds what is called "reference UTxOs" which are read-only. So if the Oracle provider has write access and everyone else only has read access, then the Oracle will never have anyone to collide with other than herself.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.