Unichain: an L2 Designed for DeFi

Hello, hello. Good morning. Yeah, so I'm Mark. I lead the protocols and research team at Uniswap Labs, and I'm here today to give you guys kind of the high-level overview about Unichain, some of our, like, motivating reasons behind the development process of it, and hopefully give you guys kind of a sense of what I think it is going to feel like to be building sort of the next generation of DeFi apps in this, like like scaled Ethereum world. Let's see if my slides are on here at all.

Not that one. Definitely not that one. There we go. Okay, okay. Here we are.

So yeah, the talk is titled, we need to go deeper, because in this like next phase of the Ethereum scaling world, suddenly, you know, decentralized applications have the chance to iterate and innovate at sort of a full stack level by, you know, creating L2 rollups that optimize for their use cases. So yeah, again, going to kind of try to just like give you guys the general way that we approach the design of Unichain and how we thought about the types of things that we could do if we're launching applications on our own rollup. Give a little bit of a high level description of the things that we're actually building, and finally give some tangible examples of what it feels like to build applications on top of Unichain and in general on top of sort of optimized L2s. Okay, cool. So the first thing we were kind of realizing as we decided to build Unichain is that the L2 scaling world is kind of here.

There's like a ton of roll-ups now all of a sudden and like a lot of places to use, you know, decentralized finance and cryptocurrency in general. It's very cheap, it's very fast and so on. But how do we make sure that DeFi actually scales with it? You know, I work at Uniswap Labs, we do a lot of trading and want to make sure that the trading experience is actually as optimized as the costs and the chains themselves. So what does it mean for DeFi to scale?

Just a couple of examples in general. One bad outcome that I'm personally afraid of, as there's many, many roll-ups, is this problem of fragmented liquidity. So this is where every chain has its own little subset of liquidity. Some assets are tradable here, some assets are tradable here, but it's not easy to get from chain to chain. And so if you're a user that wants to access some liquidity either for buying or selling assets or so on, you have to go and aggregate across all of these chains or bridge and bridge and bridge and swap, and it just creates this horrible fragmented situation.

It's bad from both the user experience level and a market efficiency level because now there's several different markets that all have to be efficiently arbitrage and so on. Second category of problems that I'm concerned about is this suboptimal chains problem where if every rollup has to be general, then none of them are specifically good for a particular use case. Some potential problems in the context of DeFi and trading are the leakage of MEV. This is obviously a huge problem with AMMs in general. If a chain is not really thinking about this as it's being designed, it could have potential problems where MEV can be extracted or leaked.

In efficient markets, if maybe a chain doesn't have optimized ways for trading or so on, it could have slightly less accurate pricing or more slippage than another chain that was maybe thinking about it more. And finally, if there's hundreds or thousands of chains, maybe the big AMMs can't go to every single one. It just becomes like a general engineering effort problem of getting access to a good AMM on every single chain. So anyways, this is a potential problem where you might be, you know, on a chain and not actually have access to any liquidity there or any good liquidity. So, okay.

This is like the general motivating reasons behind Unichain from our perspective is like, let's try to build a primary home for DeFi liquidity that is highly optimized for DeFi needs and specifically like trading needs to build an AMM ecosystem that is easily accessed and highly efficient. Okay, so yeah, again, so like why build our own roll-up? Suddenly we have this like much broader design space where we can customize and optimize and scale our system to be, you know, specifically usable for our particular use cases, right? Okay, so just digging in one level deeper, if we're trying to build a DeFi-optimized chain, it's a very abstract idea. What does it actually mean?

What are the things that would make a chain DeFi-optimized? Well, one thing, generally good for user experience, but having a really fast chain is also really good for having efficient markets, right? You can think, as the chain is updating more and more frequently, you can have much more, you know, accurate rebalancing of prices to, you know, the market as a whole. So this, you know, there's been research that shows that this, you know, results in better LP returns and also just a generally much more nice UX for users, right? Secondly, effective MEV handling.

