search

ExchangeUnion / xud

Exchange Union Daemon 🔁 ⚡️
https://exchangeunion.com
GNU Affero General Public License v3.0
115 stars 49 forks source link

feat(rpc): OrderBook rpc call #2053

Closed sangaman closed 3 years ago

sangaman commented 3 years ago

This creates a new OrderBook rpc call to return a depth chart for the xud order book. This repurposes the logic that previously existed only in the xucli orderbook call which groups orders into buckets according to rounded price and moves that to the rpc layer, so that consumers of the API can get an xud depth chart without needing to reimplement the depth chart/bucket logic.

Closes #2048.

I haven't tested this yet so I'm leaving it in draft state for now.

raladev commented 3 years ago

@sangaman can u please fix LINTing mistakers?

sangaman commented 3 years ago

@sangaman can u please fix LINTing mistakers?

Yes, I'm going to run some quick tests myself just didn't have the time to last night. I realize I didn't open this as a draft either so I'll just leave it for now, I'll ping you when I update the PR.

sangaman commented 3 years ago

Sorry for the delay, but I've addressed the feedback and added tests, including a suite of performance tests that one can run via npm run test:perf - these aren't configured to run as part of GitHub actions but they can be used to quickly benchmark xud functions on a given machine. Organizing the order book depth chart with 20k orders is quite fast for me, below are typical results:

 PASS  test/perf/OrderBook.spec.ts (5.975 s)
  Order Book Performance Tests
    ✓ adds 10000 buy and 10000 sell orders to the order book (581 ms)
    ✓ listOrders with 20000 orders (49 ms)
    ✓ orderbook depth chart with 20000 orders (58 ms)

I fixed the sorting issue with the order book. However the rounding issue doesn't have a clear solution, the current and preexisting behavior is to round all prices to the nearest precision level. That's how a bucket's price can round down to zero, for example.

I'm thinking that it actually makes sense to always round down buy orders and always round up sell orders. The thinking being that the order book depth chart should show how much volume there is to a certain price point. If the buy side shows price of 0.01 and quantity of 0.5, to me that means I should be able to sell at a price of 0.01 and get 0.05 filled. So when a buy bucket shows a price of zero, that just means that if I market sold at any price that's how much would get filled. On the sell side of things, the logic works in reverse. Let me know if that makes sense to you and I'll make this change to the bucket rounding logic (which would be a fix/change compared to the existing functionality).

raladev commented 3 years ago

I'm thinking that it actually makes sense to always round down buy orders and always round up sell orders.

makes sense

So when a buy bucket shows a price of zero, that just means that if I market sold at any price that's how much would get filled.

Can we just change 0 to <0.01 (for --precision 2)? It definitely would be better then 0. if it hard to do on grpc side because of var type, we can just handle it in UI and cli.

sangaman commented 3 years ago

Can we just change 0 to <0.01 (for --precision 2)? It definitely would be better then 0. if it hard to do on grpc side because of var type, we can just handle it in UI and cli.

Yeah that's a good idea, I'll put in that change now and squash the commits.

kilrau commented 3 years ago

Sounds good to me!

sangaman commented 3 years ago

I fixed the rounding to work as I described and made the cli display zero values as "smaller than the smallest bucket" such as <0.01. While I was working on that it occurred to me that we'll also want to round precision to the left of the decimal point sometimes, like with BTC/USDT for instance, so I made precision a signed variable on the rpc request.