Oracles - intended usage
Last updated
Was this helpful?
Last updated
Was this helpful?
The most general way to interact with Oracles is to use the HTTP API. In this document the API is put to use, showing the complete life cycle of an Oracle.
To show the intended usage of oracles we walk through basically the For simplicity, we only work with a single node in this example. It should be straightforward to split the example into one node running the oracle and other nodes querying that oracle.
The following assumes that the node exposes at address localhost/127.0.0.1 the following ports:
User API external HTTP endpoint: 3013
User API internal HTTP endpoint: 3113
In order to work through the example we need the (Base58Check-encoded) public key of the account with positive balance. For simplicity, we will use beneficiary account. It is easily retrieved from the running node:
We need to wait for the first block to be mined by the node (or else our transactions will be rejected with "Insufficient balance").
Once the account has a positive balance we can register an oracle:
prepare oracle register transaction as per . In order to ease the initial integration, the æternity node provides:
NOTE: the transaction fee is depending on the TTL. An oracle register transaction costs at least 1 (as all other transactions), plus 1 per 1000 blocks of life time. (I.e. a TTL of 50 blocks --> 2, and a TTL of 4500 blocks --> 6)
sign the prepared transaction (e.g. by using the SDK)
This means that we have created the transaction to create the oracle, once the next block is mined this transaction will be included. We can verify that the oracle is created:
Now, when the oracle exists, we can extend the TTL:
sign the prepared transaction (e.g. by using the SDK)
Again, we can check that the TTL was extended:
We can post a query to the existing oracle:
NOTE Similarly to the oracle registration transaction, the transaction fee field depends on the query TTL. The base query transaction fee is 1 (as all other transactions), and the TTL accounts for 1 per 1000 blocks (just a preliminary value to test the concept). I.e. the minimum fee field for our test transaction is 2. We specify query fee 4 - that is the minimum considering that the oracle was registered with query fee 4. Therefore the cost of the transaction is 6.
sign the prepared transaction (e.g. by using the SDK)
We can check the active oracle queries:
NOTE the query and response values are Base58Check-encoded.
We should note that in the response for the query request above we got thequery_id which we use to respond to the query:
NOTE The transaction fee depends on the response TTL (as set in the query). The base response transaction fee is 1 (as all other transactions) and the TTL accounts for 1 per 1000 blocks I.e. the cost for our test transaction is 2.
sign the prepared transaction (e.g. by using the SDK)
If we then wait for another block to be mined (and the response transaction to be added to the chain), we see that there is a response for the query:
NOTE the query and response values are Base58Check-encoded.
This conclude the walk through of the oracle life cycle example, which also exercise the HTTP API for Oracles fully.
TODO: WS API in the middleware.
post the signed transaction using the
prepare oracle extend transaction as per . In order to ease the initial integration, the æternity node provides:
post the signed transaction using the
prepare oracle query transaction as per . In order to ease the initial integration, the æternity node provides:
post the signed transaction using the
prepare oracle respond transaction as per . In order to ease the initial integration, the æternity node provides:
post the signed transaction using the