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.
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:
- Contract A - wraps Sophia Oracle API
- 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 
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 
_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!