The Future of Interoperability

Okay, cool. Thank you. Cool. So, thank you for coming today. We're going to be talking about the future of interoperability.

So, thank you, thank you. Okay, so the first question, what is the super chain? Very important question. It's a deep question, but it's also simple. The super chain, it's optimism governed block space.

Very simple. It is also a horizontally scalable cluster of chains with shared security. It is also a mechanism to turn zero-sum games into positive-sum games. Very important. It's also infrastructure for the institutions of the future.

It's time to stop using fax machines. It's time to upgrade. Also, it's the substrate to align AI. If we're going to have super intelligence, it needs to be financially aligned with us. So let's give a little bit of context about scaling Ethereum, right?

So it's impossible to scale to global demand with a single computer. Solana can try all they want. Definitely don't think it's possible with just one single computer. So there's a lot of technical challenges of building this single computer, and you can see that today we already have personal computers. So when you're all trying to build the same thing, there is this problem around coordinating the roadmap.

So building a single computer is both a technical challenge and a social challenge. So the solution is this rollup centric roadmap. So quick high-level overview. We want to leverage L1 for consensus and data availability, and then use a marketplace of layer 2s to scale the execution. This is good because there's lots of different teams competing with each other to bring L2s to market, and it creates this kind of anti-fragile competitive marketplace.

But with this, we have problems. So users, they're fragmented between many chains. It's a zero-sum game for usage. So the solution, interoperability between chains. So with interop, there's kind of two ways to think about it.

There's application layer interop and then there's native interoperability. So app layer interop, if you've ever bridged before between two chains, this is probably what you've used. So, this has, you know, some baked-in assumptions about finality. It's slow. There's confirmation periods.

You know, there's fungibility problems depending on which bridge you use, right? There's also liquidity problems. Oftentimes oftentimes only the most popular assets are supported. And also bridge hacks. There's been a lot of bridge hacks.

So yeah, app layer interop, it can work for now, it's kind of good, but a lot of problems. So enter native interop. So there's a lot of possible ways to think about native interop. This is one way. But the idea is that it's built into the consensus of the blockchain itself.

So this means that the fork choice rule and the proof system enforce the rules of interoperability. And the main value prop here, at least one value prop, is that it's easier to build fungibility into the assets so they can easily flow between all the chains that are interoperable. So how do we plan to solve this in the OP stack? All right, so this is a lot of vocabulary. Not going to go super deep on this, but we'll basically go through the user experience.

There's two transactions. Two transactions. One on the source chain and one on the destination chain to do this. But we do think that this can be abstracted away and you can use relayers similar to 4337. But the idea is that there's two transactions.

You send a transaction on the source chain and then you kind of finalize the transaction by sending another one on the destination chain. This is a little flow of how it works. So there's this idea of an initiating message and an executing message. Those are like the two transactions. We call it the initiating message, the first transaction, and the executing message, the second transaction.

So the initiating message, it's literally any log. So what does this mean? This means that any log or like an event in Solidity that your application emits can be pulled into another chain. So any log, any event, all the applications out there, they already emit events. They're instantly observable by other chains.

Right? by other chains. This is nice because there's no extra mental model required for becoming an interoperable application. All the applications today, they already emit events. So instantly when interop goes live, all the applications instantly are producing useful data that can be pulled into other chains.

What's kind of cool about this is you can kind of think about chains as nation states that use gas, you know, that's like their resource, they use gas to produce useful state, and then they can export that useful state to other chains. And this is all observable because it's a blockchain, all the data's there, so we can kind of see like the trade between the chains. Just like an interesting mental model. So, we have this identifier. So this is kind of getting into the weeds of how it works.

But at a high level, there's this identifier that the developer needs to pass into the remote chain and the identifier points to the log that you're passing in. So, basically what this means is this executing message, this is like the second transaction, the developer, all they need to do is they just need to grab the log that they want to pass to another chain, and they build an identifier for it, which uniquely points to the log that they want to pass to the other chain. And there's three pieces of information that you need to do this. You need a chain ID, a block number, and a log index. Given those three pieces of information, you can uniquely identify any log.

