Author Topic: Clarification on trading engine & matching  (Read 3145 times)

0 Members and 1 Guest are viewing this topic.

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit


Does it take any account of the time sequence in which orders were submitted during the 10 second interval of that block? If not, how are equal orders for that block prioritised for fills?

AFAIK there is no defined behaviour. A delegate can choose as he likes. FCFS is a good assumption, but keep in mind that in a P2P network different nodes may see new transactions arrive in different order.


This is just an uneducated thought, so treat me kindly! I find it strange that delegates could potentially take the same set of orders, and derive a different match. I'm surprised this does not make it difficult for others to agree upon and verify, or is this not a problem? I guess I would have expected that if timing of orders within a block cannot be agreed upon, then the only way to get agreement on the matching is to treat all orders in a block as simultaneous. I feel like the nature of discrete block production seems to call for an auction-based clearing mechanism on each block rather a traditional time-based one.

To clarify, there is (AFAIK) no defined behaviour for *including competing transactions in a block*. Once the transaction has entered the block (and the order has entered the book), the behaviour is completely deterministic. Otherwise distributed consensus could not be achieved.
OK, got it now, thanks for the clarification. And that deterministic matching procedure for orders that have entered the block is what pc just described. Makes sense now.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Ok, but the rest of what I said should be accurate?

Yes, basically. The market engine always looks at the highest bid and lowest ask, taking shorts and covers into account. When the highest bid and the lowest ask overlap, a trade is executed. After that trade, at least one of bid and ask has been consumed completely. The process continues with the next highest/lowest until there is no more overlap.

Owner address sorting basically just means that serious traders can use proof of work to get preferential order matching treatment by finding a "better" address to trade from.  Not catastrophic, just a little weird.

I just wonder what happens when there are two orders with the same price and owner... shouldn't happen in practice because the client creates a new owner address for every transaction.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
I believe orders are matched highest bid to lowest ask, and that only equal priced orders are sequenced non-deterministically.  I'll have to confirm this.

No, equal priced orders are ordered according to their owner address.

Hm, as I'm writing this I realize this could be a problem...

Ok, but the rest of what I said should be accurate?  Owner address sorting basically just means that serious traders can use proof of work to get preferential order matching treatment by finding a "better" address to trade from.  Not catastrophic, just a little weird.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
I believe orders are matched highest bid to lowest ask, and that only equal priced orders are sequenced non-deterministically.  I'll have to confirm this.

No, equal priced orders are ordered according to their owner address.

Hm, as I'm writing this I realize this could be a problem...
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano


Does it take any account of the time sequence in which orders were submitted during the 10 second interval of that block? If not, how are equal orders for that block prioritised for fills?

AFAIK there is no defined behaviour. A delegate can choose as he likes. FCFS is a good assumption, but keep in mind that in a P2P network different nodes may see new transactions arrive in different order.


This is just an uneducated thought, so treat me kindly! I find it strange that delegates could potentially take the same set of orders, and derive a different match. I'm surprised this does not make it difficult for others to agree upon and verify, or is this not a problem? I guess I would have expected that if timing of orders within a block cannot be agreed upon, then the only way to get agreement on the matching is to treat all orders in a block as simultaneous. I feel like the nature of discrete block production seems to call for an auction-based clearing mechanism on each block rather a traditional time-based one.

To clarify, there is (AFAIK) no defined behaviour for *including competing transactions in a block*. Once the transaction has entered the block (and the order has entered the book), the behaviour is completely deterministic. Otherwise distributed consensus could not be achieved.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Actually not at the end of each block but somewhere in between. An important point is that the market engine runs *before* new orders are applied to the market, i. e. after creating an order it will take at least two blocks before it has been executed.

What's the rationale behind this? Why aren't orders matched as they go into the current block?

Not sure. It was changed on or slightly before Aug 27 it seems. Maybe something to do with the possibility of delegates front-running orders.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Actually not at the end of each block but somewhere in between. An important point is that the market engine runs *before* new orders are applied to the market, i. e. after creating an order it will take at least two blocks before it has been executed.

What's the rationale behind this? Why aren't orders matched as they go into the current block?

I believe orders are matched highest bid to lowest ask, and that only equal priced orders are sequenced non-deterministically.  I'll have to confirm this.

If this is the case, then it won't be known which orders should match until the full list of orders for the given block is complete.  Then, the actual processing of the order list takes some time, and delegates don't want to miss their block production time.  So then the only way is to finalize the order list in one block, process that list between blocks, and then finalize it in the following block.

