search

ParadigmFoundation / zaidan-monorepo

Zaidan Liquidity Monorepo
2 stars 0 forks source link

reputation tracker service #23

Open L-Kov opened 4 years ago

L-Kov commented 4 years ago

Overview

This issue provides a high level specification for a service designated reputation-tracker that is responsible for managing reputation values for individual takers in an attempt to provide a more informed pricing model.

Details

One important lever the Zaidan model provides the market maker is the ability to influence prices based on the particular taker requesting the quote. This is particularly important when you consider both the taker optionality (limited, but still present to some degree) and potential out-of-band cancellations. To take full advantage of this privilege the dealer retains, it makes sense to consider a stand-alone reputation tracking service. The service would be responsible for providing a numeric value in the range (0,1) representing the likelihood of a particular taker address being adversarial.

We could approach this problem as either a binary classification problem or as a regression problem. Personally, I lean towards treating this as a regression problem, the output of which we can treat as an input into a pricing model (check out this notebook) that influences a quote premium. Over some threshold (e.g. 95% confidence of an adversary) a taker address could be blacklisted and the system will refuse to service their quote requests. A taker address that has never interacted with the system, could initially be treated as a potential adversary (e.g. .75 regression value) and would become, assuming continued benevolent behavior, more trusted over time, resulting in more favorable pricing. We will need to develop a framework for building our regression problem. For that we can defer to the zaidan-research repository. This issue, will thus focus on the services positioning and interaction with the overall system.

The reputation-tracker is quite simple from an interface perspective. The reputation-tracker could 1) service proto requests for a taker's reputation value from other micro services (the maker specifically) or 2) could continuously update a mapping/table that provides reference from a taker address to a reputation value in some shared database.

The reputation-tracker will need to have access to a continuously updating table of information for takers that have interacted with the system. The service will process this raw data ultimately producing a reputation value. Information that seems immediately valuable in the context includes:

Ideally the system will be able to immediately react to changes in the data alluded to above. In reality, a batched approach to taker evaluation will likely be sufficient (if there is ever a terribly mis priced quote we could disregard it). For this reason, the system might be able to simply read from a shared database, assuming some other service is responsible for updating the necessary information, and adjusting reputation values upon every (or discrete groups) of observed change.

hrharder commented 4 years ago

Looks good - I think we can say somewhat definitively the following:

Both of these can likely be inferred from the current table structure for QUOTES and TRADES we will established in services/dealer/db (see #18).

On the question of:

the size of requested quotes

Some more specificity is likely needed. We can do one/several of the following:

  1. Allow services to check the total trade volume for each supported asset (note 1)
  2. Allow services to get an array of all quote ID's for a given taker address (from the dealer)
    • This could be broken into two methods: one for all quotes, one for successful trades
  3. Allow services to get a past quote/trade from the DB by its quote ID (note 2)

If we do (2) and (3) above, we could allow the consuming service (in this case the reputation-tracker) to define how "size of requested quotes" is calculated and used to affect the ultimate reputation score.

Personally, for in this case, I lean toward doing (2) and (3) and leaving out the USD value calculation for the time being. That being said, at some point it will likely make sense to start recording USD value at the time trades are executed for both the makerAsset and takerAsset.

(cc @gchaincl on the points mentioned above re. our DB package)

Notes

  1. If we want to do this in USD, we would need to store USD value of all trades at the time they took place
  2. This should already be the plan, and will be supported by gRPC calls to the dealer
L-Kov commented 4 years ago

For simplicity I think we should ignore the size of requested quotes initially. I suspect the other two pieces of data (# of QUOTES and # of FILLS) will be more predictive anyway.

With this said, I think we need to specifically consider how the reputation-tracker consumes/requests the necessary data. For efficiency considerations the reputation-tracker should only need to get addresses and their corresponding values if they have changed since it last calculated reputations. For this reason I think there are two models that work:

1) the dealer provides a gRPC endpoint that takes a timestamp (or number if there is some ordered representation of the data) as a parameter. The dealer's response will then be all the address/value mappings for which the value has changed (both QUOTES and TRADES) since the specified timestamp.

2) A pub/sub mechanism where the reputation-tracker service can subscribe to updates of value changes for addresses' QUOTES and TRADES.

Option (2) seems ideal as it is the most performant since reputation scoring updates happen immediately, rather than in batches like (1).

hrharder commented 4 years ago

This is where @gchaincl I think you can help us. I don't have a good sense of what a pub/sub mechanism might look like here, or if it could use gRPC.

What do you think? We can chat about this on Monday.