Replies: 3 comments 2 replies
-
This is super cool! Thank you for writing it up. Some preliminary thoughts:
|
Beta Was this translation helpful? Give feedback.
-
Thanks for the issue and the question.
So, if everything is routed via the KEOM frontend, it should be okay, right? If there is a frontend where traders need to log in and trade, then you can easily build it so that users submit the transactions to KEOM and not to the operator—at least for a PoC. A user can still "hack" around it, import the transactions into his / her own client, and submit them to the operator. But as Bobbin said, for the first couple of months that might be ok.
Another solution might be to add another optional field
Then, the user would create the |
Beta Was this translation helpful? Give feedback.
-
By the way, apart from the security aspect. I am trying to assess if KEOM can run as a sequencer/intermediary. For this, KEOM would need to submit multiple transactions as a batch via the client. I assume this is only possible if the following conditions are met:
|
Beta Was this translation helpful? Give feedback.
-
Spending future notes allows transactions to consume notes that are created during the transaction, in addition to being able to pre-compute output note ids for a transaction consuming a particular input note.
The goal is to allow KEOM to receive and batch multiple fulfillments in the same block.
Below is a graphical representation of a limit order, Bob starts by creating a limit order note, Alice partially consumes the limit order, resulting in 2 output notes (A clone of the limit order with the unconsumed amount and a P2ID note consumable by the original maker -Bob-). This flow repeats until the original limit order is fully consumed or until the original maker cancels/recalls their order.
Limit Orders
Below is a sequence diagram describing the flow and interactions during a limit order creation. It's straight forward, a trader asks KEOM how to build the transaction, KEOM responds with a serialized transaction, the trader then executes and submits the transaction directly to the operator. KEOM polls the operator to see if the note is included in order to update it's internal order book state accordingly.
Market Order
The sequence diagram below describes the flow and interaction of a market order. A trader wants to buy some asset and they don't care about the price. The trader asks KEOM which then responds with the notes they should consume in a serialized format. The trader proceeds to consume the order by executing the transaction then submitting it to the operator.
Problem
The order book performance in the above design is bound to the block time of Miden since KEOM backend has to wait for inclusion proofs from the Node Operator before it can consider an order filled/consumed
Workaround
Traders to submit their transactions to KEOM instead of directly to the operator. This would allow KEOM to keep tighter track of inclusion status of notes. It would also allow KEOM to make use of future notes features. In the case of partial order consumption, KEOM would be able to respond with future NoteIds to different traders without waiting for the original note to be included. This is because KEOM has full visibility and control of the sequence of transactions/submissions to the operator, unlike the current scenario where KEOM has to trust users to submit their orders to the operator on time.
The problem with this workaround is that it assumes full trust that users won't submit their transactions directly to the node operator rendering KEOMs transactions invalid.
One solution is to have the limit orders be multi-signed by the trader and KEOM specific special account. Since this is not available in miden yet. I have created this issue to braistorm potential workarounds/solutions that would allow the order book to achieve subsecond TPS performance with the existing tool-chain.
Beta Was this translation helpful? Give feedback.
All reactions