Support TWAP at the Airnode feed side

[bbenligiray]

Users frequently request us to provide a kind of data that we only have access to in raw form, with TWAP applied. If we could specify in the pusher config that the signed data for a Beacon requires 15 minutes TWAP to be applied for example, we would be able to serve a wider variety of data. Two problems:

• This will increase the memory requirements significantly. If this appears to be a problem in practice (which I doubt), we can approximate TWAP through a running cumulative average as in

avg(t + 1) = avg(t) * ((twap_window - fetch_interval) / twap_window) + x(t) * (fetch_interval / twap_window)

• The existing implementation (of the signed API and pusher) is agnostic about the data schema, while a TWAP would assume a single number. We can say that if a TWAP window is defined, the data needs to be decodable to an int256.

@bdrhn9 for visibility because we discussed implementing this at the Nodary API-side yesterday (but if we implement this here we can generalize it to other API providers as well)

[Siegrift]

• I like this as a feature and it benefits the API providers since it implements a feature that they don’t have. The increased memory can then be seen as the cost they have to pay.
• The pusher memory consumption should be stable (because of the pruning) and can be estimated by running the pusher for the required time and adjusting the deployment machine memory accordingly.
• We can statically validate whether TWAP is available for a data point just by looking at pusher.json (the _type needs to be int256).
• I guess we would want to make it a regular beacon, so we would set an additional parameter to the template. For example:

    "<BEACON_ID>": {
      "endpointId": "0x3528e42b017a5fbf9d2993a2df04efc3ed474357575065a111b054ddf9de2acc",
      "parameters": [
        { "type": "string32", "name": "name", "value": "XAG/USD",
        { "type": "int256", "name": "twapWindow", "value": "600" }
      ]
    },

or do you have a different representation in mind?

[bbenligiray]

That implies that the OIS knows about twapWindow, which is a problem because this feature won't be available for Airnode. I would say do something like this

"triggers": {
    "signedApiUpdates": [
      {
        "signedApiName": "localhost",
        "templateIds": [
          "0xcc35bd1800c06c12856a87311dd95bfcbb3add875844021d59a929d79f3c99bd",
          "0x086130c54864b2129f8ac6d8d7ab819fa8181bbe676e35047b1bca4c31d51c66",
          "0x1d65c1f1e127a41cebd2339f823d0290322c63f3044380cbac105db8e522ebb9"
        ],
        "fetchInterval": 5,
        "updateDelay": 30,
        "twapWindow": 600
      }
    ]
  },

Say we reconfigure an API provider's TWAP window from 5 minutes to 10 minutes. This won't be signaled to the end user in any way (beacuse the Beacon ID remains the same) but this is both a bug and a feature. The point of the TWAP is to come up with a number that better represents XAG/USD, so it's not obvious that the user should care about its exact configuration (this is further evidence that it should go inside OIS at an endpoint level but again, I think the amount of work needed for that isn't worth it).

[Siegrift]

That implies that the OIS knows about twapWindow

Not really. The configuration snippet is from templates section. It could be stripped out with pre-processing, similarly how we do it as of now. That said, I don't really like this hack and this just adds one more level to it.

[bbenligiray]

Right, that's quite awful

[bbenligiray]

Reminder that #207 is a thing