Again, mentioned this earlier. AMMs, you know, generate a lot of extractable value. And so if we can somehow make the chain optimized for internalizing this MEV, giving it back to the users, or just generally keeping it within the ecosystem itself, that would be a DeFi optimized chain in my mind. Thirdly, a highly connected chain. So, you know, I was talking about this fragmentation of liquidity and access to liquidity and so on.

I think that if we're going to make a chain that is optimized for DeFi, it should be easily accessed from other locations so that you can actually use it from wherever you are in the scaled Ethereum ecosystem. And finally, it should be consistent. So this means if I try to do an action on this chain, I should be able to convince myself that it actually happened and won't get reverted and so on. So this is things like fast finality, timely transaction inclusion, and so on. It's just a really nice feature to have for a chain that might be dealing with, like, financial applications, right?

Okay, so as we're going and trying to build these things, what are some constraints that we want to make sure are true about this chain? This is kind of like engineering brain, you know, what are our big goals and then what are the constraints that we want to make sure are true? One of them is, you know, we're building on the OP stack and we want to be a part of the super chain, which is this very nice native interoperability cluster of chains where you can have fast messaging between them. We want to make sure that we're compatible, so we want to make sure that it's actually easy to send messages to and from Unichain within this broader ecosystem and build on top of the extensive work done by the OP team to create this native environment. Secondly, we want to have iterative development.

We have a lot of ideas now for the types of things that we want to build on Unichain and the way that it should work. But the ecosystem changes fast and we might have new ideas later down the road. So we wanted to make sure that the work that we're doing today will be like continuing to be useful as we go in the future and have new ideas. And similarly, like, you know, future proofing to future upgrades to Ethereum, future products that we might want to build and so on. So just to summarize the goals and the constraints and so on, we basically wanted Unichain to be a set of platforms that can be extended in an iterative and future-proof and super chain-compatible way.

So this idea of building platforms that allow for this easy iteration and easy extension is a really nice framing for a lot of the work that we did on Unichain. And so going back to these goals that we had, we can try to separate them into the different types of platforms that are needed. So one of them is very fast blocks, effective MEV handling. These are all in the way that the blocks are actually created, the way that transactions are ordered, and so on. And so it seemed very clear to us, in partnership with the Flashbots team as well, to create a platform that allows for extending and enhancing the block-building process.

And the second set of goals here was around the fast finality, the inclusion of transactions into blocks, and inclusion of blocks into the canonical chain, and so on. This is a little bit more of like a meta chain enhancements, you know, consistency thing. So our second platform that we ended up going with was a platform for general chain and sequencer enhancements called the Unichain validation network. So I'll go a little bit more into detail on what exactly these are, but this is kind of my mental model on like the scale of things from a, from an L2 perspective, there's these pre-block and intra-block operations around block building, transaction ordering, and so on, which is all going to be built on top of this Rollup Boost platform in collaboration with Flashbots. And finally, any post-block, multi-block, more meta enhancements are going to be a part of the Unichain validation network in my mental model right now.

So a little bit more on RolloutBoost. You guys may have seen some of the announcements and so on, so I won't go too much into detail, but just to, again, give the motivating reasons behind these things. RolloutBoost is, in my mind, a platform for supercharging block building. So it's flexible, provable block building via trusted execution environments, a little architecture diagram of sort of the way that in general the sequencer and RolloBoost interact to create blocks that have been sort of customized via this Trusted Execution Environment system. Okay, so yeah, this is sort of extending the MEV dynamics of chains and again kind of going back to some of the bad outcomes I was afraid of before.

The block building strategy itself, I think this is a really important thing to understand. The way that blocks are built is actually directly correlated with the way that MEV behaves on a given chain, right? You have Mainnet which has this full block auction that they run with block builders. We have other chains that do first come first serve or priority ordering and so on. And each of these create like a different optimization strategy for MEV searchers to actually extract the value.

