search

Loopring / DEX-API

The API of Loopring DEX
1 stars 3 forks source link

[3.6 API Refine] Get next order identifier API improvement proposal #46

Open luzzif opened 3 years ago

luzzif commented 3 years ago

A proposal to present an improved version of the get next order identifier API. An adapted version of its OpenAPI (written in YAML) definition can be found here.

Edit: attached new, improved documentation explaining how to locally manage the order id in case fast-paced order placing is required.

yueawang commented 3 years ago

In 3.6, we have StorageId instead of OrderId, and it is separated into 2 types: even id numbers for order called orderId, and odd id numbers for offchain requests (transfer/withdraw) called offchainId. So if a trading bot manages its storageId locally, he needs to +2 to get next valid id for a new request in same type. Do you think this setting/limitation can be well understood by API readers, especially those trading bots writers?

luzzif commented 3 years ago

Interesting, I didn't know it. I'd imagine the local order id management mechanism is the only way for fast-paced order-placing bots (market makers for example) to avoid hitting the rate limiter right? I've updated the original OpenAPI specification to be clearer on this matter.

yueawang commented 3 years ago

Yes, it's new in 3.6, API will be rename to storageId, which is used as a discontinuous nonce. For some tech limitations, we need to separate it into different types, odd/even is intuitive and easy to do. More info about the separation: As you know the history tree is still a 2^14 leave nodes tree, and the request history leaf node in that tree is located by storageId % (2^14). As we don't want to put different requests in the same history leaf node due to the complex request queueing model, odd/even is the easiest way to separate it out, otherwise, we need to calc carefully what the next slot is.