[ORACLES] Updates, Requests, Questions and Feedback

Thank you for your question, it’s always useful to have a discussion and look at each matter from different points of view :slight_smile:

3 Likes

Is it possible that certain transaction will need to be verified by oracles. These holders could be within a certain industry that needs high level verification,would this need more verification from oracles, then driving more query’s to them/more transactions?

Oracles are a mechanism to provide truth for the outside world. They can be built to accept any type of data, transactions’ hashes included.

Is it possible that certain transaction will need to be verified by oracles.

Alice makes a TransactionA1. It has a hash TransactionA1Hash. Alice sends a query to an oracle CheckTransaction. Oracle CheckTransaction receives the query, using the hash provided tries to get TransactionA1’s state - if it is already included in the chain or not. Based on whatever the oracle is looking for, it posts a response to the query. This response might be based on the TransactionA1’s contents and some references to an external data source. This is the time for the high level verification you’re talking about.
Alice then can use this response in an contract call.

I am not sure if this answered your question. If you were asking if an Oracle can prevent Alice’s transaction of being included in the chain - no, it can not. If that’s what you want, please use a couple of phases interaction:

  1. Alice posts TransactionA1
  2. Alice calls oracle CheckTransaction with the hash of the transaction
  3. Oracle CheckTransaction does the high level checks off-chain and posts a response
  4. Alice uses this response to call a contract to finish the process

Of course steps 1 and 2 could be combined into a single contract call transaction. Here I’ve split them to bring more clarity of the sequence of thge different phases.

5 Likes

another question about oracles in general (I just had a call with @erik.chain where this question of me came up):

  • at this moment it is only possible to perform oracle actions on-chain, right?

the reason I am asking that is that if we assume we will have many oracles (mainly IoT sensors) in the future we probably will need support for an incredible high amount of on-chain transactions. have you already thought about that? @dimitar.chain

2 Likes

Hi @marco.chain
Yes, oracles are available only on-chain. Regarding the off-chain - you can still have an IoT device that signs messages and sends them off-chain to concerned parties - still off-chain. You can have a certain contract that checks that the received signed message has an origin the IoT’s pubkey (so it is correctly signed) and use its input for your off-chain contract. In this sense the IoT could act as an off-chain oracle and its signed messages can still be used both in off-chain and on-chain contracts and disputes.
Providing a broadcasting service from a single IoT to multiple off-chain channels could be yet another business niche.

2 Likes

Hello,

I am trying to create a client for contract, which calls another contract with an oracle. When I run my unit tests, everything works fine, but when I run the same from from my web app through the JavaScript SDK, I always get an out_of_gas exception and I have no clue where I have to search.

Please, can somebody give me a hint?

Best Regards

Hi Guys,

I have additional question to what @UlfA has already asked before me.

My question: who is going to be debited/charged for Oracle query when one contract creates an Oracle query through another contract? Oracle is registered in constructor of the second contract (i.e. it is in callee).

As I understood, the Oracle query needs to be initiated by the Contract who supposed to cover query fee. So that in my scenario, first contract needs to lookup an Oracle instance and use it to create an Oracle query. Then, second contract should lookup for a query from the blockchain in order to respond with an answer. Still not sure wether I got the existing Sophia API right.

No, this is wrong. Anyone can initiate the query to the Oracle and after a response had been posted to that query - anyone can use it to call their Contract. Nothing in the protocol requires the Contract to ask the oracle. Only restrictions lie in response types and the specific Contract’s internal logic - if a Contract call is provided with a response that fits those - it is valid no matter who initated it (and payed the fee).

Doing a call that uses another contract to execute some logic for us is called a remote call and it is described in the protocol.
tl;dr: calling contract dedicates some gas to the called one, after the remote call is done - the excess of gas (if any) is returned to the caller contract. This approach is designed to work with multiple remote calls, as well. At the end - the transaction that posts the contract call pays all the gas consumed.

Hi @dimitar.chain

Thanks for reply.
Yes, I understand that everybody can ask an Oracle a question.

Let me describe what I have in development. I model my application using a couple of contracts. One of the contract (A) wraps Oracle Sophia API. I use this contract (A) to ask a question from another contract (B). That is design choice at this point.

