Design Decisions Shaping L2 and Ethereum Interop From Mark Tyneway OP Labs Optimism

[Music] hello hello okay okay my mic is working now well welcome to Sunny Colorado here we are another eth Denver so my name is Mark and today I'm going to be talking about some design decisions shaping l2s so we're going to get into the why rather than the how right so user stories help solve real problems I'm here today to talk about the actual user problems that we're trying to solve with the blockchain you know we want to move away from just talking about the technology as this solution and really think from first principles from the perspective of the user and the problems that are being solved so let's start off with talking about user stories so a user story is a description of a software feature articulated from the end users perspective it focuses on what a user needs rather than the technical details so this this is the important point in ethereum we love to talk about the technical details but here when thinking in terms of user Stories We want to focus on the user needs we want to solve real problems for real users so how do we formulate a user story as a who I want what so that why this is like a very simple template for how to make a user story and doing this will help to make sure that the technologies that you're working on are framed in solving problems for end users and not just an interesting idea to work on so first thing we want to do we want to Define our user this is one of the most important questions for any startup so for Simplicity we're going to say today our user is any entity with an onchain asset now I'm going to walk through some value props in some user stories and we can from there talk about the design decisions for the op stack or blockchains in general um to really hone in on how these problems are being solved so censorship resistance as a user I want to be be able to guarantee that I can include a transaction so that I can maintain the ability to exercise property rights over my assets so why is this important for example you might have a loan in Defi and you want to keep it collateralized when there's lots of volatility you are at risk of losing your money to a liquidation if you cannot land a transaction on chain right this is very very important this censorship resistance property so thinking in terms of the op stack and l2s there's this idea of force include transactions so there there's basically two ways to include a transaction into an OP stack based L2 you can either go through the force include path which is a little bit slower or you can go through the direct to the sequencer path which is a little bit faster everything comes with trade-offs the slower path the force include transaction path that goes through L1 so that guarantees the sensorship resistance properties of L1 if you go directly to the sequencer the sequencer technically can sensor if they want to through the low latency path But ultimately the only Power of this sequencer has in this case is the ability to delay the inclusion of a transaction they cannot completely censor any transaction and we saw this play out in practice with sonum so sonum had this policy where you know they wanted to protect user IP rights um through their sequencer so they did not want to include any transactions that would infringe on those rights but it's possible for any to you know go through L1 through this Force include transaction path and get their transaction included and you can see the l2b team here actually did this in practice and they were able to you know touch these tokens and trade them that the sequencer was not processing transactions for okay next user story we're going to talk about hardness so as a user I don't want the rules of the platform to change underneath me in a way that is not aligned in my interests so that I can rely on the platform in life or death situations right this is one of the promises of the whole crypto and web 3 movement is there are these existing platforms that can kind of just change their rules arbitrarily and you don't really have any say in it so this property of hardness lets you understand the way that the platforms or your counterparties are going to act and have transparency into that um so that you can rely on them more and you don't need to worry about say being deplatformed or the platform no longer um changing or changing its rules in some way that isn't aligned with you so this is why the rollup stages framework exists we have this idea of a stage zero roll up a stage one rollup and a stage two rollup so a stage one rollup has a forced 7day delay on upgrades while a stage two rollup has a 30-day delay on upgrades so what this means is if the chain is changing its rules in a way that you don't like you have time to exit the chain and go someplace else now people often ask the question you know can't the sequenc are just arbitrarily change the rules this is not the case um the only way that the an OP stack chain can change its rules is really um if the um proof system is upgraded on chain and it's really like this social consensus around like who's running the full nodes like the sequencer does not have the unilateral ability to just arbitrarily change the rules and push them on their users the old chain will still live on and the bridge will still um basically allow for users to withdraw from the old chain it will not follow the new chain okay so let's talk about medium of Exchange as a user I'd like to send my onchain assets to purchase real world Goods with as good of a ux as a credit card so that I can rely on blockchains for everyday expenses right this is like a real everyday sort of use case for blockchains the reality is that you know we cannot finalize blockchains basically instantly there's tradeoffs so we have this idea of levels of finality um people talk about pre- informations right um for an optimistic rollup finality of the chain happens as soon as the batch data is posted to L1 a lot of people seem to think that for an optimistic rollup the chain doesn't finalize for seven days that is not true chain actually finalizes as soon as the L2 transactions are posted to L1 to you know the the da layer all right so let's talk about liveness this is basically the chain staying on so as a user I would like to not rely on the uptime of a third party so that I can always rely on my onchain assets so what this means is if the sequencer goes down the chain stays live and you can continue to talk to it and interact with it through Force include transactions you don't need to worry about if the sequencer is online or offline but um we have this idea of like the sequencing window basically if the sequencer does go offline you will definitely experience a large quality of life degradation with interacting with the change it'll be much slower but you can still interact with the chain get your assets out so yeah there's actually a UI that enables this if you go to bridge. G you can arbitrarily interact with any L2 contract directly from L1 so now let's talk a little bit about me protection so as a user I'd like to transact without being worried about being sandwiched so that I don't leak my value right this is a major problem on L1 where you know there's like Jared from Subway who sandwiches users and they make a lot of money doing this it's the Dark Forest so with the op stack we have this idea of a private M poool where only the sequencer can learn information about the pending transactions this prevents malicious actors from going in and you know um extracting me from the users now there's a trade-off here because technically now the sequencer can extract this me but it's possible to run the sequencer in a te a trusted execution environment and basically prevent this because the the whole thing with the te is you can basically say this is the exact block building algorithm that I'm going to use and anyone can verify that I'm running it and anyone can go and look at exactly what it does they can run it locally they can play with it and they can see that it does not extract malicious me so it's a good tradeoff now write costs so as a user I'd like my fees to stay consistently low so that I'm never priced out of being able to exercise the property rights of my onchain assets so this is why we're working on horizontal scalability through interop in web 2 they have this architecture where you can horizontally scale your application in the cloud in crypto that's just not possible people are still deploying single server applications on a single chain right we need to evolve past this and start to develop applications that can horizontally scale across many chains this is why we're working on the cluster architecture in the op stack cool so who else are our users app developers let's talk about app developers so with the op stack we really care about evm equivalence as an app developer I want the ethereum tooling to just work with my app deployed to L2 so that I can focus on application development instead of rebuilding my tooling stack the idea is that the you never really want to surprise developers building on your platform you want it to work the way that they expect so by focusing on ensuring tools like Foundry and hard hat just must work for op stack by avoiding introducing extra pre-compiled or large modifications to the evm um it makes it a lot easier for developers to just build their app and ship it and use all of the same tooling that um The Wider L1 ethereum ecosystem is built to ensure that their application is safe so in the context of interoperable apps as an app developer I don't want to have to worry about complex interop details so that I can just focus on my application logic so the solution here make cross chain calls as similar to calls within a single chain make them as similar as possible so what does this mean we want to build tooling like a library that you can just drop right in and from the developers perspective it'll be literally no difference than just calling a smart contract on the same chain cool that is it for my talk [Applause]