And what this allows you to do is you can define the entire interop, like, you know, the main invariant. Invariants are very useful for thinking about protocols. all the executing messages, they must be valid, meaning that the log and the identifier, the identifier must actually point to the log that's passed in to the remote chain. So if any of these executing messages are invalid, then that block containing the executing message will get re-orged out of the chain. This creates a really nice user experience where at the application layer, you don't need to think deeply about validating messages.

You can just assume that every message that comes through, every cross-chain message that comes through into your application, you can trust, because the protocol will reorg out messages that are invalid or fraudulent. Cool. So we have this idea of a dependency set. And this dependency set is basically the set of chains that you can accept inbound messages from. So as a chain operator, you can come online and you can add chains to your dependency set and start accepting inbound messages from them.

In the future, we'd like to explore using zero-knowledge proofs to basically remove the need for this dependency set so that you can scale kind of arbitrarily horizontally. And the cool thing about this is it is possible to consume events from your own chain. And you can also in the future, we're going to make it possible to consume events from L1. Meaning that any event that happens on L1, you'll be able to pull right into L2 and consume it in your application. So another feature, shared security.

So what this means is all of the interoperable chains, because this is a protocol level feature, protocol level interop, all of the chains will share security and finality. And this allows for fungible assets. So the assets on the super chain, because there is shared security, it makes the assets truly fungible. If the security is not shared, you kind of end up in this world where it's weakest link security between all of the different chains. So we published this ERC7802, which defines a minimal interface that allows for a developer to create a token that can be interoperable using this scheme.

It also plays well with existing standards like XERC20 and Ether will be natively supported. So you will be able to send Ether between all the chains seamlessly and there's a way to upgrade all of the deposited assets to use ERC 7802, meaning that all the assets that have been deposited from L1 into the L2s will be able to be sent between the L2s. Cool. So we also have this idea of a shared lockbox. So what this means is all of the ether that has been deposited, it's custodied into a single contract.

And this solves the problem of withdrawal liquidity. So if you're depositing ETH into a bunch of different L2s and you're sending it around, there's one major problem where, you know, because it's still custodied on L1, and if you're trying to withdraw, you might run into problems. So this guarantees the ability to always be able to withdraw from a chain. Cool, so we've got some layers of abstraction. Not gonna go super deep into this, but at our lowest level, you know, it's, we have this cross L2 inbox.

You can kind of think about it like this is useful for reading arbitrary logs. Then we have this L2 to L2 cross-domain messenger. This is useful for cross-chain calls. Then on top of this, we have this super chain ERC20, and this is built on ERC7802, and this is where the fungible tokens come into play. Cool.

So, let's talk a little bit about app design. I think this is where it gets pretty fun. So, today, a lot of applications, they're built for a single chain. And when you want to deploy your app to another chain, often it's just a copy and paste. Literally take the exact same contracts, deploy them to a new chain.

So this results in some problems. This is where the liquidity fragmentation comes in. Right? Like a Uniswap pool on one chain might have way more liquidity than a Uniswap pool on another chain. What if there is a way that we can kind of have shared liquidity between all the chains, right?

So we get the liquidity fragmentation. We inherit the scalability problems of the individual chains and Basically the application depends on the chain for user experience. So this means Different chains kind of some are faster. Some are slower, right? The application has no say in the way that The user experience when it's between different chains.

So why is it this way? It's just because it's still really early. Right, so I think it's really important that we learn from Web 2.0. What does this mean?

Chains, they should be thought of as microservices and like a cloud architecture, right? Like, and for smart contract developers, they should be thinking about chains more like threads for your application So in an interop first world like how do we think from first principles in design smart contracts? They can be deployed Against chains that have really fast and secure native interoperability. So I think one way to do this is to identify subsystems of your application that do one thing really well and figure out how to horizontally scale them. This is classic web 2 architecture for scaling an application.

