Whats beyond High-Performance L2s?

Good afternoon everyone. Today we're going to talk about a very exciting topic which goes past a very boring topic which is what's beyond high performance L2s. Everybody has been building L2s, everybody has very high performance, everybody has giga guests and I think it's really important to go really beyond that. And we have with us Mark from Optimism, Mark from Uniswap, and Robert from Flashwoods. My name is Georgios.

I'm from Paradigm in Ithaca. And I think the frame for this conversation is that with performance in the EVM feeling solved, and it's time to talk about more exciting things beyond cheap and fast, how do we go about it? We only have 20 minutes, so we're going to split this conversation to two topics. A, frontier features for L2s, and B, interoperability. How will things look like?

Is it going to be few L2s, many L2s? What does it imply about the market structure around them? And so I think we have Robert, likes fuel twos perhaps and mark and mark who like moral twos So maybe we can kick it off from there Robert is one big chain enough Well, so I didn't know I'd be put on the spot about my interop beliefs But now they've come out already. So we can start from there. So I think one question that I've had is sort of why don't you have network effects that lead to one big chain, especially when we're mostly not innovating on things like different virtual environments.

Every chain basically has all the same op codes. They work mostly the same way, in large part because you all have made a phenomenal open source stack for doing these things So if all these things are modulist anyway, then then why does an activity just end up on one big chain? Like maybe unichain in the future Why do we need multiple different environments to interoperate with and there are a few answers that you can come up with here? So so one of them is maybe you want isolated fee markets, but that doesn't even feel super strong because why can't we just isolate the fee markets on a single chain itself? So is the complexity that interoperability requires and the risks like cascading reorgs as an example, is that really worth it or should we really just put all this stuff on a single gigagas or pedagas, as Georgios' new meme, chain?

That's the starting point. I'm curious maybe to hear the interrupt bulk case. Yeah, I mean, I think we're still kind of in the stone ages with our mental models around chains. ages with our mental models around chains, we kind of, ultimately it is impossible to fit all of the world's usage on a single computer. We can just look at existing applications and how they work to see this.

So definitely do not believe that it's possible to build one blockchain to rule them all. We need to leverage the same techniques that Web2 uses to scale their applications to be able to grow to global usage. So I think we should stop thinking about chains and we should get to a place where the brand starts to like, all the chains have brands, and we need to start to kind of detach the brand from an individual chain. As these existing chains fill up, they're going to launch multiple chains. We see it with proof of play already.

And you could imagine maybe in the future there's a unichain one, a unichain 2, a Unichain 3, right? This is just horizontal scaling. We need to figure out how to build applications that can horizontally scale and move away from the idea of a single chain and thinking about a chain and instead just have like a network of compute that you can tap into that gives you nice blockchain properties. So I think interop is required to get to this future. For everything that needs to synchronously compose, why not just have that on a single instance of state?

And I think that's sort of the difference between Web2 when you have many different services with their own servers is because not everything needs to be able to synchronously interact with each other in the same way that at least applications within crypto today, financial applications, really want to be able to atomically compose. And in that case, why does Unichain need to have many different chains? Why shouldn't it just have one hub for liquidity and applications? Since the goal for Interop in the first place is to synchronously compose between chains, no? I think the problem of literally building one mega chain is just really, really difficult.

It's like what happens when you have one chain that outgrows the ability to run in a data center? Like Solana is starting to hit this with their historical data. A lot of the cloud tooling, they just don't support buckets large enough to fit all of their data. So if we go down the single chain route, it is a way harder problem. We need to really rethink all of the infrastructure to the data centers, to all the tooling to get it to work.

So I think that the kind of like the distributed model, it exists, right? We all have cell phones that compute locally. I think that if we just look out into the world, we can kind of see that, you know, the kind of distributed model works and we shouldn't, you know, go back and try to reinvent the wheel. We should build off of all this knowledge of years and years of engineering. I think one of the key benefits of horizontal scaling over vertical scaling for me is that it's much more abstracted and automatic, for lack of a better word.

