# State Contention Rules Everything Around Me by James Prestwich | Devcon SEA

- Speakers: James Prestwich
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 25:14
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-QrbJbjWKNX4
- YouTube: https://www.youtube.com/watch?v=QrbJbjWKNX4

## Description

State contention causes MEV, prevents parallelization, breaks gas simulation, causes transactions to revert, etc. etc. We'll discuss state contention in practical and theoretical systems (e.g. OS threads and type systems) and how/why synchronization primitives developed. We'll cover why state is contentious, what state is contentious, what can be accomplished by making state non-contentitious, and strategies for refactoring existing systems to reduce contention.

Speaker(s): James Prestwich
Skill level: Expert
Track: Core Protocol
Keywords: Layer 1, Architecture, Cross-L2, concurrency

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

Oh, I got a nice little cover screen. All right. Uh, hi everybody. I'm James. Uh, I'm going to be talking about state contention. State contention is you kind of understand it intuitively. Like your Uniswap trade can fail, but your token send can't. Right? So, it seems really simple on the surface. There's some things that fail and some things that don't. And sometimes it's not your fault, then if your token send fails, it is your fault. So, I'm James. Uh, I work at In it 4. In it 4 is a research collective building next-gen Ethereum tooling. Uh, you can follow me on Twitter, GitHub, whatever you like. Uh, and we're talking about state contention. So, this talk is not well laid out. I talk very fast. It's going to be a lot we can cover in Q&A at the end. All right. So, ooh. This is the state. This actually looked very different on my laptop, so I'm going to be a little confused by the trees throughout this talk. This is the state. Don't ask questions. Just roll with it. The state is a tree. The tree goes in the header. So, when you access the state, multiple people are accessing the state at the same time. Ethereum can't do concurrent access, so we have to linearize. We have to put people in order. Uh, with state contention, reordering people changes outcomes. So, if it's this order, we get this tree. If it's that order, we get a completely different tree. This is contentious state. Changing the order changes the outcome. So, look, like we have about 50 years of managing contentious access to state in computer processes and things. And the main thing to know about it is that the OS and the CPU mediate concurrent access. So, typically, when you're writing programs, you have this thing called Linux and it runs on this thing called a processor and they handle what happens when multiple people or threads or processes or whatever want to access the same resources. Uh the only problem with this is that the Ethereum OS hates you and has a knife, right? Like it wants your money. The Ethereum OS is designed to deprive you as much of as much money as possible. Okay. Uh we call this MEV, which I forget what it stands for, but you know, whatever. Uh so I want to talk for a second about the mail. You want to talk about the mail, Mac? Let's talk about the mail. I've been dying to talk about the mail all day. Right? When I send a transaction on Ethereum, I want something from it, right? Like I want to send tokens. I want to transact on Uniswap. I want uh some NFT PFP for some reason. I don't know. Like I want something. That's why I'm sending the transaction. So I stamp up my letter, I address it, I send it off into the network. Uh this looks completely different. So some slides are going to be broken. Don't worry about it. It's fine. Uh so I define my scoring function. I have something that says how much I like the state that is the outcome of my transaction. When I'm sending tokens, I want those tokens to move. So if they move, I'm happy. If they don't, I'm sad. So uh in this case, I really like this nice evergreen tree. So it's 10 of 10, perfect, no notes. I may or may not like palm trees or deciduous trees, but I love evergreens. Right? So builders, they make blocks. There are two builders that make all the blocks. Uh if you don't know their names, you should learn them because they control everything around me. So builders decide what order state access goes in. This is how Ethereum as a OS, CPU, whatever, virtual machine mediates concurrent access to resources. It linearizes them, and the builders are the ones responsible for doing that. So, the builders decide the order, right? And the order decides the outcome. It's perfectly deterministic. So, you can kind of shortcut this and say builders decide outcomes. Uh this is an important asterisk. We'll come back to it later. The builder chooses which transactions go in the block, what order they occur in, and therefore the builder selects outcomes from a set of possibilities. So, that means because my scoring function is deterministic on the outcome, which is deterministic on the order, which is totally controlled by the builder, that the builder decides whether I'm happy or not at the end of a block. It decides whether my tokens move. There are two block builders that decide whether we are happy at the end of every block. Right. So, that's the mail, you know. Builders mediate concurrent access to resources to decide outcomes for users. Uh and here's where we get back to the asterisks, right? Uh they can decide outcomes if they can affect the state. And if they can simulate that state accurately. So, this is two different very important caveats on the ability of a builder to select state from the outcome of possible states at the end of the block. So, one, there are some states that a builder cannot affect. They can easily affect Uniswap because anyone can trade on Uniswap, but they can't easily affect my token send. They can't send my tokens for me. They can't take those tokens away from me. They can't take ether out of my account. All they can do is decide not to include my transaction. So, in some sense, my transaction is what we call order-invariant. I don't care where in the order it goes as long as it gets in. So, we talk about scoring functions. There are many classes of scoring function. There are many choices of scoring function. Typically, it's connected to what application you're running, what you're trying to do. Some of these are order-independent. Uh order-independent scoring is when I need my transaction in the block, but I don't care where in the block. So, in this case, I don't care if my transaction is first or third. I'm happy either way. My scoring function is order-independent. Uh yeah. So, examples of this, like I need to send Yaz one ETH. Like, I don't care if it's top of block, bottom block. I just got to send Yaz ETH. Uh if I need to re-collateralize a loan, I don't care if that's top of block, bottom of block, as long as it happens before I'm liquidated. And if I'm re-collateralizing a loan in the same block I'm liquidated, that's just my fault. That's on me. Uh and if I'm transferring my NFT PFP that I bought earlier, like 10 slides ago, uh I don't care where that transfer goes in the block. They can't deprive me of that NFT, which means I can transfer it regardless of what the builder does as long as my transaction gets in. So, if the state's not contentious, like the outcome may not change for me. Uh with all of these order-invariant transactions, scoring functions, goals, intents, if you want. This isn't to talk about intents. Uh when the builder rearranges things, you still end up happy. But with things like Uniswap trades, you may not. You usually don't, in fact. Uh so, there's a distinction between these two classes of transaction. One where the builder can exercise a large degree of freedom over the outcome and one where they can exercise a much smaller degree of freedom over the outcome. Uh, another like important example here is that if the builder doesn't include my token send, that transaction is still valid and it can go in the next block. If the builder changes the outcome of my Uniswap trade, that transaction is no longer valid, can't go in the next block, and I have to re-attempt the trade again, and I have to pay the gas fee again. So, this comes back to simulation. When I send that Uniswap transaction, I have to look at Ethereum state and I have to simulate the outcome of my Uniswap transaction so that I can appropriately gas transaction, so I can sign it, submit it to the network, whatever, so I know what I'm getting from the Uniswap transaction. Uh, the builder also needs to be able to simulate my transaction. A builder won't include a transaction in the block that it can't simulate. And you might be thinking like, James, you just said like a minute ago that the outcome is a deterministic result of the order, right? So, how could the builder not be able to just simulate that deterministic function? And the answer is that we're actually in a pretty complex world now and there are sometimes when the builder doesn't know things in advance. Uh, so if the builder can't determine the outcome, they don't get to decide the outcome. Which, I mean, should be pretty obvious. I don't get to decide something I don't know. So, simulation relies on perfect knowledge. They need to know all inputs to the state transition function when they simulate the block. Uh, simulation allows the builder to censor me or to interfere, but it's actually good, uh, too. It's necessary. We can't really function very well without it. Uh, I need to be able to gas my transaction, which means I need to simulate it to know what it'll cost. And when I'm transacting on Ethereum, what I'm doing is functionally paying the builder to get the outcome I want. My gas fee goes to the block builder, and the builder gives me the thing I wanted out of it. Uh, that's, you know, the the good version of the relationship. That's what most users go through all the time. So, in order to get what you want, you pay the builder. And if the builder can't simulate the transactions, they don't know if they're giving you what you want or not. And so, you might just get wrecked through nobody's fault at all. Simulation is critical for interacting with the chain. Uh, we don't want to get rid of it. So, in what cases does a builder not have perfect knowledge of the future? You'd think like the builder is creating the Ethereum block, they must know the current Ethereum state, they must know what's in the block, they should be able to produce the next state, too, right? Uh, so, sometimes we reference new and unpredictable information. Uh, this is a, these slides look very different. They look great because Tom made them. Uh, this is from a blog post that we wrote recently about reorgs in rollups. Uh, not something people talk about very often. Uh, so, Tom made these slides. This is Tom. He's great. We love Tom. Uh, Tom like is an example of unpredictable input. You didn't really expect me to be putting Tom up over a like slide about reorgs. And rollups are the key example of unpredictable information controlling state while a builder is simulating a block. So, this is, uh, you know, what optimism looks like. The H blocks are host blocks, the R blocks are roll up blocks. And roll up blocks reference some older state. Uh some older host blocks, some older Ethereum block. Uh This is because optimism and every other modern roll up does what we call run ahead sequencing. The sequencer is progressing the roll up faster than Ethereum progresses. So that means that they can't reference new Ethereum state. Because if Ethereum reorgs, you go from uh you know, some old Ethereum header to some new Ethereum header. Uh the roll up, if it referenced the reorg state, is now invalid. So the roll up needs to reference only state it believes will not be reorged. Uh optimism waits 3 to 4 minutes, uh which seems fine. Arbitrum waits for justification, which if you watched the last talk, you'll probably have a pretty good idea of what justification is. Uh that's closer to, you know, tens of minutes. And they do this to ensure that the roll up sequencer has perfect knowledge. That the state of Ethereum referenced by the roll up will not change. So this delayed reference to Ethereum delays all entrance to the roll up. The roll up can't reference modern Ethereum blocks because that would mean the information is not perfect. So it references old Ethereum blocks. Right, I just said this part. This is when I get my slides out of order because I'm not a very good builder. Uh so optimism and Arbitrum's pre-confirmation system that the sequencer runs that gives you a trusted stamp on every transaction requires simulation. And it therefore uh it lags host references in order to preserve simulation. Their entire fast confirmation system, which is a trusted stamp from a central authority, relies on simulation and relies on time lagging. So, they can never reference current Ethereum state, only some view of the past. And that's the trade-off. I'm getting myself all out of order this talk. So, with a based roll-up, uh it's slightly different. Based roll-ups can reference uh current Ethereum state. But, the based roll-up builder doesn't know what Ethereum state will be in the next block. If the roll-up and the host are producing block 10, uh the based roll-up builder doesn't know what the state of Ethereum will be after block 10 while constructing roll-up block 10. So, these links are much tighter, but there's still a one-block delay in based roll-ups because you can't reference the current Ethereum state because you don't know what it is. Right? So, this is where we come back to if builders can simulate things accurately. When something like a roll-up references the host chain, it references information that the builder doesn't know. So, if the roll-up state transition function references anything in the host state, the builder doesn't know what that state is and doesn't know how to simulate the roll-up block. So, that's why we uh time lag optimism and Arbitrum sequencing so that they can reference past Ethereum state instead of uh current Ethereum state. And so, now I stole a bunch of slides from earlier in the presentation, and I'm going to pull it back and tie everything together. Uh the builder chooses outcomes, and it chooses whether I like those outcomes or not. Okay. Uh some outcomes are order-invariant where it doesn't matter where in the block they go as long as they're included. Uh nothing can interfere with those transactions and change the outcome via contention because they are fundamentally non-contentious uh or the contention is permissioned like in the state of in the case of a token send. Okay. So, when the builder includes an order-invariant action, they know the outcome even if they can't perfectly simulate the state. So, you can have a portion of the state that is simulatable even when the remainder of the state is not. So, in the case of a based roll-up, when it references Ethereum state, if it references only the outcomes of order-invariant actions, you can have a zero-block time lag on communication between Ethereum and the roll-up. Uh this is the only case in which you can do that. Uh and so, we're going to go through the the takeaways real quick. All right, this is again what I said. I'm getting ahead of myself every time. So, when the roll-up block is submitted atomically with order-invariant actions, the roll-up state transition can read those. So, when the roll-up block going to Ethereum is alongside token sends, then the roll-up can know that those token sends occurred and to whom the tokens were sent and that those tokens definitely confirmed. Uh because the alternative, if the token sends reverted, then the roll-up also reverted. Right? So, the roll-up knows that either those token sends occurred or that roll-up block didn't, you know, didn't occur either. They're atomically linked and therefore the roll-up can reference those token sends in its state in the same block that they occurred on Ethereum. Uh and maintain simulability. It allows the builder to construct cross-chain transactions within a single block. So, you know, we learned a little bit about how fast I talk and that we have a bit too much coffee around the venue. It's free. It's not very good, but I like it. Uh we learned simulation allows censorship, right? If the builder can simulate your transaction, you access contentious state, they can censor you. Uh we wrote a whole blog post about this. We showed that the Optimism sequencer can always censor Aave withdrawals or any lending market withdrawals. Uh regardless of whether you use forced inclusion or not because they can use state contention to prevent the market from having liquidity when your withdraw is processed by the roll-up. They can do that when they're sequencing, they can do that with forced sequencing. It doesn't matter. So, on modern sequencer roll-ups, you have no guarantee that you can ever leave an Aave market if you piss off the sequencer. Okay. Uh simulation is necessary for precoms. It's necessary for gas estimation. It's necessary for using the chain. We need to know how much things will cost and what they'll do in advance. Precoms, like Optimism, Arbitrum, everyone does, require delaying communication between Ethereum and the roll-up by a significant amount, minutes to tens of minutes depending on your security parameter. Simulation is absolutely necessary for the only way we know of to do same block host to roll up communication. Uh pre-confs are inherently incompatible with same block communication because they require uh delaying the state reference. You can never have both a totally reliable pre-conf and same block communication. So, we're kind of walking a mechanism tightrope where we're we have two sequencer designs that are out deployed, run ahead and base. There's likely other better designs that give us things like same block cross-chain communication. Uh but we just haven't found the right path through the middle. Uh so, you know, this is the kind of stuff I work on all day. Thanks for listening to my talk. Okay, cool. I'm going to shuttle you along to the middle and then um Okay, I guess we had one question which was a exclamation that said, "Super cool talk." Which is amazing. Thank you. so much. Um I guess we're shuttling you off. So, give another round of applause. Oh wait, no. Okay, no, there are questions. People forgot to submit them. Come back. Come back. Okay. Super cool talk. Thanks for your talk. Um doesn't angry sequencer need liquidity to block Ave withdrawal? How angry can I get? Uh the angry sequencer does need temporary access to funds to block the Ave withdrawal. But because they control the duration of their own borrow, they can make that duration effectively zero because they control the timestamps and therefore they control what the Ave market charges them in interest. So, they do need liquidity in order to borrow and drain the liquidity of the market you're in. That doesn't seem to be a like big challenge. Sequencers tend to be controlled by entities that happen to have a lot of cash lying around in the form of some sort of token. Or just a lot of cash lying around. Okay. What alternative designs do you think could be cool aside from base and run ahead? I recently talked about this on the Gwar show. I think that we might be overcomplicating things a bit with sequencing. Like the optimism Arbitrum run ahead sequencer model is complicated. Like you saw how much more complex that graph was than the base roll up graph, right? Like you have to manage state references. You should go read the docs on this because it's a real pain. And then base sequencing is basically just making your roll up a part of the modern MEV pipeline. And if there's one thing we kind of really hate just terribly, it's the modern MEV pipeline. Like the PBS auction is one of the worst, most toxic things going on in Ethereum. It's why there's only two builders and they decide what happens to your transactions. Like it's not good. So, rather than trying to just design a mechanism from scratch, I think there's room to just like simplify. Why not just have round robin sequencing? Like get five people together, give them make them take turns. Don't have an auction. You're already more decentralized than Ethereum. If you get five of your closest friends, you are more decentralized than Ethereum block production. And that's a problem. Okay. Did you expect that we will end up with just two builders? The first time I wrote about MEV was in 2017. I think we published it early 2018. Uh and that's called that blog post was called miners are not your friends. Back then we modeled this as miners interfering with transactions by reordering, inserting, dropping, censoring, whatever. Uh and the metaphor we used was a treadmill. The miners are constantly racing each other on treadmills and the treadmill speed up to the point of the fastest runner. So you are constantly racing everybody else and if you fall behind for more than a few minutes, you get kicked off the network. Uh you stop being able to mine effectively and you stop winning blocks and that means you stop being able to pay your bills and you go out of business. Anything that's hyper-competitive like this will be a race to the bottom and will cause market aggregation. The PBS auction from the very beginning obviously caused market aggregation. We knew this when we built it. I guess this may be a follow-up question. Wouldn't the five friends also delegate to the two builders eventually? How much do you like your friends? It sounds like you don't like your friends very much. Like uh with something like this we have tried an unmanaged market. It doesn't work. Trying a managed market where someone decides who's allowed to build blocks is a reasonable stopgap until someone proposes a mechanism that is better than the PBS auction. Uh decentralization is a means, not an end. You're not supposed to be decentralizing random computer stuff. You're supposed to be decentralizing power and control. We have constructed a market that is very free and decentralized but leads to aggregation of power and control. Uh if we instead construct something that is centralized but leads to distribution of power and control, that is better. Okay. Well, I got the sign that Q&A is up. Thank you so much for joining us today. Um we have