Push Based Architecture
NOTES
We will assume every solver can connect/subscribe to CoW’s auction websocket channel. The auction websocket channel emits auctions in binary streams that must be received and processed by solvers. Main difference with the current architecture is that any solver can listen to the auctions being streamed in production. We assume they do not need to be production grade (whitelisted) solvers to listen. We assume solvers will need to HTTP POST to the driver whenever they believe they have a solution. From that point of view, only whitelisted solvers should be allowed to POST to avoid malicious behavior.
PROS
-
Solvers can simulate their solutions in an environment that’s nearly the same as production.
-
Can impose screening and whitelisting requirements on solvers (such as some form of bonding).
-
Synchronized interaction from driver to solvers. It should be possible to impose time limits. POSTed results should have a trade batch ID. The driver should probably have a process to only consider results POSTed for the latest trade batch emitted.
CONS
-
Still want to maintain list of whitelisted solvers that are allowed to POST to the driver.
-
Must implement solver selection and whitelisting process.
-
Solvers may overload the driver with POST requests and the driver must maintain some sort of queue of obtained results. Alternatively, CoW could require the solvers to stream their solutions via websocket. Then, the driver needs to hold connections to all solvers and manage their incoming streams of data.
Overall, we like the current architecture better. Below is the more detailed overview of how we envision approaches 1 and 2 described above could extend the current architecture.