Sure, you can vertically scale, but every time you want to upgrade to a larger size or whatever, you have to have this agreement and explicit upgrades of this new thing. Whereas if we just bite the bullet now and build a system that can scale horizontally and has automatic protocols for talking between chains and so on, you get a big burst of usage. We don't even have to talk about it. There's just new things auto scaling and popping up. And I think even in general, right, you were talking about Web 2 and not as much needing the atomic interop, but it is still important that you can pick and choose your specific server types for your use case and build auto scaling things that expand by creating new instances rather than expand by creating bigger instances, I guess, just because it generally is a easier thing to do when you're doing the same thing more times as opposed to switching to a different thing in my mind.

How should Interop work in a world with five chains? Because I can see the argument that Robert is making that all of DeFi should probably Live in like few domains or like one just because the synchronous requirement is so strong Maybe like let's say you're running Uniswap You probably wanted to be running in the same place as a lending market just so you can have efficient liquidations that go through that So how do you think about that versus what do brands want outside of DeFi? In the end, it has to do in some way around what are the apps and what are the apps beyond the DeFi sector. So maybe, Mark, you might have a view. Totally.

I think that there's lots of possible futures here. I think it comes down to the entrepreneurs that decide how to solve these problems. Because if we look out at today's world, there's like a bunch of different stock exchanges, right? And, you know, I'm definitely no expert in how all of these settle, but I really doubt that they use like a global order book between all of the stock exchanges. There's like some amount of time before they settle and it uses all these like crazy old legacy systems so i personally would not be surprised at all if there's like different kind of clusters of where there's defy activity and some amount of specialization in the infrastructure that basically follows whatever the local regulations are or is optimized for a particular type of user behavior.

I'm not convinced that interop needs to be atomic. I don't know, like it sounds nice for it to be atomic and maybe it makes things easier for developers and so on, but I think you know blockchains are sort of inherently asynchronous in terms of the way that their networks are evaluating things. And I think you can make things feel atomic to a user and have the properties of being atomic without actually being atomic. I've worked a lot on intense-based systems, and I feel like they're a prime example of this where you take an asynchronous thing and you turn it into what feels like an atomic thing but is actually under the hood asynchronous. How should market make...

So in the asynchronous composability world, have a Julian chains and somebody needs to? Relay the message from like one place or another usually that's a market maker. That's in the unit of case that's across for example that you're working with and I wonder how does that market making work in a world where you have five chains versus you have a gajillion chains? Are you expecting the market maker to go to the longtail chain and market make that that doesn't sound right? Could be the case where eventually the the job of relaying messages becomes sort of a specialized use case and the job of like finding prices and so on become separate like I feel like already is kind of getting to this state where market makers are Specialized in the trading and pricing part and not so much in the chain infrastructure and message relaying part.

And I don't see any reason we wouldn't be able to one way or another like specialize those roles. I think the sort of revealed preferences of market makers today are the really good ones are only on a small number of domain where there is outsized liquidity. So the top two market makers in crypto are only on the top two roll-ups right now, as far as I know, base and arbitrum. And so if you are relying on market makers to do interop between all these chains, I think you should expect that we end up closer to one to five roll-ups as opposed to 500, at least for financial use cases where you're outsourcing Jobs like trading to is that is that endgame market structure though because right now yes, they're doing that but plausibly They're doing that are they doing that because the time to rebalance across things is very slow or because nothing actually exciting for them It happens. How does the base type of interrupt the base layer interrupt that you get from a super chain style protocol help if at all with like the story for the market maker totally that's one of the main problems that we're trying to solve with native interoperability is solving for these liquidity problems and this is a trade-off when you go between ecosystem or within ecosystem it is very important to like have cohesive between ecosystem stories for how we do interoperability but the nature of the world is that within an ecosystem it's just going to be better interop so within like the super chain sort of ecosystem, we specifically designed it to remove these sorts of liquidity constraints by moving from like kind of like a lock and unlock sort of model to like a mint and burn sort of model.

And this was one of the the main design decisions that we said is a must and we think that it will really supercharge the network effect. So I'm a market maker, how quickly do I go from chain A to chain B? Instantly. Really? OK, so going from chain A to chain B, the protocol allows you to do same block if there's a block builder that's smart enough to line up the transactions between the two chains.

