Questions & Tradeoffs

[thaaddeus]

1. In order to provide L3 diffs (order open, change, fill, done) I need to process accounts notifications for the same slot in batch and that requires a little bit of client syncing and potential delay. I've also noticed that sometimes notification for the same slot but different accounts are returned with multi seconds delays (for example bids account notification then few seconds passes and event queue account notification), not sure why is that, perhaps Serum Node being busy?
   When RPC: add ability to subscribe to multiple accounts notifications - accountsSubscribe solana-labs/solana#12237 is implemented (subscribing to multiple accounts notifications) it should be resolved so there's one notification message for multiple accounts for single slot.

2. I'm using confirmed/singleGossip commitment level when subscribing to Solana's RPC account notifications as using recent/processed isn't reliable due to potentially frequent forks that mess up with calculating diffs for L3 data (it uses bids,asks and event queue accounts data to create the diff).
   Drawback of it is that notifications can be lagging vs 'recent' commitment but more reliable on the other hand. There's a way to switch serum-vial to use recent/processed commitment, but when validating L3 diffs it's rather frequently invalid, it does not happen for confirmed. Anyways if there would be a way to detect that node has performed a rollback(moved from the local fork to majority fork) via RPC sub, then I could reset local state, but as far as I know that is not possible now.

3. The way subscriptions work is by subscribing to market name not market address, that makes it impossible to handle both depreciated and current markets via single serum-vial server (one would have to run two instances one for v2 one for v3 for example), would it be better to use market address instead? I picked market name as it's more user friendly & human readable but perhaps it's not the best choice.

4. Handling real-time notifications for event queue account is rather resource intensive, but even what is more important it's consuming a lot of bandwidth (due to its size and frequent updates), not sure if there's a way to improve that somehow? Upside of using real-time notifications vs REST pooling is faster detection of fill/trades/cancellations etc.

5. It would be great is someone could review the mapping logic that maps raw accounts data to normalized messages and diffs - it's located in https://github.com/tardis-dev/serum-vial/blob/master/src/data_mapper.ts - from my testing both L2 and L3 data match what is visible in DEX UI, but perhaps there are some edge cases that aren't covered, not sure.

6. It would be great is someone could review normalized messages format if all necessary fields are there etc https://github.com/tardis-dev/serum-vial#data-messages. I'm sending price & size as strings to prevent potential precision issues (due to node.js not having decimal type), but perhaps that's an overkill, not sure.

7. Is trade message detected correctly here https://github.com/tardis-dev/serum-vial/blob/master/src/data_mapper.ts#L235 ? I know serum-ts is using maker===true, serum-rest-server is using maker===false which is also what I'm using (trade is a fill from the liquidity taker order perspective)

[thaaddeus]

From serum discord:

Thaddeus on #10

1. I'd guess it's because you have different websocket connections open which means you can be connected to different validators which may be ahead or behind each other. As you pointed out, this would be resolved if there was a single websocket connection for subscribing to multiple accounts.
2. Not sure if that's possible. Using confirmed/singleGossip seems like the right move.
3. Without more context it seems like address is better, or you need some type of mapping from name to address/is_deprecated. Something like what some UIs use, e.g., this https://github.com/project-serum/serum-ts/blob/master/packages/serum/src/markets.json.
4. I don't think subscribing to accounts as is done now is a long term solution. Solana either needs the rpc to allow streaming account diffs or programs should use msg! logs to emit events, which can then be indexed and queryable however a client + data store wants. I think the latter is the better path forward and I'm working on API for that here Events coral-xyz/anchor#89

Thaddeus — 03/24/2021
armaniferrante | Will never DM appreciate the answers!

1. I'm using single connection per market so that doesn't seem to be the case, maybe I'll try with hosting local node and see it it makes any difference
2. thanks, do you see serum-ts also moving to 'confirmed' commitment by default in the future?
3. got it, https://github.com/project-serum/serum-rest-server also uses names not address, but will give it some more thought
4. hmm, interesting, I agree that it's not really scalable, will look into msg logs more, but kind of assumed those are more of a debug logs, so it would work smth like you add bunch of msg! logs to DEX code (like order opened/matched etc) which can be subscribed to similarily to accounts notifications, right? that would definitely make the payloads more lightweights, just format would need to be defined and relatively stable

Thanks!

Thaddeus
armaniferrante | Will never DM appreciate the answers! 1) I'm using single connection per market so that doesn't seem to be the case, maybe I'll try with hosting local node and see it it makes any difference 2) thanks, do you see serum-ts also moving to 'confirmed' commitment by default in the future? 3) got it, https://github.com/project-serum/serum-rest-server also uses names not address, but will give it some more thought 4) hmm, interesting, I agree that it's not really scalable, will look into msg logs more, but kind of assumed those are more of a debug logs, so it would work smth like you add bunch of msg! logs to DEX code (like order opened/matched etc) which can be subscribed to similarily to accounts notifications, right? that would definitely make the payloads more lightweights, just format would need to be defined and relatively stable Thanks!

armaniferrante | Will never DM — 03/24/2021

1. Oof sounds like a real problem, then.
2. Not sure.
3. I don't think it matters as long as you get the right market.
4. Correct that's how it would work. The format linked above is base_64_str(unique_discriminatator || borsh_serialize(event_struct)) I hope in the future the dex can emit things like fills, so that, to get things like a csv of all trades, one would just look at all the fill events.(edited)

Thaddeus — 03/24/2021
awesome, thanks!