Standardization Challenges in the Ethereum L2 World

Transcript

okay um so today um what I will talk about is um basically some some of the issues around the Lear 2 ecosystem and especially the user experience in the Leer 2 ecosystem um as I see it today and some of the things that we can do to like really reduce um a lot of the downsides of a of having this world where we have a lot of different layer two projects and sometimes they don't talk to each other very well and move toward in ethereum where we get the benefits of all of this independent Innovation but we also have

enough layers of standardization that it still feels like a single unified ecosystem at the same time right so the way that I think about the highle goal is basically that being a user inside of the greater ethereum verse uh so including L1 including optimism including arbitrum including everything should not feel like you're jumping between 34 blockchains it should feel like you're using ethereum so one other way that I think about this is that I think the the goal that we should try to aim toward is we should aim toward a 2015 era ethereum experience with 2015 era fees right so you just

have it looks like you just have one chain you're just sending things on chain you have an address your people you people can send things between each other and the fees are extremely cheap but at the same time with 2029 era quality of user experience and uh scalability so let's look at Cross layer 2 asset movements for a bit right so above here I have a screen of what it looks like for me to do a depit to poly market right so what happens here is it says there's an option to deposit usdc and in order to deposit usdc you have to make sure to send usdc to this one particular address

and like it has to be polygon it cannot be polygon zkm see polygon and polygon zkm are totally different okay got it and you have to send eth to polyon and then if you send eth to that address on the wrong chain then your money is stuck right so this is where we are right now where I want uh ethereum user experience to be is uh something like what I have below here right so basically the the way that it should look like is they provide an address and if he wants to deposit you just have to take that address copy it paste it in your wallet click Send and and that's it right you should as a user you should

not even have to really worry about or think about the concept that there are different networks um you basically just like you would have an address and then you send your coins to that address and you're done right so one question that we can start from is basically what are the Technologies what are the changes what are the standards that we need to actually make depositing to poly market look like the thing on the bottom instead of looking like the thing on the top uh so this is ERC 3770 right this is uh a standard for how addresses can work in a way that makes sense um in a Crossway or 2 ecosystem right so today

an address is just 0x and then you have your 20 bytes um and like that's your address inside of some Network right now if I give you my address you don't know whether I'm accepting funds on Main net on optimism on arbitrum somewhere else right like actually you know you could I could want you to send funds to me on optimism but you could instead send me funds on arbitrum and like mistakes could happen the way that ERC 3770 works is the chain is part of the address right so in the example here if he wants the sense to my address on optimism it would look like op colon 0xd da blah

blah blah right so chain is part of the address right so the core idea is basically that the address should contain all of the information that someone needs to know what to do if they need to send you money or if they need to delegate some kind of authority to you right so the function that an address had in the world back in 2015 when everything was on layer one that's the same function that an address should have in 2024 when we have all of these different layer TOS um so what this means is the network needs to become part of the address right and uh in my example here that's basically what I

have right I have polygon colon 0xf blah blah blah and then if you take an address that contains polygon colon 0x blah blah blah and you put that into your wallet your wallet immediately understands that this is a request to send coins to polygon right and so it doesn't try to send coins anywhere else it it's specifically tries to do something to make sure that coins on the polygon Network get sent to that address so the first part of this is just defining the azur standard right this is something that safe already uses this is something that more and more wallets are already starting to use today the another standard which is also

important is ERC 7683 right so ERC 7683 what it does is uh it actually does cross layer to um asset transfers and in particular it uses them it does them through liquidity providers basically through a decentralized exchange mechanism in such a way that if I make a initiate a send on optimism to arbitrum then I send the transaction it gets included on the optimism chain and the destination address should get the payments on arbitrum generally within one or two slots right even though

optimism natively has a 7-Day withdrawal window and arbitrum has you know like some like several minute deposit window you rely on liquidity providers to provide the capital immediately and then when once they're able to prove that they transer those funds to you they can claim the funds um on the optimism side from you right so basically just using a general like this purpose Crossway or to decentralized exchange Network and having this like actually directly incorporated into wallets so that if he wants to send coins from one network to another it it just automatically directly uses this right like the concept of sending coins and the concept

of bridging should not be two separate operations they're they are the exact same operation from the user point of view right and the wallet should just handle doing a send if it's on the same network and doing a bridging operation if it's on different networks now that's a short-term future now let's talk about science fiction a little bit here is uh a longer term future right so imagine a world five or 10 years from now and everything is a ZK rollup and everything uses ZK technology that confirms within one single slot this is uh like starting to be actually possible right it's uh theoretically this is completely

