RFC: Light-client Friendly Orderbook

#### Background
Little background on Ask and Bid and Orderbook:
1. When Ask and Bid orders are added to the chain, they are added to the orderbook
2. The orderbook is a list of open bid, ask and deal orders
3. The orderbook's hash is calculate at every new block and added to the new block
4. In order to run MatchOrders, clients will have to query the orderbook for open orders matching their query (mostly in terms of price)

#### Standard approach
A standard approach would be to:
- have the OrderBook to be an append-only list of orders
- orders are appended to their correspondent list as they arrive

Key question: **How do nodes find matching orders?**
Here I evaluate the two different ways full nodes and light nodes can find matching orders:
- Full nodes: full nodes receive all the new blocks, validate them and keep a state tree
- Light nodes: light nodes only know the hash of the latest block and can talk to a third party and query the state tree

- Full nodes options:
- Option 1: linear (could be expensive)
- Run a linear search through the entire list of orders
- Filter the ones they are interested while scanning
- Option 2: local indexing (requires extra storage and computation for indexing)
- While receiving new blocks, they extract the orders and keep a local sorted index of orders sorted by price
- Run a sublinear search to fin matching orders
- Light nodes options:
- Option 1: trust third party (light nodes can be hidden orders)
- Ask to full node to give her matching orders
- Full nodes gives matching orders from the list and a proof of membership for each order
- However, the proofs prove that orders are in the state tree not that they are not (in order to give proofs of non-membership, the third party would have to give the entire orderbook to the light client)
- Option 2: get the entire orderbook (tooooooo big)
- Ask full node to give her full orderbook
- Check that received the right orderbook
- Run the query

#### Optimized orderbook

If we structure the orderbook in a special way such that the orders are ordered by price, then we can run proofs of memberships and proofs of non-memberships just using the Merkle tree, without sending the entire tree.

Example of proof of non-membership + membership for light nodes:
- Orders are ordered by price in the Orderbook (hence in the state tree)
- When requested a match, full nodes:
- return all the match orders as well as: the order before their match (lower price), the order after their match (higher price) and a proof of membership of those.
- in this way if the orderbook has been correctly ordered by the miners (and it is, since otherwise the block would not be valid!), then the light node has a guarantee that they got all the nodes in between their range

#### Pending questions:
- Is there a cheap way for miners to run re-ordering when creating new blocks?
- Can someone attack miners by forcing a crazy re-ordering?
- Is pricing the right ordering?
- Can we implement this just as an extra indexing that is stored on-chain beyond the standard append-only? (if so, then, this is low priority and may be introduced with hard fork)

Start with the issue's Background and Standard approach sections, then compare the full-node and light-node options with the Optimized orderbook proposal. Review the pending questions about re-ordering, attack risk, price ordering, and on-chain indexing. Done means a documented protocol decision or a follow-up specification with the chosen approach.

Written by the indexing model from the issue text.