And so I think it's really important, especially if you're building a DeFi chain that has a lot of MEV, to think hard about the way that blocks are built and so on. So this seemed very clear to me. For example, you know, efficient DeFi markets in my mind are like, if there's a liquidation opportunity on a lending protocol, it should happen as soon as possible so there's not any extra leakage on the protocol. Similarly, if there's an AMM mispricing based on the overall market, it should be rebalanced as frequently and as soon as possible so that the LPs get the minimum loss versus rebalancing and so on. Similarly, there's this other category of MEV, which I'm calling here transaction-specific MEV, but it's like if you're doing an action and that action itself is creating some extractable value, I think this type should be, as much as possible, returned back to the user, right?

This is like, my action is causing some value to be extracted. No one should get that except for me. So thinking about the way that we can do this kind of MEV internalization I think is very important. And finally, like minimizing the centralizing force where like as much as possible, anyone that sees an opportunity can act on it as soon as possible. I think this creates the most competitive environment and open environment for these types of things, right?

Okay, cool. So yeah, again, Rollup Boost in general is like provable block building. So we can give different rules to the way the blocks are built, the way that transactions are ordered, the way that they're included, and so on, and prove them via this trusted execution environment. So it's an extensible system where we can add all kinds of different features. The first two features that we're targeting are one called flash blocks, which is basically 250 millisecond effective block time using kind of a pre-confirmation or like a pre-commitment to a specific ordering of transactions.

It's perceived as near instant in the psychology of human beings, basically anything less than like 200, 300 milliseconds. And this again allows for like very fast arbitrage, fast rebalancing of prices on the AMMs and so on. And secondly is a revert protection. So basically like users never have to pay for failed transactions, which makes on-chain auctions much more efficient and any kind of strategy of attempting to perform actions that may or may not succeed. So a little bit more detail.

Verifiable priority ordering, I think, is very important here. It's basically like the transaction should be ordered by the amount of gas that they're willing to pay. This is a very common standard approach to ordering transactions, but I think it's important for a lot of the use cases that we're thinking about. I'll get more into detail around that later on in the talk. But effectively, just to give an idea of the way that the trust execution environment works, it has rules to receive a certain set of transactions, order them by priority ordering, and then commit and prove to the fact that that's what it just did.

My screen just died, but I think I have this down. Okay, so secondly, flash blocks, right? So this is basically, again, a pre-commitment to ordering of transactions within the overall block, right? So you can imagine if the block time is one second or something like that, we can create the feeling of a much faster block time by committing to an initial chunk of transactions within that block. So, that's kind of what we're describing here.

And again, this is an extensible platform. So, we have some ideas for things that, like directions that this can go in the future without having the sort of exact roadmap down. I can just give you some of the general ideas to get your mind turning hopefully. So one here is encrypted mempool. So a Trusted Execution Environment, it runs in like a private environment with encrypted data that it's accessing and so on.

So you could as a user, encrypt your transaction request to the Trusted Execution Environment's key, send it in such a way that it literally can't be accessed by anyone except for the T until it's confirmed in the block, right? Secondly, it's kind of this fun idea of scheduled transactions, which we've talked about a lot in Ethereum over time, but I've never really found a good way to do. Basically, if you want to execute an action every day or in a month or something like that. How can we like register this as a scheduled transaction and have it be executed? Well, you could just add a new rule to the T that says, okay, watch out for these scheduled transactions and like execute it when it comes.

Or even easier, just have a heartbeat that like, you know, pings a contract every block and like executes any things that need to be executed, right? And finally is this idea of a coprocessor, which is where a smart contract on-chain could request computation from the T, which is actually a really powerful thing because you can run much broader strategies, maybe accessing off-chain data and so on, that get executed on-chain in a trustless way. Okay, so that was kind of a general idea of Rollup Boost. I'll kind of do a similar thing here for the Unichain Validation Network. Again, it's a platform for validating and constraining kind of the overall chain behavior.

And the idea is, you know, probably something y'all are relatively familiar with, where there's sort of a set of nodes that are running some kind of like instrumented version of the Unichain software that runs like extra checks or extra services and so on. And they are incentivized to do so in the standard way of the chain. Our hope is that this can do a few things. It can provide checks and balances on top of the sequencer, maybe add extra meta behavior of the chain as well. Checks and balances, limiting the user trust of the sequencer, decentralizing Unichain in this progressive way with a set of validators.

