Open Oighty opened 1 month ago
A few thoughts on abstraction of bid array and ECIES functionality:
_decryptBid()
function that can have a different implementation to support a different encryption method._decrypt()
, performing a check on derivativeValue
and inserting it into the queue.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?
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 onderivativeValue
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.
Will get to this once I've hit a wall on Baseline, or it's done.
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: