[DRAFT] Encrypted Derivative Value (EDV) Auction Module

[Oighty]

See #194 .

This first pass shows that a large amount of code is duplicated from EMP. We can probably refactor the common parts into an intermediate (or 2) abstract contract. My rough thoughts for this are:

• Auctions that store bids onchain in an array
• Auctions that use the ECIES encryption/decryption library

[0xJem]

It feels better to define a struct for this an put it in the interface, so that integrators know what they're dealing with

[0xJem]

What's the reasoning for having this?

[Oighty]

There may be instances where you want the winners to be whoever bids the lowest value for some parameter. Some examples are: the duration of an option, the size of an additional incentive, the strike price of a put option.

Because of this minValue may need to conditionally be maxValue

[0xJem]

This should be a check of whether start + duration > uint48 max

[0xJem]

A few thoughts on abstraction of bid array and ECIES functionality:

• There is definitely a lot of duplicated code for handling on-chain storage of bids
• We should ideally design it so that the encryption method/algo can be easily changed. e.g. standardised _decryptBid() function that can have a different implementation to support a different encryption method.
• Can a bid only have one decrypted value (e.g. amount out or derivative value), or can it be multiple values/a struct?
• Another abstraction point is what to do with the decrypted value. e.g. contents of _decrypt(), performing a check on derivativeValue and inserting it into the queue.
• Can the capacity and partial fill functionality be abstracted? Line 727 of EDV.sol

With respect to the timing... it's a pretty significant re-factor, and I feel that EMP would need to be re-audited. Do we want to hold up release for this?

[Oighty]

A few thoughts on abstraction of bid array and ECIES functionality:

• There is definitely a lot of duplicated code for handling on-chain storage of bids

Agree and think this should be it's own abstract.

• We should ideally design it so that the encryption method/algo can be easily changed. e.g. standardised _decryptBid() function that can have a different implementation to support a different encryption method.

This might make sense. As is, it should be fairly easy to swap out to a different encryption library, but good to make it explicit.

• Can a bid only have one decrypted value (e.g. amount out or derivative value), or can it be multiple values/a struct?

With the current library, it's limited to 32 bytes, but that could hold multiple values. We only use 16 bytes currently and use the others to provide a randomized mask, which makes it a little harder to brute force the decryption.

• Another abstraction point is what to do with the decrypted value. e.g. contents of _decrypt(), performing a check on derivativeValue and inserting it into the queue.

Yeah, this seems easier that the decryptBid one.

• Can the capacity and partial fill functionality be abstracted? Line 727 of EDV.sol

Maybe. It's the same in this case, but could be different if you use an algorithm that could potentially have multiple partial fills (e.g. VCG). I don't think this is as important at the moment though.

With respect to the timing... it's a pretty significant re-factor, and I feel that EMP would need to be re-audited. Do we want to hold up release for this?

I said all of the above to say. 1. I think we should create the abstractions for the EDV auction module and use them there, and 2. we shouldn't update the EMP module to use them right now. It makes sense to launch the EMP quickly and start getting some user feedback.

[0xJem]

Will get to this once I've hit a wall on Baseline, or it's done.