✨ Data Proxy Registry

[Thomasvdam]

✨ Feature

Motivation

The data proxy registry module will serve as a repository for public keys and the fee of the associated data proxies.

After executing a proxy_http_fetch method an overlay node will query the data proxy registry with the public key it received from the upstream data proxy node. It can use the params to determine the amount of gas that was consumed by the proxy_http_fetch call.

Warning

We will want to implement a delay to fee updates to prevent attacks and give consumers a chance to respond to fee changes.

Implementation

The store for this module would have the following key-value scheme:

[map]  public_key -> data_provider_params
# Delayed update queue
[set]  height/timestamp | public_key
[item] module_params

Where data_provider_params are the settings to be used for that provider:

• Payout address: a seda address that receives the rewards for providing data-proxy services.
• Fee in aseda: the cost of the data-proxy service. This can be converted to gas using the gas price of a data request.
• Upcoming fee: a data-proxy operator can schedule a fee change to give consumers the opportunity to edit their data requests. Null when no fee change is scheduled. Otherwise a struct that includes the new fee and the height at which it comes into effect.

module_params should at least include:

• Fee update delay: a positive integer that specifies how many blocks need to pass before a fee change comes into effect.

There should be 2 transaction endpoints. One for registering a key with params, and another to edit the params for an existing public key.

$ sedad tx dataproxy register <pubkey> <params> --from <address>
# Updates the payout address right away. If a new fee is specified it will be scheduled according to the delay in the module params, unless a manual delay is specified (which should be higher than the minimum).
$ sedad tx dataproxy edit <pubkey> <params> --from <address> [--delay int64]

Scheduling a fee update while there is already a pending fee update overwrites the old one with the new update and calculates a new effective height based on the delay.
This should also remove the old entry from the queue.

There should be a query endpoint to retrieve the params for a particular public key.

$ sedad query dataproxy proxy-params <pubkey>