research(contracts): Order.Data struct (aka GPv2Order.Data)

[mfw78]

Problem

There have been some limitations observed in the current GPv2Order.Data struct that have led to issues such as circular hashing.

Acceptance criteria

• [ ] Proposed struct parameters meet current and future use cases
• [ ] Free of circular hashing problems
• [ ] Capable of being generated on-chain (ie. no fields are the result of some arbitrary off-chain calculation / hashing).

Details

TBD

Possible Solutions

TBD

Research track

• Developer experience

[mfw78]

Suggest to include a field that is a nullifier. IE. on a a discrete order being settled by the settlement contract, storage slot nullifiers[from][nullifierFromOrderData] = true.

This would allow for easily reasoned "one-cancels-the-other", and would actually be supported by any signing scheme.

Optionally, could also introduce a trade flag that allows for this logic to be inverted (only trade if the nullifer has been nullified). This allows for logic such as "one-creates-another".

Overall this would drastically reduce the complexity required when reasoning about conditional orders that generally either require some storage slot used on some specific handler contract, or relies upon the filledAmount in the settlement contract (which in and of itself creates issues with freeFilledAmountStorage).

[fleupold]

Suggest to include a field that is a nullifier. IE. on a a discrete order being settled by the settlement contract, storage slot nullifiers[from][nullifierFromOrderData] = true.

Wouldn't this potentially cause problems with programmatic orders where a malicious observer could potentially front run any orders placed by a watch tower with random other orders for the same nullifier?