So like two seconds is what we've been saying. There is a little bit of a pre-confirmation trust assumption when you go that slow. But if you want it to be like trust minimized and you don't want to rely on that pre-confirmation, then you just have to wait for the remote chain to post their data, which, you know, chains with throughput do that every couple of minutes. Okay. So in in that world you're expecting that the market makers are going to be quickly doing things instantly across networks and plausibly on any super chain integrated network.

What happens is that the market maker is going to be using the slow super chain feature to rebalance their assets across them. Yes, 100%. The market makers, they should not rely on the pre-confirmation levels of security. They should wait until the data is all posted, and then they can arbitrarily move assets between chains without liquidity constraints. But Robert made a good point around something about cascading reorgs when there is some mistake happening.

So what happens then? That is 100% a thing. So under this sort of design, the finality of any chain is tied to the finality of another chain. So what are your risks? Your risks are you pull in L1 data into your L2, and that L1 gets re-arged out.

That causes the L2 to re-arg. That's already how the OP stack works today. Another risk is you basically accept a cross-chain message from a chain that has pre-confirmation levels of security and then they equivocate when they post the data, meaning that they post different data than their unsafe, the data that they pinky promised you. In the future, we want to develop an equivocation guard to prevent this. It's an active area of research.

Switching gears, Mark, we, Mark, Duda, you guys developed Unichain with Flashbots. Unichain has frontier features not available by default on the OP stack. How do you guys see that playing out and how does that interplay with Interop? What are other frontier features that we want and what are some that you're excited by? Robert, what are you excited by in these features, and how does that all play out in the Interop world where maybe they break compatibility with the Interop standard?

ROBERT KAPLAN- Yeah, I guess two questions. The first one is, how does it play with Interop? The second one is, what kinds of features am I excited about? about. I think how it plays with interop is a really interesting question because we want to be able to play with interop.

It's super important for our thesis for Unichain and I think in general for L2 scaling by rollups to work. And the other side of this coin is OP Labs has spent so much time developing rollups that, I don't know, we would be newbies. We'd have to go and relearn everything. We don't want to like build fraud proof systems from scratch So we want to be able to like lean on the work that you guys have done And so on and so really the way we thought about it was like how can we find? Areas that we can extend on where like it's actually going to make a difference But not require like going too deep into the you know And so the two things that popped out, kind of like what I was talking about in my talk earlier, were the block building as sort of a general section of innovation and the overarching way that blocks are posted and committed to and so on.

And those ended up being sort of where we started to build. I think if we're going to PETA gas or whatever, the biggest question that pops into my mind is, like, what do we do with it all? I think I've got to actually build use cases and so on. So the thing that makes me most excited, I think, about Frontier features is actually adding completely new primitives for developers to build on top of. So a lot of the stuff with the just execution environment, I'm really excited about this idea of a co-processor where you can request completely arbitrary off-chain computation from the TE.

Super cool. And you could just build stuff you wouldn't have thought possible on crypto a couple years ago, I think. We're super excited about the TE co-processing too. The sort of frame that we have on this is how do we enable the next generation of applications in crypto? That's how we talk about it at Flashbots.

And how do we make roll-ups and the L1 as great of an environment to do that as possible? So on enabling the next generation of applications, we really like using trusted execution environments to give users on-chain access to superpowers that they wouldn't have, like being able to synchronously read data from Web 2.0 on chain. We have a really cool demo called Teleport, I think it's Teleport.best, where you are able to have a smart contract control a Twitter account without trust except in the manufacturer of the TEE, which is super cool.

So you can load in your Twitter account, you can issue NFTs that anyone without trusting you can then use to tweet from your account. And that's an example of Web2, Web3 integration that's uniquely enabled by TE co-processing, and we think is gonna enable just a whole new class of stuff that people can do in crypto that you couldn't do before. We're also super excited about experimenting with different ways for applications to monetize and be sustainable. Priority fee ordering, I see Dan is walking around in the audience, is sort of the first one. And we want to experiment with different ways that applications can monetize the flow coming from their users in order to make it easier to get traction and build a sustainable business within crypto.

