Current nuisances and limitations

1. A whole new WitnetPriceFeed contract needs to be deployed everytime a change in the underlying data request is required. No matter if the change is minimal, like adjusting the witnet reward, these are the steps and costs systematically involved on every single chain supporting the modified price feed:

   • Deploy new instance of the WitnetPriceFeed contract: requiring ~2,000,000 gas units.
   • In some cases, a new contract verification process may be required.
   • On the WitnetPriceRouter instance, re-route currency pair to new WintePriceFeed instance: ~175,000 gas units.
   • Eventually, price feed poller bots and the data feeds explorer website will notice about a currency pair being re-routed on the WPR instance, as they need to interact directly with the underlying contract address for certain operations.

2. There's no obvious way to introspect the expected result size of a data request that gets eventully posted to the WitnetRequestBoard contract. At the moment, this limitation prevents the WRB from providing exact calculation of the Witnet base reward for a specifc data request. When assessing possible solutions, let's have in mind that on-the-fly introspecting of new incoming data requests may indeed cost too much gas, though.

3. Badly formed DRs can now pass through the current WRB, as it performs no formal validation at all.

4. The WitnetPriceRouter contract has neither way to verify the result type of the underlying data request for a price feed is actually an integer. While the WPR is owned and managed by the Witnet Foundation, the WPR should whatsoever refrain from accepting data requests returning non-integer values.

5. Web3 apps willing to eavesdrop either the sources, retrieval types (HttpGet/HttpPost/RNG) or witnessing parameters being posted (and eventually solved) to the WitnetRequestBoard have no other option but importing the witnet-requests NPM package, which is only available on Javascript (atm). It would be nice to have some on-chain read-only methods to either disassamble any DR posted to the WRB, or have a place where to look-up for related metadata.

6. There's no obvious way in the witnet-solidity-bridge repo to compose/re-use parameterized data requests, so devs cannot help but engineer their own way onto this.

My proposal

Let's have a WitnetDataRequests registry contract where:

• Anyone can separately register RAD-part bytecodes (ie. DrRad) and any possible combination of quality-of-service parameters (ie. DrQoS).

• Upon registry, a formal validation would be performed by the smart contract, as to make sure no incongruity, incompleteness or rubbish is saved in the Registry.

• Unique identifiers would also be generated (ie. DrRadHash, DrQoSHash) upon registry.

• Bound to each identifier, all metadata extracted during validation would be directly accessible via specific look-up methods (directly reading from storage, w/ no need for on-the-fly calculations).

• Registration of RAD-parts would accept parameterized bytecodes, in which case a list of args (ie. DrRadArgs) would then need to be declared (an offset and a Witnet-supported type for every possible parameter).

• For what it may eventually be worth, the registry would also allow to stamp any combination of pre-registred DrQoS and DrRad bytecodes.

• Similarly to the IWitnetRequest interface, the Registry would also provide:

  • The resulting bytecode of any combination of pre-registred DrQoS and DrRad hashes (either parameterized or not).
  • The SHA256 hash of the any possibly combined bytecode.

WitnetDataRequests

Benefits

The utility of this WitnetDataRequests Registry contract would be much augmented if adopted from eventually enhanced WitnetRequestBoard and WitnetPriceRouter contracts.

WitnetRequestBoard

By having an immutable reference to the WF-promoted WDR instance, we'll make sure that:

• Queries posted to the WRB would refer to DRs that should have been previously published, and formally validated, into the WDR registry. This way, there will be no chance for the WRB to ever relay a badly formed DR to the Witnet side-chain.

• The WRB would manage to provide an exact calculation of the minimally acceptable reward for a DR to be relayed into Witnet, based on both the QoS parameters and the result type (and length) of the DR.

• Clients to the WRB would have the chance to post queries refering either a fully-stamped DR (ie. DrHash), a Rad/Qos static combination (ie. DrRadHash, DrQosHash), or even a parameterized Rad/QoS combination (ie. DrRadHash, DrQoSHash, DrArgs).

WitnetRequestBoard

WitnetPriceRouter

By relaying on the WDR instance refered by the WRB:

• For every currency pair, the WPR would separately keep track of the Radon script, the QoS parameters and the feeding contract that will be used for eventual price udpates. This way, the Radon script or the QoS parameters could get upgraded independently, and without needing to deploy a whole new feeding contract. The upgrade of any of these two would cost like ~50,000 gas units.

• The WPR would reject any attempt to bind a currency pair to a Witnet Radon script not returning a proper integer value.

• As the WitnetPriceFeed would be agnostic to the underlying data request used for updating the price, and by additionally establishing the WitnetPriceFeed to be "clonable", one single instance could be re-used every time a new currency pair is added to the WPR, as long as no improvement in the feeding logic is desired. The cloning of a contract (based on the minimal proxy approach) only takes like ~200,000 gas units on regular EVMs, no matter how complex the cloned contract may be.

WitnetPriceRouter