Querying of Oracle via name hash

This work happened in the middle of September.
Reporting about it was postponed until the PR is merged.
Since we need to merge it after hard fork, for visibility, the endeavor is summarized below to avoid any further delays.

The PR 2797 adds ability to query oracle via a name hash.

This level of indirection, represented by a pointer to Oracle ID stored in the name entry, can be useful if we want to abstract over oracle providers.

As an example, if we have more than one oracle allowing queries about the weather in the region, or land register, we can structure our service depending on these oracles in a way, which supports switching to different provider if needed.

The reason could be minimization of the cost of query, or increased availability if oracle becomes unreliable, slow, or detected to work with older data than some alternative oracle.

With this indirection, the functionality using the data from oracle, can be decoupled from literal encoding of the oracle ID by referring to oracle via a name hash.

The user building additional functionality can then proceed as follows:

  1. Register a top name (or possibly a subdomain in the future) in AENS
    (this creates a name entry, which can change its pointers - hashes the name object resolves to)
  2. Set up “oracle_pubkey” pointer in the claimed name entry to a preferred oracle id
    (via name update transaction)

For any reason mentioned above, user is free to point to a different oracle via issuing another name update transaction.
The functionality building upon answers from oracles doesn’t need to be changed, but it would have to be prepared to receive the answers in different shapes, as it can’t know which oracle would be used in future as source of data.

Since there was a lot of development done after this PR, some features (in particular miner signaled consensus) requires minor changes to this PR before we can merge it.

3 Likes

Thanks for this post and update.