possible but practically we actually have ZK provs that are able to prove like right now average ethereum blocks in like about 15 seconds right now this does take a lot of gpus right this does involve parallelization but the latency is already decreasing massively right and there no theoretical reason why the latency needs to be longer than maybe 4 seconds and so if you have ZK rollups that are all confirming to ethereum in each and every slot then there's actually a way that you can do all of this Crosswire 2 Trading without even needing liquidity providers right and uh this is a an interesting strategy that

uh I mean I know some people are starting to look into and so you know Justin has been looking into this Alex goovi from matter Labs has been looking into similar things a lot of people right and uh you know basic idea here is uh so let's take a simple case right let's look at commonly traded assets so let's look at for example eth and know like wrapped Doge moving from let's say in this case like from scroll to base right so fairly common networks fairly common assets so what happens is that on the on the source chain uh so in this case arbitrum right basically you have a lot of different transactions and you're

going to have a lot of transactions that are sending coins cross chain and they're sending them to different users but they're sending them to the same network right and so over here from a user point of view you have someone sending five E to Bob someone sending 25 e to David someone sending 20 e to Fred but from a network Network point of view these are all transfers to from arbitrum to scroll and so you batch them and you and as part of the block you just directly make one transfer that immediately transfers the coins from um from arbitr M scroll so this is uh if you have commonly traded assets right now one big question is well what about rarely traded assets right what about

coins that are extremely rare coins that only have a few people using them or or even nfts right one of the big challenges with 7683 is that it only works well for commonly traded assets it does not work at all for nfts because there's only one copy of each nft right like you cannot use a liquidity provider to like give you some Shadow copy of like vital. eth right like liquidity providers can't just like clone vitalic doeth and then front a copy and uh for me and then like claim that copy back seven days from now so for rarely traded assets we use another trick which is we can make a specialized mini ZK rollup which performs only the task of managing

asset transfers right so you basically have a mini ZK rollup whose role it is to accept a more complicated list of transfers basically a list of all kinds of different assets erc20 earc 721s that are being transferred from one L2 to another L2 and then it has one block that and it's also on L2 and so you have this entire big set of transfers that gets processed on L2 and L1 only sees the updated state route of arbitrum and it also sees the updated state route of this cell layer of this asset layer to and so you're still only putting a little bit of information uh and doing a

little bit of computation directly on layer one right so this is uh a possible future like a possible long-term future of how asset movements might work without relying on any kind of liquidity provider infrastructure in the far future now this still requires a lot of Technology right this still requires very robust uh you know ZK EVMS that can provide proofs in one slot uh but uh like I think this is where we're going to get to eventually now cross chain account abstraction right so you know we talk lot of people are using safe right so who here uses safe good lots of people using safe now one challenge will safe is uh what

happens when you have assets across many different chains and at the same time you need to sometimes upgrade your wallet right so like for example you might want to change your key if it's a company maybe remove one key holder add one key holder if it's a single user maybe you don't trust some key anymore you want to switch to some newy you wants to upgrade a hardware wallet like anything the challenge is if you have your wallet on 20 different l2s then how do you actually do that upgrading at the same time so the short-term solution is to make the upgrade be a message that can just get automatically

replayed across chains right and this is something that people are already starting to do the long-term solution is this approach called key store wallets where you basically you have the record of what the keys to an account are and what is the logic that verifies an account in one place and then you have Assets in many different places and you have a safe that's in many different places and that safe can read into the key store this is easiest to implement if the key store is on L1 right so on L1 you can have your accounts you can update your account and then l2s can read into L1 every time you make a

transaction so this is something that optimism already I believe supports I know scrollers are looking into supporting it like basically the ability for L2 is to read L1 if you have this then supporting things like keystore wallets becomes much easier gas payments uh so today you need to have eth on chain a in order to send transactions on chain a one thing that should will become possible tomorrow is you pay eth on chain a and then you automatically pay like basically create an open auction for a bundler to send a transaction on chain B on your behalf these are things that are like starting

to be already possible Right but these are all things that we can absolutely do using decentralized networks right in a way that does not have any dependency on specific centralized actors now you could have have you know people that are professional professionals that specialize in doing these operations but if one of them disappears another one would be able to immediately come in and take their place light client support um so today we actually are starting to have light clients that can kind of verify L1 so there's a project from a Noah on a16z crypto uh called Helios and uh Helios is

a light ciance for ethereum so it actually verifies at least part of ethereum consensus and so if you're using helium to access or Helios to access the ethereum chain then you're not trusting infura to give you state rots right you're actually verifying signatures and you're verifying that the chain that you're following actually is the chain that the majority of the ethereum stake is supporting we have this for ler one kind of um like it's still early stage software it's not yet incorporated into the major browser wallets it should be but it it will get there but we have nothing for L2 right and I think we need to always keep in mind right as we move from layer

