Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

research: Use blobs for decentralised order posting #20

Open
fleupold opened this issue Oct 30, 2024 · 0 comments
Open

research: Use blobs for decentralised order posting #20

fleupold opened this issue Oct 30, 2024 · 0 comments

Comments

@fleupold
Copy link

Problem:

Currently orders are posted to a central backend system, which batches and forwards all currently valid orders to solvers. In order to decentralise the protocol, solvers and protocol verifiers need a way to independently decide which orders are available for a given auction and thus which orders are allowed to capture "surplus".

Given the current objective criterions, it is important that only orders which were available to all solvers capture surplus. Otherwise solvers could inflate their score with "private orderflow". Private orders, e.g. in the form of inventory a solver or market maker wants to provide "just in time", are still allowed, however they must not count towards the quality of the solution (their surplus if any is ignored).

It is therefore important to have consensus around which orders where available for a given auction.

Possible Solution:

Use Ethereum's EIP-4844 blob space for cheap data availability consensus and to post orders.

An order is valid in the batch for block x if it was part of any blob committed to prior to block x.

Details

Ethereum currently allows for 6 blocks with 128KB each (https://blobscan.com/).
A regular EIP-712 signed CoW Swap order in the current format requires ~300 bytes (sellToken: 20, buyToken: 20, receiver 20, sellAmount: 32, buyAmount: 32, validTo: 4, appData: 32, kind: 32, partially fillable: 1, signature: 65). ERC1271 orders may have arbitrary signature length.

Assuming only EOA orders, we could therefore fit around 400 - 500 orders into a single blob. With perfect utilisation of blob space (ie. assuming there will be a project that allows us buying "fractions" of a blob) and current gas prices this would allow order placements for as little as 0.2 cents ($0.002) per order on mainnet.

131072 blobGasUsed * 0.0000000025 blobGasPrice * 2500 ETH price / 500 orders per blob = $0.0016

Yet, no matter how small the cost may be, order placement would no longer be free and therefore the question arises around who will pay for it (I doubt any truly decentralised solution will allow order placement for absolutely free as it could be used to spam the system).

There could be several modes that the user can chose from in the UI:

  1. Fully decentralised: ie the user takes care of posting the blob using their own gas money
  2. Specified relayer: signed order is sent to a dedicated backend and the relayer's address is specified as a "partner fee" in the app data (thus they will receive a payment if the order gets settled). The relayer can dictate the fee to be high enough that it will cover their cost "in expectation".
  3. Unspecified relayer: signed order is broadcasted over a p2p gossip network with a special type of "partner fee" (without a concrete partner address). This is later interpreted as "pay the tx.origin that posted the blob containing the order" the specified fee, thus creating an incentive for blob aggregators to collect and include orders in one of the blobs they post.

While 3) might be the right mix between UX and permissionless-ness finding the right price / partner fee for relayers to post the order may be difficult to estimate and introduce additional complexity.

Evaluation

TBD some scheme/process with which we evaluate different solutions.

One drawback of this solution is that it only works on chains that support EIP-4844 (Mainnet, Sepolia and Gnosis at the time of writing).
Theoretically one could use a credibly neutral enough chain (e.g. Gnosis) to post orders for all networks. However, this may make it more difficult to trustlessly prove the chain that the settlement is actually happening (depending on the dispute resolution mechanism that will be used it is not clear that this is feasible/desirable in the first place).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant