Closed sunce86 closed 1 week ago
We should distinguish more more what component we mean when we say "Auction". Currently the api has an /auction endpoint. That data comes from the database where it is stored by the Autopilot. This "auction creation" happens I think every 1 or 2 seconds, doesn't store liquidity (but uses it to calculate native prices, and can change even outside of new blocks (when a user cancels an order).
I see. I was referring to the Auction
as a struct used in a single driver run loop.
I think our medium term plan is still https://github.com/cowprotocol/services/issues/230 which decides a bunch of the points in your posts because there is less reason to react to blocks and driver run loops would be defined by how auctions get created in Autopilot. But the points are valid for deciding when Autopilot should create auctions.
Also related to #545
This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.
This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.
Will be tackled this quarter
Block mining under POW consensus is random (but expected to be at 13s on average). I assume this randomness is the reason why our
Auction
creation is completely independent of the block mining, because if it were dependent, we would sometimes have long times without newAuction
taking into consideration newly created orders.With POS activated, blocks are mined each 12s. We should leverage this information to better time the
Auction
preparation and simulation/submission of settlements.Expected changes:
Auction
to be prepared each 24s (each two blocks) instead of 30s as is now, and synchronize it to be done after acknowledgment of the new block (we can change it later to 12s when number of submitted orders per second is increased).Maintaining
trait implementers (mainly liquidity fetchers) need to be executed sequentially(before) withAuction
creation, and not in a background task. For this, additional work on performance of liquidity fetchers is needed (currently in progress).Theoretically, I expect this change to improve our roadmap item "Execution Speed". Solvers would always work with the newest Ethereum state, while at the moment, they occasionally work with the one/two blocks of old liquidity. With this, we can enter the settlement submission knowing the solution is always based on the latest block, therefore possibility of revert of transactions is reduced and dependable only on the position in the pending block and not on the Ethereum state changes introduced by previous block/s. Additionally, simulation inside settlement submission loop can be adjusted to be done every 12s instead of every 2s as now, and synchronized with new blocks.
WDYT, what else needs to be done or what should the implementer of this task be aware of?