Price feed proxies?

[aesedepece]

Arguments:

• Price feeds is the most user-facing piece of the Witnet stack.
• The Solidity bridge we have today is pretty powerful and flexible, but we plan to keep improving it 𠅥— reason why we proxied it.
• Once people start using the price feeds, changes in WitnetRequestBoard must be backwards-compatible so they don't break the price feed <> request board API.
• There's always some slight probability that the price feed <> request board API could be broken at some point if some significant change is implemented for critical reasons.
• There's also the case in which we want to update the base price feed contract (ERC2362PriceFeed) for whatever reason.
• We can't obviously commit to keep polling old versions of a price feed.
• If a price feed is redeployed, we need to make sure that nobody is left behind, and that all users will be using the new version.
• One obvious solution is to put the actual price feeds behind an ERC2362 compliant proxy that always routes the reads to the latest deployment of a price feed.
• This is also an opportunity to offer all the price feeds from a single contract address, as ERC2362 already provides for the possibility of a feed serving multiple asset IDs.
• Trust implications in all of this are not trivial (someone needs to be the "owner" of this proxy, and whoever that is, holds a huge power to break several 3rd party contracts at once through a failed or malicious upgrade).
• Another option is to make our tooling (truffle box, etc.) silently deploy one proxy per user, and let them be their own "owner". Then, we keep polling both old and new feeds during a "grace period" in which they need to either (a) update the feed address in their "personal" proxy, or (b) continue polling the old feed on their own.

I don't have a strong position on all of this, but I think we need to tackle the issue and make a decision to this respect sometime soon, because it is crucial for mainnet deployments.

[guidiaz]

I really like the idea of having some kind of ERC2362 router aggregating all price feeds maintained by certain sponsor. Although price feeds themselves (ERC2362PriceFeed) enable anyone to start or complete any price update cycle, they still have trust implications in the sense that there has to be some kind of "sponsor" (e.g. Witnet) who commits to deliver certain update periodicity, in order to let them provide a real value to the community. So, in this sense, introducing an ERC2362 routing pattern should not necessarily require a higher level of trust from the user/dapp side.

Based on current implementation of ERC2362PriceFeed, a simple approach could follow the following pattern:

Being ERC2362PriceFeed a UsingWitnet contract, this simple approach would not be oracle-agnostic.

[guidiaz]

However, in terms of trustability (+/vs) maintainability (from the sponsor/operator point of view), there are some features that could be considered in a more refined ERC2362 routing pattern:

• [1] Ensuring that all price feeds under the same router use the same Witnet Request Board entry point, could be a plus:

  • While WitnetRequestBoard implementations are proxied, so minor upgrades are automatically propagated to all "UsingWitnet" contracts relaying on that entrypoint, it's true also that the sponsor may eventually decide to stick to certain implementation version (not accepting further WRB improvments), or just jump over an eventual decentralized version of the Witnet Request Board. In this way, all live price feeds (...being all of them in "requestPending==false" status...) could be easly upgraded at once without needing to reploy them all again.
  • Bad thing about this approach: the router would not be oracle-agnostic.

• [2] Ensuring that all price feeds are solved by a common prototype implementation, would enable all price feeds to be upgraded at once in case a new feature or patch was to be applied in the logic of the polling mechanism (e.g. the way the reward is calculated). This approach would include [1] as the updated prototype implementation could always point to either the same or different Witnet entry point as the one used by any previous prototype.

• [3] The router could also act as a "factory", enabling the construction of new price feeds by applying a "minimal-delegate-proxy" pattern and either using the prototype implementation described at [2] as a "beacon", or enable the "sponsor" to eventual specify different implementations when creating new feeds. In either way, creating a light proxy on each new price feed would for sure cost less in terms of gas than deploying/reploying price feeds every so often.

• [4] Updating not (only) the polling logic, but the actual request being processed on each price update, would enable the sponsor to update oracle-specific parameters in some (or all) of sponsored price feeds. For instance, in the case of Witnet-based price feeds: the number of witnesses, reward, number of sources, aggregation filter, etc.

[guidiaz]

After some team discussion, the following approach has been considered best in terms of versatility and truslessness:

Moreover, it allows those directly interacting with a WitnetPricePoller instance to continue doing so even in the case it stops being referred by a WitnetERC2362 instance.

[aesedepece]

Time to close this discussion, as this idea has already been implemented and actually deployed into several of the supported networks.