Event sourcing via more expressive events

[rainbreak]

Currently there is a single event - ItemUpdate.

When a frontend constructs the order book it scans through the event history of the market and uses getOffer to determine offer status following an ItemUpdate. More expressive events would allow the order book to be entirely event sourced.

Existing events:

• Trade(uint sell_how_much, address indexed sell_which_token, uint buy_how_much, address indexed buy_which_token)
• ItemUpdate(uint id)

Proposed new events (replacing ItemUpdate):

• Offer(uint id, uint sell_how_much, address indexed sell_which_token, uint buy_how_much, address indexed buy_which_token)
• Trade(uint id, uint sell_how_much, address indexed sell_which_token, uint buy_how_much, address indexed buy_which_token)
• Cancel(uint id)

Then each market function is associated with a single event type.

[rainbreak]

@jorisbontje: what are your thoughts on this from frontend perspective?

[jorisbontje]

1) I think the Offer event would also need to have an id attribute, so the offer can be bought or cancelled. 2) This would require clients to always sync the entire eventlog before they can do trading; otherwise partial trades would mess up the orderbook. I have some mixed feelings about this.

[rainbreak]

1) Agreed, edited OP.

2) Good point. Frontend would still be able to operate as it is now (with modified event names), so not really event sourcing.

I think one benefit would be for always-on bots: they can listen to the market and trade purely on events, although they'd still need some on chain proxy for risk free arbitrage.

[jorisbontje]

Extend Trade event with buyer and seller property. This would allow you to do reporting on your trading history. We can't have them indexed, as this would exceed the maximum number of indexed attributes (3 + 1 for the event signature).

[jorisbontje]

While we are at renaming events, I suggest to prefix the events with Log as per Peter's security audit recommendations.