Order Management System: Order propagation and processing in browserbook.

[Ankan0011]

In our current system, where we have designed sending the matched order to a random peer to process the matched order. But this approach can run into longer latency of the orders if the peers are not interested in order processing.

Proposed Plan Order Propagation stage will comprise below-mentioned steps:

1. Instead of sending the matched order to a random peer in the whole system, we will now ask the peers if they are interested in processing the order and be a validator.
2. We will store the peer ID of the interested validators in local indexed DB and update it.
3. Matching algorithm will match an order and send it to a random validator to process the order.

Order Processing stage will mean committing the matched order to the Polygon chain. The processing stage will comprise below-mentioned steps:

1. Order are processed by the interested user selected at random from the validators list.
2. Once the order is confirmed by paying the transaction fees of the order the validator will update the transaction hash for the order verification.

[tejareddy8888]

Stages of Orders Flow :

_{The Stages of Order Flow is narrated in 4 node as 4 characters namely Alice, Bob, Carol, Teja. Alice wants to buy alpha tokens for his beta tokens and Bob wants the other way around beta <-> alpha. Teja opts to be a matcher node. Carol is just a network participant.}

1) Order Placed:

• Alice place an order to buy alpha tokens by paying beta Tokens where she also pays additional 2% of beta tokens.
• Bob place an order to buy beta tokens by paying alpha Tokens where he also pays additional 2% of alpha tokens.
• The Orders here are signTyped here and placed in the Orders Table.
• the order status is PLACED

2) Order syncing

• Orders placed are synced between all the node participants.
• Now the Alice's , Bob's order is visible to Carol and Teja in there order DB. As Orders have been passed over PubSub mechanism and all the network participants can listen.

3) Pre-Order matching (Most trickest part)

• For Order Matching, initially atleast one of the network participant needs to opt-in as Matcher Node, in our current scenario. Teja has opted for being a Matcher node.
• Secondly, As the orders are visible to everyone in the network, The orders are passed to OMS in each network participant and a matching request for orders is placed in Matching Request table where it also random chooses a matcher node in the network and submit in that table.
• In our case, Lets assume Carol has ran the OMS first and placed the Matching Request first in the matching request table.
• Order status is MATCHED

4) Post-Order matching:

• Once the matching request is received by the matcher node which is listening on the matching request table. It will verify the duplication in the Matching Request Table and then execute that assigned particular MR signing using the Metamask.

• In our case, Teja receives the matching request and he will sign the MR.

5) Matched Order Propagation

The matched order has to be removed from the Matching Request Table in all the network participants. The order status to be changed to SUBMITTED.

6) Order On-chain Validation and Completion

• As the signature of the order of a particular network participant has to be verified to check the whether the user has signed the right order and then perform the execution of matching order. https://github.com/ethers-io/ethers.js/issues/830

• As the order gets executed and also the 2% of the beta and alpha tokens are transferred to the Exchange Contract and Teja who has submitted the order on-chain.

6) Deleting the Order

• After this listening on the events from the chain, the order status changes to FULFILLED.

[blueslurpee]

Really nice work.

"It will verify the duplication in the Matching Request Table"

How does this work?

[tejareddy8888]

Thanks for the comment, Here the idea is to create an hash or id based on the orders which are getting inserted into the Matching request id, Eg: if there is an exact order A and order B are matched there would an exact value which is generated out of it. So if someone else is trying to place same matching request then it just can deny it.

[cmbothwell]

Perfect, an "order processor" will validate that the hashed combined order is not present in the table. How do we prevent malicious behaviour, anyone attempting to duplicate orders would be blocked at the smart contract level with some sort of nonce?

[tejareddy8888]

I agree that Replay Attacks are quite common and As I referred earlier, thats were the EIP-712 comes in handy, ethersjs signTypeData comes in place, where we can design the value either using nonce or any unique value which can used only once and verify the signTypeData on the smart contract.

To extend :

I would recommend a transactionNonce of that particular client on the exchange.