one to L2 all of the guarantees that we wanted from ethereum L1 they need we need to make sure that they apply to layer 2 as well so the future is we need to have light clients also support layer 2 to the good news is this is kind of easy right actually Helios already does the hard part which is verifying consensus and so you have the header chain right you have the chain of like basically the most core parts of the ethereum blocks once you have the header chain you can use Merk branches and you can verify any particular thing in the ethereum state now once you can verify things in the ethereum state then if you have a based roll up right so this is

the example on the Left Right Tao a base rup then you act it actually has a contract that contains a state route and then you use another miracle branch and then you can verify any object inside of the tyo state if you have a rollup that's not based then you have a contract that contract stores what the current signers are of L2 blocks and then you basically accept anything that's signed by that particular set of signatures so somewhat more indirect approach but this is what you need to do to have like Best in Class like as trustless as possible access to an L2 so this requires some software work this

also requires some standardization so in particular a chain config should also have a some kind of pointer to the code that actually does L2 light client verification so I recommend like we basically just do this the same way that the CCI ERC does it right basically you just have an onchain contract that has a function that does the verification but there's several different ways to do this um proof aggregation so one of the there's two big bottlenecks that are preventing us from having ZK rollups that confirm that that submit to ethereum every slot one of them is pro

latency right right now for for most of the production system proving blocks takes maybe 10 minutes maybe 20 minutes it takes some amount of time the other problem is that is that some putting a proof on ethereum costs costs gas right it costs a quite a lot of gas for a very simple proof about 300,000 for something like a stark from starkware maybe two or three million so these are costs that they do not want to have to pay in every single slot and so a natural solution here is to have an ethereum wide open infrastructure that does proof aggregation right basically user or l2s can submit their proofs

instead of submitting them directly on chain they can submit them to an open network and then when they submit them to an open network you can have anyone that's able to create a bundle and the bundle generates a proof of the proofs so it generates one Stark that proves that all of these other proofs that are specific to the layer twos exist it generates that one proof and then it publishes that one proof on chain and that automatically updates the state for all of the different l2s so if you do this then l2s would be able to publish to ethereum every slot and you actually like it actually would um have a lot of gas

savings um application layer stuff um so oracles this is one thing that's currently not very efficiently designed it could be more efficiently designed basically if you have L1 SL load or L1 calling then you could have Oracle data live only on L1 and then all of the l2s can just call into it um or you could try to use a pull architecture instead of a push architecture for oracles um ens needs to move to L2 they have plans for that they're executing on them um ens supporting users having different addresses on different layer twos so so these are just like some of the big examples right of uh things that we need

to have if we want the ethereum layer 2 ecosystem to have the same kinds of properties that we have been expecting the ethereum ecosystem to have all along even back in 2015 when we were that when all that existed was layer one right layer the the transition to layer 2 is there to enable scale without sacrificing decentralization and we need to do all of this work we need to actually work hard to make sure that we actually do not sacrifice decentralization so what do we get if all of the ideas that I just talked about are implemented let's talk about the user's

experience if you're a user and you need to send assets could be eth could be usdc could be an nft then all you need to do is put an address into the two field and then collick s basically you you would need to do just the thing that you were doing back in 2017 when everything was on one network except with all of these standards it would actually work regardless of which L2 you're sending from and regardless of which L2 you're sending to the user experience to upgrade your wallet you do it once um and you do it in one place and it immediately has an effect everywhere the user experience to pay gas right now if you I know know there are a lot of people that have a lot of

different ideas for how to support different users even users that do not have any eth um but I think at the very least if you do have eth you should be able to click Send and transaction fees should be able to get paid you should not have to worry about making sure that you have eth in all of the right layer TS at the same time right there should be things things that you can do that work entirely in the background so that if you have then you can click Send send a transaction and everything that wants to happen actually does happen the user experience to verify the chain uh so the user verifying the chain should be fully secure should be trustless you should

not need to to trust an RPC provider you should not need to trust centralized infrastructure even if you use centralized infrastructure in order to get information about the chain quickly you should not have to trust it and I think this is something that actually is possible to achieve and the time that it takes for transactions to finish should only be one slot right 12 seconds so basically like we can get all of the same benefits that we actually already had when ethereum was one chain when it was just a layer one but at the same time we can we can we can have an ecosystem where we have those benefits

but also we have much more scale we have thousands of times more scale than we had before because of uh the layer 2 ecosystem and at the same time we have this ability for people to have many different kinds of layer tws that try different things that take different tradeoffs that and that experiment with different virtual machines um experiment with uh different uh kinds of centralization and decentralization and so we get the benefit of experimentation at the same time right so we have you know a thousand flowers blooming and at the same time we have standardization and everything still feels like you're

sending eth you're sending assets you're doing you're participating in Dows doing all of your operations within one single uh great ethereum ecosystem so this is the goal and uh I hope that uh we can work hard to get there thank you