Open L-Kov opened 4 years ago
Looks good - I think we can say somewhat definitively the following:
dealer
must provide a gRPC endpoint for other services to check the number of times a takerAddress
has requested a quotedealer
must also provide a gRPC endpoint for services to check the number of times a takerAddress
has filled a requested quoteBoth 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:
dealer
)
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)
dealer
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).
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.
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. Thereputation-tracker
could 1) service proto requests for a taker's reputation value from other micro services (themaker
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.