And yeah, the very first thing that we're targeting here is what we're calling fast finality, but it's basically a way that you can gain confidence that a block is not gonna be reverted before it's gone through the entire fault-proof window process and so on. And I think this, kind of from a mental model perspective, is very important for any kind of cross-chain settlement where you need to be confident that something actually happened on Unichain and won't happen in a different way than you saw. So kind of general mental model for how that works. Oh, sorry. This is the architecture of the Unichain validator system in general.

So we have the UNI token on mainnet which can be staked into a staking contract Which then gets sort of transmitted onto UNI chain where you can have Sort of a state of all of the currently active validators that can run services on UNI chain And and potentially receive rewards and so on there Okay, so fast finality general mental model for how we're thinking of it working is like a commitment to a particular like ordering of the canonical chain As blocks are created and so on we're thinking of it working is a commitment to a particular ordering of the canonical chain. As blocks are created and so on, the validators can be running a node and committing to a particular set of block hashes in a particular order and so on before they've gone through this entire process. We can talk about that more later, but some future work, again, this is a platform for extending the chain, so we have a bunch of ideas for other directions that it can go, but one is kind of like adding extra inclusion guarantees using an inclusion list or similar mechanism. Secondly, we could limit the actual batch posting of blocks on Unichain to require some overall weight from the validators and so on. And finally is this idea of cross-chain settlement services.

How can we make it so that users can interact with intense-based systems in a much more efficient way or receive messages from other chains in a quicker way as well. Okay, so I've got a few minutes left here. I want to give you guys kind of like a tangible example of what it feels like to build DeFi on Unichain from the perspective of one of our products. So we have this product called UniswapX, which you may have used before or heard about. And we're currently extending it to have different types of auctions that run differently on different chains to optimize for access to liquidity and so on.

So one of the ones that we're very excited about is called Priority Ordered UniswapX, which is based on this Priority is All You Need paper from Dan Robinson, which I think he's actually going to talk about today later. But the idea is basically an order specifies like a baseline price and a target block. So basically a block that is going to be ordered by the priority fee is a key requirement here. And finally, it specifies a price increase per priority fee. And kind of the mental model here is that every extra way of priority fee that a filler adds is, like, in theory, an extra amount of, like, value that they can get from this order, basically.

Kind of like the extractable MEV of this order, right? And the key thing about our priority order Uniswap X order is that for every extra amount of priority, the filler has to actually give more output tokens to the user. So this is kind of like a very simple version of a MEV internalization protocol, right? Where the MEV that's being extracted is actually forced to be sent back to the user. So yeah, this is just an example of that.

If there's three fill attempts where one has a 3G way priority fee, one has a 2G way, one has a 1G way, if the block is ordered by priority, the 3G way one will go in, but that also means that the filler has to give more output to the user, giving them sort of a better price in the end. So okay, a couple of problems with this in general, even if a transaction to enter this auction, right? And so the losing bids end up having to pay gas for reverse. You can imagine if this is happening on some other priority order chain, this first filler will win, and they'll get to fill the order, but these other two have to pay a little bit of gas for their failure. And just, you know, this extra leakage makes it, like, much more complicated to interact with the system as a filler because you have to consider the risk of failures and so on.

So okay, we have Unichain, we have the rollup boost, we can just add some rip protection. More complicated than it sounds, but we have the ability to add these types of features, which now much, it simplifies the experience of being a filler on this system, makes it much more efficient and so on. Similarly, a key requirement of this is that if you're trying to fill an order, that order is specifying a particular priority auction that you must get into, because that's where the order is being priced, right? It's not super easy on all chains to get into a particular block, right? So if you submit a little too early, you might get in the previous block.

A little too late, you might get in the next block, right? And that'll be a failure in this case as well. Well, you know, we have this block builder that we can add extensions to. So we worked with the Flashbots team to add a new bundle type, which lets you specify a particular block and a particular Flashblock PGA within that block that you want your transaction to be included, the T can hold on to your transaction until that particular PGA and include it. So now it just much more simply puts everyone that wants to be in this particular auction into that auction.