The final thing that I'm super excited about is taking a lot of these research-oriented ideas that we have had in the e-space and deploying them in the context of NL2. So maybe we can get multi-concurrent proposer running on a roll-up. We can get fossil or different ideas for censorship resistance. It makes a lot more sense to do that on a roll-up before we implement it on the Ethereum consensus layer. So taking those more fundamental research ideas, deploying them are some frontier stuff that we're really excited about.

Hell yeah. And as part of the RETH project, we've been doing a lot of work on customising nodes and to allow extra functionality on them So we're excited to continue doing that with you guys and mark How does super chain work in a world where everybody does crazy modifications to their systems that? Okay, so super chain you get the proof? If you do anything that breaks the proof, part of the definition of the super chain is that it's shared security. So doing things that like modify consensus, you're gonna break the proof.

In the short term, what this means is you need to do things at the policy layer if you want to like make these modifications, right? A lot of these modifications around like the sequencer, how it goes about building blocks. My claim is that we don't necessarily need to innovate a ton right now in random directions to get the next leg up in adoption. We really need to focus on product and having a cohesive user experience. If you look at focus on product and having a cohesive user experience.

And if you look at base, right, base is growing a ton and they don't have any crazy custom pre-compiles or anything like that. And they're seeing massive amounts of growth. They just have a cohesive end-to-end product that's really good. At some point, we will hit the wall, though, and we will want to start adding in new features. And I think the way to think about adding in new features is you really want it end-to-end integrated.

Because there's a lot of features that sound like a good idea in theory, but if the applications aren't building deeply into them, allowing for kind of like a zero to one sort of application, like something that's like net new that actually solves problems, the cost in adding new features is actually too high. Got it. So maybe a synthesis of this is that the work that these guys did on and their teams on flash blocks and and related features for segmenting the block They are out of the core protocol and that means that they don't actually require any breakage of the interrupt spec and plausibly for the forcoming future we're gonna see massive amounts of new chains that follow a similar pattern. Exactly. And then as there are protocol changes that get proven out that people want, like, for example, the P256 precompile, like, we support that in OP stack.

That was a consensus change. And we're big fans of following the roll-up improvement process. So if people do want to make consensus changes, then we always look to that repo to kind of filter out good ideas. Chuck? I think there's all sorts of purpose-built stuff that people want to do.

One thing that I was excited about for Unichain would have been implementing custom opcodes to make swapping really great, make them much more performant. And I learned that that broke some rules for the super chain, which is also one reason why I'm trending towards fewer chains rather than more. I don't literally mean one chain, but I do mean fewer rather than more, because I think interop in practice may end up being hard to play out, depending on how purpose-built people want their chains to be. If you add extra opcodes, then you're going to need to maintain a solidity compiler fork. I would say, like...

Maybe not. In general, if I'm adding a custom opcode that other people don't want, then I feel like it's not a useful enough opcode, probably. It seems like if we build a chain that has an arbitrary programming language, then I don't know. I guess I'm not completely sold on needing a swap opcode, if that's what you were getting at. Yeah, that's interesting.

You may just want it earlier than everyone else wants it. Yeah, that's fair. That might be the right limit. Yeah, we know what that feels like. Yeah.

I think we're almost at time one synthesis of this would be then that people do want customizations. Many of these are out of protocol. Some of them that are in protocol will be breaking interop in the short term. That's a good argument for maybe in the few chains world. At the same time, it's possible that these chains that want to do these opcodes, maybe they don't need the interop because they're doing so customized stuff out of the world where they don't need the synchronous interop.

I think that's probably going to be the most exciting thing happening in 2025 where everybody launches an L2 and you're gonna be looking, okay, are the people launching really customized L2s really seeking true interop or are they okay with something slower? And maybe the things where these happen, they're not finance related applications and they don't really need the synchronous interop. I think there's a super promising future for an application that launches like a really customized L2 that is end-to-end integrated into this specific application that they're trying to launch. Super, Yeah. If you're building AppChain L2s, these are the people that are on the frontier and you should talk more with them.