So find the gas bottlenecks and figure out how to shard them between multiple chains. And if we get to a world where we can auto-scale chains with usage, then applications will actually be able to scale to global demand. So let's just think about a DeFi example. Imagine that we had a horizontally scalable on-chain order book where the orders are all placed deterministically between a bunch of chains. And then the gas market can be kind of scaled or like smoothed between all of the different chains.

And then the gas market can be kind of scaled or like smoothed between all of the different chains. And as there's more users that come on board, there's a gas spike, you can just spin up a new chain and start load balancing execution to that chain. Now let's think about an NFT marketplace. So back to this idea of identifying subsystems of your application. So in an NFT marketplace, there's the ability to mint NFTs and there's an ability to trade these NFTs.

So what you can do is you can take this application and you can create a horizontally scalable cluster of chains that mint. And literally all they do is mint. They mint super fast at max capacity all day, every day. And if we had the number of users that say use Instagram or TikTok on a daily basis, we would need something like this. And then we can take the trading aspect, which is a completely different sort of smart contracts, and we can put them in their own cluster and horizontally scale this like matching engine for people to trade their NFTs.

Cool. So we need some primitives to make this happen. So we need a smart contract wallet. I'm really, really excited for the next Ethereum network upgrade, Pectra. We're adding an EIP-7702.

Very excited about this. It will make it really easy for users to add a smart contract wallet to their EOA and then basically give kind of like this seamless sort of upgrade into using smart contract wallets. So very, very exciting. I think it's going to be a game changer. We're going to be a game changer.

We're going to try to get it into OP stack day one. So the smart contract wallet, you can kind of make it smarter and it's one of the key primitives required to load balance your transactions across many chains. We also have been thinking about this idea of distributed storage. So what does it look like if you're building an application that is too big for one chain and you actually need to read and write storage across many chains from within the EVM, from within your smart contracts. This is a design pattern that we need to figure out and yeah, there's some interesting work going on right now.

People are trying to build like a promise library, like in JavaScript there's promises. Like imagine if you had a promise library in Solidity where you could just basically create a promise and that promise represents reading data from another chain. And then under the hood, somebody can, a relayer can just fill in that data. And from the point of view of the developer, they don't need to think about it. They can just create the promise and then it gets filled in.

And then they can resolve the promise afterwards. And they kind of get this asynchronous sort of style that they can build into their Solidity application. We also need a multi-chain RPC. So one of the goals is to eliminate network switching. Users should not need to think about networks.

It's kind of crazy. Users for Web2 applications, they don't need to think about switching between AWS and Google Cloud. It's kind of crazy. We can get to this world where users just point to a single RPC and this single RPC is able to aggregate all the information between all the different chains and have it be backwards compatible with Uniswap wallet or MetaMask. Cool.

So I'll talk a little bit about contributing. So we have open specs. If you want to understand how all this works, this is a QR code. It'll take you to specs.optimism.

io. The protocol is all specified there. It's very, very important to specify what you're doing. Otherwise, you cannot scale contributions. And sometimes you won't even know what you're building yourself if you don't spec it first.

So specs, check them out. It's also open source. Very important that it's open source. Not only is it open source, it's free software. You can take it.

You can do whatever you want with it. You know, it's MIT license, geth has more copy left, it's GPL. It's very important that anybody can take a roll up SDK and deploy their own chain and transact on it. So we're working on some public DevNets for Interop. We launched a public DevNet at the Edgelana Hackathon last week.

It was very fun. We deployed some apps to it, and they were interopping. So it's coming along. We're going to be launching more DevNets with more features and we're going to be opening up more and more to get feedback from the community. Cool.

Thank you. . Thank you. Thank you. Thank you.

Thank you. Thank you. Thank you. Thank you. Thank you.