Now, my question was about Oracle fee. I want to charge a caller (B) of the contract (A) for making an oracle question.

Scenario:

  1. Contract A - wraps Sophia Oracle API
  2. Contract B - user contract which calls Contarct A to make a question. This contract gets an instance of oracle object to make a query via Sophia.

am I correct that above scenario charges Contract B for an an oracle fee , when it makes Oracle.query? This is what I want, so that user Contract pays for his question to Oracle.

No, it is the contract doing the call to Oracle.query call that pays the fee. If you want contract B to “pay” you have to supply the corresponding amount in the call to A. See protocol/sophia.md at master · aeternity/protocol · GitHub and the amount parameter.

1 Like

@hanssv.chain thanks. This is what I have in my Contract B as code:

contract MyContractB =

 private function askOracle(user: address, points: int): intQuery  =
    let o = state.myRemoteContractA.getOracle() // this is oracle(int, int) type
    let q = Oracle.query(o, myQueryInput, state.oracleFee, RelativeTTL(50), RelativeTTL(50))
    ...

I got it that Oracle query fee will be paid by the contract which has this above function, i.e. MyContractB is paying.

Yes in this case MyContractB is paying.

1 Like

I have a general question regarding oracles again:

  • it is not possible to query the oracle and process its response within one function call right?
    • I currently assume this always needs to be separated in two different functions
    • so I would for example store the ID of my oracle-interaction-object in the state and then call the other function to process the answer as soon as the oracle-response arrived, correct?
  • how would oracle responses be processed?
    • is this possible within the smart contract (because we know the response-format of the respective oracle) or must be response be interpreted off-chain and then “manually” be submitted to the function that performs an action based on the oracle-response?

I read a bit more into the oracle topic yesterday and the more I read the more fascinated I get regarding how it is designed and implemented.

so I know that oracles have a TTL and oracle query objects (query and response) also have a TTL. therefore I have additional questions:

  • assuming an oracles expires:
    • will the whole oracle state tree be deleted?
  • assuming the TTL of the response oracle query object expires:
    • then the object will be pruned from the oracle state tree, right?
    • after it gets pruned
      • then it won’t be possible to use that object anymore in the future, right?
      • what happens if a response of the oracle query object was already be used within a smart contract? will the answer still be visible?

I am especially wondering how the oracle query objects are handled. do they remain in the blockchain after the TTL is expired? because in the protocol description it is also stated that they get closed with an oracle response transaction and become immutable.

would be cool to get some clarification here :slight_smile: thanks!

it is not possible to query the oracle and process its response within one function call right?
It can certainly be done, but I can’t really think of a useful case since it would mean that the contract would also have to act as the oracle in between query and reading the answer :wink:

_how would oracle responses be processed? _
Oracles are dual purpose, either they are “plain text” and then all processing is done off-chain. Or they are “contract oracles” and in that case queries and responses are encoded as contract values (and the contract interfacing the oracle is checking the types etc.) An oracle that is created within a contract is always a “contract oracle”.

TTL questions
Yes, if the oracle expire the state tree is garbage collected. The same is true for individual queries (and responses).

In order to use an oracle response it has to be in the state tree at the height where the usage is done so to say. And if a contract use an oracle response at height X then we can always validate this contract call at height X - but if the oracle response expire at height Y, then another contract call cannot use it at height Y + 1…

There is a difference between immutable and eternal, the response will never change, but it will also not be around forever.

If the response is “in the blockchain” after it has expired is more of a philosophical question… No, it is no longer in the state tree. Yes, its effect can be visible for example a contract could have stored the response in its own state. And if you have something like an “archiving” node you can always go back and look at the state at height X…

3 Likes

thanks for that detailed explanation!

1 Like

How does AET ensure the data provenance for its oracles and the privacy of the data requesters e.g. blockchain accounts for data to be used in smart contracts … account A triggers contract B to request Data C to be used in B … masking account A … how, for example, does your oracle approach differ from TownCrier or Rhombus or Oraclize? Any comparative analysis? Thanks!