fleupold
commented
3 months ago Very nice proposal!
I'm not sure I understand the concept of the smart contract signatures. Smart contracts don't have a private key, so they cannot create signatures that can be shared offchain and easily be verified on another chain. They can modify state (e.g. set some storage slot with the semantics: "I attest that x happened") on their chain, however verifying this on another chain trustlessly (ie. without a centralized actor saying some event happened on the other chain) requires cross chain message passing, usually via light clients and advanced cryptography (which adds additional delay).
Also, I think any bridging requirement will add significant latency as most secure (ie. non-intermediated) bridging protocols have long finality times requiring potentially minutes between the mainnet settle and disburse event (unless solvers have liquidity available on all chains which seems very capital inefficient).
One idea that @mkoeppelmann had a while ago, is that maybe solvers could borrow tokens in the canonical bridge (which has inventory of all bridged tokens) against a single collateral type (so you only need $ on each chain), but this wouldn't work for native assets and require co-operation of the native bridges.
If we more or less require solvers to have inventory on all chains, I wonder how much we are gaining from "combining" the batch. There is no real atomicity in settling trades p2p (ie. solvers need to price in some risk that they will have to call revert on one chain) which makes it very similar to the current system (a solver that operates on Gnosis and Mainnet and sees a cross chain CoW could bid on both networks knowing they are likely inventory neutral if they win both auctions).
Alternative
Maybe a simpler, yet much less powerful, alternative could be to go back to a closed batch auction system where liquidity has to come from CoWs (or any inventory solvers hold). For this to work well I believe we first would need to have significant network effects though (ie a good amount of trades settled with solver inventory or protocol own liquidity) and not rely on the global atomic liquidity pool (which was 🔑 in bootstrapping CoW Protocol's success).
In this world, CoW Protocol would become somewhat like a meta-chain. On every network there would be a "deposit contract" in which users can place their sell tokens to accrue internal balance in our own ledger and where they can sign orders for this ledger. We would then hold a single batch auction given all orders and balances on that meta-chain (maybe it's an L3, maybe an app specific L2, maybe it's chain abstraction, whatever buzzword investors want to hear). The meta-chain could be represented as a single merkle-root for all balances and open orders.
A settlement would then simply be a state transition from one state of the world (old balances for each users) to a new state of the world (new balances for each user) in which signatures get verified and limit orders get executed according to the clearing price (reducing sell token balance, increasing buy token balance). Since we control the state transition and live in "our own world", there are no atomicity concerns. Such a state transition could even be implemented as a zero knowledge proof (fun fact this is how we spent the first 6 months of 2018 on this project).
Note, that this wouldn't allow to use atomic on-chain liquidity (ie other AMMs) on more than one chain (the meta-chain could still be rooted e.g. on Ethereum and every state transition could still atomically execute "interactions" in the account of the solver to sweep in liquidity).
In order to withdraw, users could claim their internal balance on any chain. There might be some delay and cost required in order to consolidate/move funds to the desired target chain via bridges.
The usability aspect of having asynchronous orders could be handled similar to how we currently handle ETH flow trades (ie once you deposit, you don't have to do anything and will eventually receive your tokens back in your designated account). However, the wait time might go up significantly depending on the security guarantees we want to impose for verifying a deposit is made on a secondary chain (maybe we could use COW staking for this?)
acanidio-econ
OrestTa
Problem
As we open on more chains, replicating (and maintaining!) multiple instances of our current chain-by-chain mechanism (with their reward scripts and accounting) will be a gigantic overhead.
To avoid this, we should have a single mechanism for a single cross-chain auction. There are many things to think about from the mechanism design perspective, but I think the main challenge is to define a global, x-chain notion of "success" and "revert" of the settlement. Here I present an idea and the changes required in the smart contract. As far as I can tell, the main change required from the smart contract perspective is to split the settlement in two parts, that can be called in different blocks.
Acceptance criteria
Have some high-level specs to define a cross-chain auction.
A possible solution: requirements
Suppose there is one "slow and expensive chain" (e.g., Ethereum) and several fast and cheap chains. Cow protocol has a settlement contract in each of those chains, but these smart contracts need not be identical.
Also, suppose that our autopilot can sign the winning solution, where here a solution is a list of interactions/transactions, one per chain. Finally, the settlement contract on the "fast and cheap" chain operates "non-atomically" in the following sense:
A possible solution: the mechanism
After the autopilot signs the winning solution, the winning solver calls the "trade" function on the settlement contract of the first "fast and cheap" chain. The first settlement contract checks the signature of the autopilot and then signs the correct execution of the "trade" function only if the solver deposits an extra bond (say 1 ETH) with the settlement contract.
With the autopilot signature and the first settlement contract's signature, the winning solver calls the "trade" function on all other "fast and cheap" chains. Note that these settlement contracts do not require the bond because the solver can prove that it deposited it with the first settlement contract. After calling the "trade" function an all "fast and cheap" chains (and collecting the relevant signatures), the winning solver accesses the "slow and expensive chain" in an atomistic way (i.e., "in" and "out" in the same transaction, like now). The settlement contract in the "slow and expensive chain" then signs that the transaction succeeded. With this signature, the solver can return to the "fast and cheap" chains except the first one and trigger the disbursement of the tokens. Each of these smart contracts then signs the successful disbursement of the tokens. Finally, the winning solver aggregates all these signatures and triggers the "disburse" function on the very first settlement contract, which also returns the bond to the solver. If one of the calls to the "trade" function or the settlement on the "expensive and slow" chain fails, then the solver needs to call the "revert" function, again in reverse order, so to receive back its bond. Failures to trigger the "revert" functions is a slashable offense.
Additional observations
If there are some cross-chain swaps, the above scheme may require that the solver contributes some of its own capital when triggering the "trade" function. For example, a user may want to swap WETH on Ethereum for ARB on Arbitrum, and the solver's solution first bridges the WETH to Arbitrum and then swaps ETH for ARB. To have the required output tokens after the "trade" function is called, the solver must contribute WETH to the settlement contract on Arbitrum. The solver can then receive back the WETH by bridging them from Ethereum to Arbitrum when calling the "disburse" function on Ethereum. However, if the solver instead proposes to "swap and then bridge", then no additional capital is required. The point is simply that solvers that can deploy additional funds may have an advantage.
Finally, "success" and "revert" are observable on chain. This may be useful for automating the payout - for example, the penalty for a revert may be automatically pocketed from the solvers' bond, so that the payout script only has to keep track of successful settlements.
Research track
smart contract v2, solvers