Offline monsterer

Actually not at the end of each block but somewhere in between. An important point is that the market engine runs *before* new orders are applied to the market, i. e. after creating an order it will take at least two blocks before it has been executed.

What's the rationale behind this? Why aren't orders matched as they go into the current block?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
That's really illuminating, thanks guys! It's just amazing the thought and work that has brought this all together.



Does it take any account of the time sequence in which orders were submitted during the 10 second interval of that block? If not, how are equal orders for that block prioritised for fills?

AFAIK there is no defined behaviour. A delegate can choose as he likes. FCFS is a good assumption, but keep in mind that in a P2P network different nodes may see new transactions arrive in different order.


This is just an uneducated thought, so treat me kindly! I find it strange that delegates could potentially take the same set of orders, and derive a different match. I'm surprised this does not make it difficult for others to agree upon and verify, or is this not a problem? I guess I would have expected that if timing of orders within a block cannot be agreed upon, then the only way to get agreement on the matching is to treat all orders in a block as simultaneous. I feel like the nature of discrete block production seems to call for an auction-based clearing mechanism on each block rather a traditional time-based one.


Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Is it the case that orders submitted, cancelled or filled during a 10 second round, cannot be received and displayed by clients as part of the market state until that block is produced and synced? (as opposed to being broadcast immediately for all clients to display in the market state?).

New transactions are broadcast through the network immediately, and in that sense they are also "visible" to everyone. But as Xeroc pointed out, the market frontends normally only display orders that have been included in a block.


Does the matching algorithm effectively get applied once every 10 seconds at the end of each block, when it is produced?

Actually not at the end of each block but somewhere in between. An important point is that the market engine runs *before* new orders are applied to the market, i. e. after creating an order it will take at least two blocks before it has been executed.


Does it take any account of the time sequence in which orders were submitted during the 10 second interval of that block? If not, how are equal orders for that block prioritised for fills?

AFAIK there is no defined behaviour. A delegate can choose as he likes. FCFS is a good assumption, but keep in mind that in a P2P network different nodes may see new transactions arrive in different order.

Do certain order types get sequenced before others?

The market engine checks expired and margin-called covers before regular orders. Shorts executing at the price feed are sorted by interest offered. Apart from that, all orders should be checked in order of their execution price.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
A couple of things I realise I'm still not clear on. I'm happy to be pointed to a document that explains this in simple terms.
I am not a dev but may can help out with my understanding of things
Quote
Is it the case that orders submitted, cancelled or filled during a 10 second
round, cannot be received and displayed by clients as part of the market state
until that block is produced and synced? (as opposed to being broadcast
immediately for all clients to display in the market state?).
Yes .. the client currently only takes confirmed transactions as valid .. though
there is a extra command to schon pending transaction in the network

blockchain_list_pending_transactions

Quote
Does the matching algorithm effectively get applied once every 10 seconds at the
end of each block, when it is produced?
AFAIK that is what is happending .. but the results of the matching algorithm
are not transactions .. in the client they show as 'virtual'. Hence, they are
performed in every client ..

That's why in order to make modifications in the market or the matching require
a hard fork .. so that the clients use the same protocol.

Quote
Does it take any account of the time sequence in which orders were submitted
during the 10 second interval of that block? If not, how are equal orders for
that block prioritised for fills?
From what I know, they are not prioitiesed .. First come first serve. Though
this might become a business opportunity. Imagine you have a delegate and
someone wants to make sure that the next block (which you will have to sign)
contains his market transactions .. then you can offer the deal to do so for a
fee. Though I am uncertain as to what shareholders think of it and how long a
delegate could run this business.

Quote
Do certain order types get sequenced before others?
sequenced in terms of "ordered by price"?
I don't really know :(

Offline lastagile

  • Full Member
  • ***
  • Posts: 144
    • View Profile
is it auction cross


从我的 iPhone 发送,使用 Tapatalk

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
A couple of things I realise I'm still not clear on. I'm happy to be pointed to a document that explains this in simple terms.

Is it the case that orders submitted, cancelled or filled during a 10 second round, cannot be received and displayed by clients as part of the market state until that block is produced and synced? (as opposed to being broadcast immediately for all clients to display in the market state?).

Does the matching algorithm effectively get applied once every 10 seconds at the end of each block, when it is produced?
Does it take any account of the time sequence in which orders were submitted during the 10 second interval of that block? If not, how are equal orders for that block prioritised for fills?
Do certain order types get sequenced before others?

Thanks.