# State Lock Auctions: Towards Collaborative Block Building
**URL:** https://collective.flashbots.net/t/state-lock-auctions-towards-collaborative-block-building/3019
**Category:** Research
**Tags:** mev-boost, brainstorming, pbs
**Created:** [February 3, 2024, 11:16pm UTC](https://collective.flashbots.net/t/state-lock-auctions-towards-collaborative-block-building/3019 "2024-02-03T23:16:44Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@dmarz](https://collective.flashbots.net/u/dmarz)
#### Post date: [February 3, 2024, 11:16pm UTC](https://collective.flashbots.net/t/state-lock-auctions-towards-collaborative-block-building/3019/1 "2024-02-03T23:16:44Z")
# State Lock Auctions: Towards Collaborative Block Building
_Many thanks to [Conor](https://twitter.com/ConorMcMenamin9), [Quintus](https://twitter.com/0xQuintus), [Louis](https://twitter.com/LouisThibault87), and [Shea](https://twitter.com/SheaKetsdever) for discussions and comments that inspired this post._
_Cross-posted here [State Lock Auctions: Towards Collaborative Block Building - Block proposer - Ethereum Research](https://ethresear.ch/t/state-lock-auctions-towards-collaborative-block-building/18558)_
## Overview
Due to the public first-price nature of the [MEV-boost auction](https://github.com/flashbots/mev-boost), searchers are incentivized to vertically integrate, becoming “searcher-builders” to [bid “more strategically”](https://ethresear.ch/t/mev-burn-a-simple-design/15590/17?u=dmarz). This verticalization aimed at gaining an edge in the MEV-Boost auction has had the unfortunate consequence of considerably raising the barriers to entry for statistical arbitrage, and as a follow on consequence, has created an unfavorable market structure where new “searcher-builders” are bulk purchasing orderflow from other builders and subsidizing blocks as an effective “advertisement spend” to reach orderflow parity with incumbent block builders. Attempts to remove this edge from “strategic bidding” have primarily been focused on [modifying the auction into a sealed-bid format](https://github.com/flashbots/mev-boost/issues/112), all of which have fallen short as they introduce new collusion vectors in the absence of private and credible commitment technology such as MPC, FHE, and TEEs.
Greatly borrowing from distributed systems literature, this post sketches a proposal for enabling the ability to “lock state” through an open auction in the mev-boost protocol, with a follow-on feature of providing visibility into this “locked state”. The ultimate outcome of this approach is that block builders are no longer effectively “[pipeline stalled](https://en.wikipedia.org/wiki/Pipeline_stall)” via uncertainty in constructing the rest of the block, which opens the door for “Collaborative Block Building”. In distributed systems terms, we are creating a “[boot leg](https://en.wikipedia.org/wiki/Rum-running)” decentralized multi-version concurrency control system for the ethereum distributed state machine by [leveraging visibility](https://arxiv.org/pdf/1704.01355.pdf).
The main advantages of this approach are that it maintains basic privacy and bid update-ability to searchers competing in these high-velocity arbitrages, supports more generic arbitrage compared to previous “laned” approaches, and is easily deployable into the current market. The main drawbacks are its creation of a “pseudo-enshrinement” of single transaction arbitrages at the top of the block and offering a new censorship and griefing vector. As this proposal is merely a sketch, there are still large unknowns around how to effectively price the cost to lock state, the effects on searcher’s bidding strategies, and how to generalize the auction past the ability to lock a single set of states.
## Desirable Properties for a State Lock Auction
While not exhaustive, some immediately apparent favorable properties:
1. **Locker Safety** - Revealing the address of the person who locked the state before the block is confirmed creates a targeted DoS vector.
2. **Bid Update-ability** - A searcher who commits to a state lock should be able to update the parameters of their transaction as long as it does not modify the state access list.
3. **Locked State Visibility** - The storage slots of a locked state should be publicly visible to block builders.
4. **Guaranteed Lock Payment** - Whether a searcher updates the bid or not, a payment transaction should be included in the block for locking state.
5. **Squatting Resistance** - Ensuring the cost to lock up extensive amounts of state is prohibitively high to prevent griefing.
6. **Contention Aware** - The price of a lack should reflect the amount of interest in writing to that state.
## Access Lists
For most of this post we refer to the state to be locked as an “access list”. In the context of [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), a state access list A is defined as a sequence of tuples:
A = [( \text{address}, [ \text{storageKey}\_1, \text{storageKey}\_2, \ldots] ), \ldots ]
Where:
- \text{address} is an Ethereum address of a contract or an Externally Owned Account (EOA) that the transaction interacts with.
- [\text{storageKey}\_1, \text{storageKey}\_2, \ldots] represents a list of storage keys within the specified contract’s storage the transaction will access.
An example access list for a swap is shown in [Appendix A](#A-Example-Access-List).
## Proposal: Relay Run Single Lock Auction
Representing searchers as S, the relay as R, and partial block builders as PB, the auction process unfolds as follows:
1. **Open Auction** :
- Prior to the cutoff time T\_{cutoff} seconds into the slot, searchers submit their state lock commitments to R with two distinct transactions:
1. **Winner Selection** :
- At T\_{cutoff}, R picks the highest bid:
b\_{max} = \max(\{b\_i | b\_i \geq \text{LockCost}(A\_i), \forall i \in S\})
- R then discloses the winning access list A\_{max} associated with b\_{max} to anyone who calls:
\text{GetLockedState}(n)
1. **Bid Updating and Partial Block Submission** :
Two main activites can occur post winner selection:
- The winning searcher addr\_{max} can update their state access transaction facilitated through:
- Partial block builders query GetLockedState(n) for A\_{max}, build partial blocks based on this information, and submit them using:
Below is an artist’s rendition of the above auction process.
A rough sketch of the changes to the relay spec can be seen in [Appendix B](#B-Rough-Relay-Spec-Change).
### Analysis
This approach meets most of our core objectives for a state lock system: ensuring **Locker Safety** , **Bid Update-ability** , **Locked State Visibility** , and **Guaranteed Lock Payment** , takes an initial stab at **Squatting Resistance** , and makes no attempt at being **Contention Aware**. Even further, **Locked State Visibility** lays the foundation for collaborative block building by allowing builders to append partial blocks to top-of-block arbitrages more confidently. The design deliberately avoids checks for conflicting transactions during SubmitPartialPayload to avoid blocking any other transactions also intending to touch the contentious locked state. BBlock builders are free to send in blocks with conflicts, but they are now aware of conflicts beforehand, which is an improvement over today’s market and creates an incentive to participate. Searchers are also incentivized to participate as it makes entry to stat arb easier and increases the likelihood of block inclusion. Relays take on extra work and, therefore, additional cost, but this approach normalizes the ability to take profit through a second price auction between relays in a roundabout incentive.
One area of concern is shifting towards a more relay-centric block building and [normalizing builderelays](https://collective.flashbots.net/t/builderelay/2688). My biased and cautious initial reaction is that we should be okay with this trend as long as it does not create opinions on which blocks are built or give an unequal advantage to one party over another. From this POV, relays will continue to house more auction-related logic as a trusted third party amongst a network of builders, each additional piece of logic ideally helping to promote more collaborative block building.
This approach requires no protocol changes and can be run in parallel with the current mev-boost auction. Additionally, it creates a “laned” approach without restricting it to a single arbitrage type, but is not fully generalized as it restricts top-of-block arbitrages to a single transaction. Exploring bundle support is thus an ideal future exploration, but if done naively, could create additional complications via a new avenue to submit entire blocks.
There are, however, a few complexities with taking this approach live. One is that it suffers from a cold start problem. If, at launch, only one searcher has developed the capabilities to compete in this auction, they will likely dominate for a short period and very cheaply, depending on the lock reserve cost price. The dual of this is that it only takes one searcher’s participation to snowball the rest. Another area for improvement is that this design only focused on the singular relay case, but in reality, there are many relays that all act independently. One thought is that maybe synchronization doesn’t matter since [bid cancellations are a similar cross-relay problem that is not guaranteed](https://ethresear.ch/t/bid-cancellations-considered-harmful/15500). In the multi-relay scenario, the best case is that each agrees on the state to be locked. In the worst case, each has a different state set and partial block builders construct for all potential paths. This creates more work, but at the very least, it is parallelizable and still a significant improvement over the status quo. Another area for future exploration is how this approach plays with optimistic relaying given its more complicated validation logic.
Lastly, the most significant unknowns here are the lock pricing mechanism and the state commitment’s effects on searcher strategies. The lock pricing mechanism is very undefined and most likely the place where things can go comically wrong; therefore, follow-up work should try to reason about this analytically and adversarially. Incorporation of historical state access into the pricing mechanism is also difficult because that is an extremely large vector to update if done naively and cannot be plugged into the block like the base fee relies on. Progress on figuring out this mechanism will also help to assess how big of a censorship vector this auction is and tease out the incentives more concretely. The effects of creating a new upfront cost to doing statistical arbitrage also should be thought through, but in the worst case, a searcher can effectively cancel their trade and simply pay the fee, not requiring them to commit to trading large amounts at a price they no longer find attractive based on signals on other domains.
### Add Ons
- Allow for searcher’s to continue bidding on the locked state after the initial auction period has closed.
- A randomized closing time could be used to discourage last-second bidding. But in the multiple indepedent relay case, this comes at the cost of creating different winners per relay.
- The state lock auction could employ a second-price rule to determine payment, encouraging truthful bidding. This could be achieved by inserting a refund transaction into the block for the difference, at the cost of 21k gas.
- [EIP-2930 transaction types](https://eips.ethereum.org/EIPS/eip-2930) could be used for the state access transaction, but they do support access to non-acces-list supplied storage slots so would not enable blind trust. In general moving in this direction will help streamline all future collaborative building efforts.
- The block construction in the relay provides an ideal time to plug in [unconditional inclusion lists](https://ethresear.ch/t/unconditional-inclusion-lists/18500).
- Leave bidding open to replace the state access transaction with your own as long as it touches the same state as the original. The incenvites around this are a bit unclear.
- Allow an auction per overlapping access list in parallel.
- One challenge here is that an access list which represents arbitraging two pools can be broken into two auctions to arbitrage each pool, and the cost of locking each pool individually may not be as high as someone trying to lock them both at the same time. The generalization thus requires some form of combinatorial auction that allows you to bid conditionally on winning another auction.
- [Tarun has cast’ed about how the Jito Solana MEV Auction works in a similar manner here](https://warpcast.com/pinged/0xa6d3fe25).
- Another challenge is that in the single auction case, the relay can be sure that a winning transaction will produce a certain access list. In the double auction case, we can no longer be certain of the 2nd transaction’s access list solely by looking at the first transaction’s access list. This is exemplified by a 2nd transaction, which is conditional on a balance modified in transaction 1. Although we should be able to detect _ **the possibility** _ of such a read-write conflict, it is most likely not stable enough ground to continuously stack these auctions on top of. A relay could simulate the 2nd transaction on top of the winner from the first auction, but this does not give us enough time in the block to run many auctions. Most likely, some constraints on the transaction’s ability to write and read state will need to be employed to fix this.
### Feasibility with ePBS
The challenge for integrating this approach with something like a future “ePBS” is that we would need to shift the auction to the attester layer, which naively requires an additional synchrony period. The network must come to an agreement on “what” the winning access list is, not to mention the p2p games that this incentivizes at the protocol layer.
One reason against moving this sort of thing into the protocol is that it doesn’t affect the resources on the network from a validator’s perspective, more or less locks wont affect the resource requirements needed to perform a validator’s duties. Additionally, lock auctions don’t represent a liveliness risk to the network. If the auction goes down, then we degrade back to the current state of block building. An argument supporting moving it into the protocol is that the auction generates revenue from the protocol’s state.
## Conclusion
This proposal sketches out a design for a relatively crude mechanism to auction a top-of-block state lock on Ethereum and enables collaboration in the block builder market. While not an end-game solution, it creates an ideal interface for experimentation with state locks and _ **unlocks** _ new aspects of the block building market, which may help us out of our current local maxima. Assuming an ideal lock pricing mechanism, this approach can go live into the wild quickly and move us one step towards a better builder market structure.
## Appendix
### A. Example Access List
Example Access List for
- [tx hash 0x84ba67793c7aa0140ae9f7cbc58a7bec04099672d467dfe280ec5987b5f26b46](https://etherscan.io/tx/0x84ba67793c7aa0140ae9f7cbc58a7bec04099672d467dfe280ec5987b5f26b46) swapping `Wrapped Ether` for `Porktoshi Nakamoto`.
Created via Created via these [python scripts](https://gist.github.com/dmarzzz/21827db7b9303088577dc1cca0dd23b4).
```auto
[
{
"address": "0xa65303cbe1186f58dda9cf96b29e1e89ae90b165",
"storageKeys": [
"0x0000000000000000000000000000000000000000000000000000000000000008"
]
},
{
"address": "0xb39bc86ac75118011f646276fca48d56e54c4854",
"storageKeys": [
"0x000000000000000000000000000000000000000000000000000000000000000d",
"0x7e3bb96fe9c3e8bf8baff39136a5e5778a1f21be90df3270983ce535ed884516",
"0x9db3014a7ecc5c8baca43505a03b4e7e24c2ec389a973d5605a299f04defc730"
]
},
{
"address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"storageKeys": [
"0x377eec8667584e30e85471441b46e69393e5f35d2b63a0b4c26a5b1f6d059aa5"
]
}
]
```
Here
- `0xC02aaA...3C756Cc2` is the WETH token contract
- `0xb39BC8...e54C4854` is the PORKTOSHI token contract
- `0xA65303...AE90B165` is the PORKTOSHI/WETH Uni V2 Pool
Based on the storage keys for the PORKTOSHI contract we can see there is some non-standard ERC20 behavior and the [source code verifies that](https://etherscan.io/token/0xb39bc86ac75118011f646276fca48d56e54c4854#code) but is besides the point.
### B. Rough Relay Spec Change
Validation rules and internal logic are explained in the previous sections.
#### 1. `relay_SubmitStateCommitment`
Allows participants to submit a state commitment for a particular slot.
- **Accepts:**
- **Returns:** Confirmation of submission.
#### 2. `relay_GetLockedState`
Fetches the access list associated with the winning bid for the specified slot.
- **Accepts:**
- **Returns:**
#### 3. `relay_SubmitPartialPayload`
Enables partial block builders to submit a set of transactions as a partial block proposal.
- **Accepts:**
- **Returns:** Confirmation of partial payload submission.
---
### Author:  [@Quintus](https://collective.flashbots.net/u/Quintus)
#### Post date: [February 5, 2024, 5:03pm UTC](https://collective.flashbots.net/t/state-lock-auctions-towards-collaborative-block-building/3019/2 "2024-02-05T17:03:06Z")
> [@dmarz](#):
>
> The effects of creating a new upfront cost to doing statistical arbitrage also should be thought through, but in the worst case, a searcher can effectively cancel their trade and simply pay the fee, not requiring them to commit to trading large amounts at a price they no longer find attractive based on signals on other domains.
Stat arb teams will bid lower on average since earlier auction termination implies more risk for them
I wonder if we couldn’t have similar optimisations with builder heuristics without introducing a new auction format. For example, what if we allowed searchers to mark that one bundle had the same ToB access patterns as another they sent previously. In the backend, if we receive high value ToB bundles, we build a block in which there aren’t any state overlaps so we can easily update if we want (or alternatively we allow for overlaps but then keep track of which tx we have to re-execute).
---
### Author:  [@dmarz](https://collective.flashbots.net/u/dmarz)
#### Post date: [February 6, 2024, 10:05pm UTC](https://collective.flashbots.net/t/state-lock-auctions-towards-collaborative-block-building/3019/3 "2024-02-06T22:05:38Z")
> [@Quintus](#):
>
> or example, what if we allowed searchers to mark that one bundle had the same ToB access patterns as another they sent previously.
Yes we can get this by forcing searcher’s (or encouraging) to use Access Lists in their bundles, it’s even possible today since EIP 2930 txns are live (although they do allow for the possibility of outside of Access List state access).
But the big disadvantage of your proposed way is that we don’t give the rest of the builder market visibility into the state that was locked.
---
### Author:  [@Markus\_0](https://collective.flashbots.net/u/Markus_0)
#### Post date: [February 7, 2024, 7:57am UTC](https://collective.flashbots.net/t/state-lock-auctions-towards-collaborative-block-building/3019/4 "2024-02-07T07:57:25Z")
This is cool!
**Few questions:**
1. Are the state lock bids distinct from the state execution bids? If not, how do you ensure truthful bidding in the first auction? Couldn’t the winner just nuke their bid as soon as they win? (gonna assume this answer is yes for the remainder of my comment)
2. You can lock state you don’t have permission to execute against right?
**and Few thoughts:**
**1.**
This makes bidding strategies really interesting as it effectively shortens block times and sells an option on execution part way through the slot. (put differently you kinda sell an execution ticket for the back half of the slot)
This has weird DeFi ramifications:
For AMM’s (and related apps):
My intuition is that @Quintus is right and bids on average get lower. This isn’t definitively the case though as the state auction will:
a. Capture Reversion Value
If I’m a stat arber selling on Binance and planning to buy on-chain I’m going to bid for the relevant state - if, after the state auction, the price converges with AMM spot, I won’t execute but I still paid for the state. This isn’t the case in current PBS.
b. Lower Hedging Costs
Theoretical stat arb hedging costs go down as the arbers average inventory delta drops since they don’t have to account for non-execution risk in the back half of the slot. This turns the stat arb into a true arb and allows them to trade more aggressively (this probably doesn’t cover the lost value from the added risk due to volume volatility but it might be close)
For Oracle’s:
Censoring Oracle updates is kinda weird here:
Imagine you have an oracle-based perp protocol. You can
a. Purchase the right to the state involving your position
b. Purchase the right to the state involving the Oracle update
You now have a synthetic derivative that pays out if the price moves more than the fee for opening and closing a position. The premium you pay is the cost of locking up the state. If I understand correctly this derivative would pay out for ALL pairs supported by the protocol.
This is different from incumbent Oracle frontrunning as it can’t be prevented by permissioned or private Oracle updates. You can ALWAYS lock the oracle state no matter what.
Furthermore, while interesting, these auctions are very complex and I think it’d drastically shrink the pool of searchers able to compete
**2.**
if multiple relays are involved I think this makes the vertical integration situation worse.
With state lock auctions stat arbers now want to integrate with a relay because they want the lowest latency in submitting a bid for relevant state (this is the same as the current searcher-builder integration incentive but with relays instead of builders). If the slot hadn’t already started when the auction is carried out you could argue that latency would be less important, but given that a stat arber already has 4 seconds of inventory to clear I think the incentives are literally the same. Randomized auction duration helps here but has downsides as noted.
Additionally, if different relays have different views of who won the state auction the stat arb searcher ALSO wants to be integrated with a collaborative block builder. They want to update their bid as late as possible to ensure that the collaborative block based on their relay’s state wins the auction and they get to execute the state they purchased. So now you have integrated searcher-builder-relays as the most advantageous competitor.
So in short, I think this is a super interesting mechanism, but I’m unsure that it’s an improvement unless we somehow get to a single-relay system