I am interested in creating an order matching contract. I started looking at a contract that Vitalik wrote....
https://github.com/ethereum/serpent/blob/master/examples/cyberdyne/market.sein the comments, he mentions.....
"This contract operates in "epochs" of 100 blocks At the end of each epoch, we process all orders simultaneously, independent of order. This algorithm prevents front-running, and generates a profit from the spread."
Can someone explain to me why he needs to prevent "front running". Is it because the miners can see the transactions and therefore front-run them?
Also interested in developing a matching engine that does both FIFO (Is this not possible in ethereum due to front-running?) and Pro-Rata...
http://www.rajeevranjansingh.com/order-matching-execution-sideAnyone who can share ideas on order matching algos would be greatly appreciated.
Comments
Vitalik proposed processing orders in batches rather than sequentially. "Specifically, let orders accumulate for a few blocks, and then come up with a list of all orders that have appeared during that time sorted by price, and them match them one by one. If "a few" is something like 5, then there are going to be enough different miners that every order will almost always get in."
Another solution from @pmcgoohan would be to randomise execution orders within a different block to order collection, and use a random number of collection blocks before execution.
There's a great post on the reddit covering all this, I recommend giving it a read through
I had some work done in this lines arround a year back for decentralised market place and came out with the conclusion that system traditional order matching alogs might not work in decentralize scenario and can cause a computational overhead as the volume of open orders records in chain can go exponential thus making it infeasible for chain to manage ordering systems looking at TPS constraints of blockchains.
My Suggestion is use of open broadcasts on the p2p network for putting a open order and execution is only stored in the chain. The proposition that i put forward is use of techniques likes CSMA / CD used in wired communications to detect interference or collisions of frames within the network. The Open orders [expression of interest for trade] is a broadcast on to the network. All clients have minor caches to store some amount of orders {i.e. pertaining to the market he /she is willing to listen to }, upon matching the order with a counter order a execution order is created (collision is created) which is sent to miner to validate.
Here is my paper on the matter for reference - https://docs.google.com/document/d/1ZRcQGHPyUHbcbKQ69fV-T2Mkf7A4jzw8JNRBvBNO1K8/edit#
I feel this can be put in place via Ethereum framework currently I am just started with ethereum paper and am finding it most interesting as each page goes by.
Nice work Eth Team