search

Axis-Fi / axis-core

Axis Protocol
https://axis.finance
Other
6 stars 1 forks source link

EMPA Refactor #45

Closed Oighty closed 6 months ago

Oighty commented 6 months ago

Per recent conversations about needing to support more potential winning bidders (up to 10,000 as opposed to the current limit of around 400), this PR creates a standalone EMPA contract that avoids several costly operations:

  1. We do not create an array of winning bids in memory (memory costs increase as you use more of it) and send between contracts.
  2. We only perform a static number of transfers in the settle function (e.g. seller payment/refund, curator, partial bid fill). As a result, most bidders (win or lose) must claim their payout/refund after the auction is settled.
  3. Reduce the number of variables stored (remove abstractions not relevant in a single auction type contract) and pack them more efficiently, including making assumptions about the size of amount values (12 bytes, same as Gnosis Auction).
  4. Switch out priority queue implementation for a more scalable binary heap style implementation. This can be done since we only iterate through the queue once and do not need it to be sorted in place.
  5. Replacement of RSA encryption with an ECIES variant that uses less storage and less gas per decrypt.
Oighty commented 6 months ago

Comment from previous PR on reasoning for ECIES

Alternate encryption scheme to replace the RSA-based one: ECIES using BN254 (aka alt_bn128) curve

The two main issues with RSA are:

  1. It may be possible to come up with a combination of (amountOut, seed) that matches an encrypted bid, but that is different than what the user submitted. This should be very difficult, but we have no way to detect it.
  2. It also turns out that submitting decrypts to validate encryption opens a door to two issues both of which can't be solved at once. If a user submits an encrypted amount that doesn't follow the RSAOAEP specification, then it can't be decrypted. If you catch these errors, you allow the submitter to censor other bids by forcing them to fail by providing the wrong inputs and skipping them. If you don't catch the error, a bidder can DoS the bid settlement by submitting a bid that can't be decrypted (i.e. cannot provide values that will successfully pass the check the decryption check in the contract). This can be solved by decrypting the messages directly on-chain, but it is too gas intensive to do so (upwards of 100k gas per bid).

In this version, we use a simplified version of the Elliptic Curve Integrated Encryption Scheme (ECIES) where the auction creator provides a public key on the AltBN128 curve. Bidders create a shared key off-chain and conceal it using the public key of the auction. To settle, the private key for the auction can be provided and the encrypted amounts out can be decrypted directly using the AltBN128 ecMul precompile for ~6,000 gas. We use a simple, hash-based key derivation function and XOR encryption, which are weak by themselves, but are likely sufficient behind the EC public key cryptography.

Oighty commented 6 months ago

Closing this PR to focus on #46 . All changes here were merged into 46.