tdex-network / tdex-daemon

Go implementation of the TDEX Beta Daemon
https://tdex.network
MIT License
11 stars 13 forks source link

[Draft]Local price feeder #688

Closed sekulicd closed 1 year ago

sekulicd commented 1 year ago

This is POC for incorporating price feeder inside daemon. Its purpose is to discuss potential solutions. One thing not yet clear is how do we bind tickers to base/asset pairs. Do we update existing CreateMarket RPC and add ticker per asset? Do we add new RPC RegisterAssetTicker? or smtn else?

@tiero @altafan please review.

altafan commented 1 year ago

Do we update existing CreateMarket RPC and add ticker per asset? Do we add new RPC RegisterAssetTicker? or smtn else?

I still need to check the code, but in general the ticker depends strictly on the price data source, like for example the market lbtc/usdt might have a different ticker on kraken rather than bitfinex or coinbase.

We could give the daemon's feeder component access to the domain repos to read data, but pheraps it needs a dedicated db where it can store info such as asset tickers, price sources, etc.

altafan commented 1 year ago

@sekulicd I updated the target branch for this PR. You likely forgot to set it to v1, was pointing to master

altafan commented 1 year ago

One of the key points of merging the feeder into the daemon is that we should be able to configure and interact with it via RPC calls. This means dropping the config file used by the original external service.

These could be the RPCs to be consumed by the operator:

service FeederService {
   rpc AddPriceFeed(AddPriceFeedRequest) returns (AddPriceFeedResponse);
   rpc StartPriceFeed(StartPriceFeedRequest) return (StartPriceFeedResponse);
   rpc StopPriceFeed(StartPriceFeedRequest) return (StopPriceFeedResponse);
   rpc UpdatePriceFeed(UpdatePriceFeedRequest) returns (UpdatePriceFeedResponse);
   rpc RemovePriceFeed(RemovePriceFeedRequest) returns (RemovePriceFeedResponse);
   rpc ListPriceFeeds(ListPriceFeedsRequest) returns (ListPriceFeedsResponse);
   rpc ListSupportedPriceSources(ListSupportedPriceSourcesRequest)
      returns (ListSupportedPriceSourcesResponse);
}

message AddPriceFeedRequest {
   Market market = 1;
   string source = 2;
   string ticker = 3;
}
message AddPriceFeedResponse {
   string id = 1;
}

message StartPriceFeedRequest {
   string id = 1;
}
message StartPriceFeedResponse {}

message StopPriceFeedRequest {
   string id = 1;
}
message StopPriceFeedResponse {}

message UpdatePriceFeedRequest {
   string id = 1;
   string source = 2;
   string ticker = 3;
}
message UpdatePriceFeedResponse {}

message RemovePriceFeedRequest {
   string id = 1;
}
message RemovePriceFeedResponse {}

message ListPriceFeedsRequest {
   Market market = 1;
}
message ListPriceFeedsResponse {
   repeated PriceFeed price_feeds = 1;
}

message ListSupportedPriceSourcesRequest {}
message ListSupportedPriceSourcesResponse {
   repeated string price_sources = 1;
}

message PriceFeed {
   string id = 1;
   Market market = 2;
   string source = 3;
   string ticker = 4;
}

With these RPCs, it would be up to the operator to specify the price source and the asset ticker for a market price feed and he could check the list of available sources with ListSupportedPriceSources at anytime. These APIs give also a lot of flexibility to the operator because he could tweak the configuration of a market price feed at will (by always stopping it first, similar to the management of a market), for example to change the price source and ticker, or also to just change the ticker if he set a wrong one by mistake. Last but not least, a price feed could be removed if for example the operator changes strategy for the market and doesn't need the price feed anymore.

One (cool?) thing that just came up in my mind while writing would be detecting the change of strategy and automatically starting or stopping a price feed, if any exists for that specific market. Could be a feature to add for future iterations, just brainstorming ideas.

tiero commented 1 year ago

Yes agreed on having RPCs to configure the feeder. I would retail the "well knonw pairs"

Ie. We can hardcode that LBTC and USDT asset hash to known ticker for each API, so when you "attach" a feed to a market via RPC it will read the market and auronativally bind

sekulicd commented 1 year ago

Yes agreed on having RPCs to configure the feeder. I would retail the "well knonw pairs"

Ie. We can hardcode that LBTC and USDT asset hash to known ticker for each API, so when you "attach" a feed to a market via RPC it will read the market and auronativally bind

@tiero can you elaborate more on reasoning behind "well know pairs"? why do we want to kind override user input when he adds new feed to market?