Beyond scaling - Unified UX in a multichain world

Transcript

[Music] foreign hello guys my name is Fred and um I'm the tech lead of beamer and we believe that scaling ethereum with Roll-Ups enabled whole new design space for applications but it also introduces a new problem with a growing complexity in your ex so today I'd like to walk you through our research process at Beamer and what we think is the problem with the roll up Centric future what we what is the current state and what we need to do about it so that we really can achieve Mass adoption on ethereum so because we believe

the ux is currently the biggest block one of the biggest blockers for Mass adoption on ethereum so scaling ethereum is in full progress we have seen exponential growth in the past year users devs and liquidity escaping ethereum onto Roll-Ups and this is a continuous progress and we see a lot of Roll-Ups coming up and this is also one of the things vitalik mentioned in this blog post what we need to achieve for Mass adoption however escaping to Roll-Ups introduces fragmentation users liquidity there's really a whole set like a completely new

problem which is introduced by this horizontal type of scaling so this is really what we think is not going to allow for Mass adoption if we don't fix this problem and it's actually not only the users also the depths have this problem of fragmentation they see users and liquidity on different chains so what they have to do is they have to either leave the users currently alone and let letting them navigate The Tokens or the assets to the chain where the dab is deployed or they fragment themselves needing to maintain multiple instances of multiple Roll-Ups and also

fragmenting their liquidity if they have that some and additionally basically not being to able to integrate with other dabs which are not deployed on the same chain and when that happens users have to deal with this fragmentation they have to navigate through the networks they had to gain the knowledge first about the whole L2 infrastructure and yeah really like it results in a really horrible ux I think if you are an L2 user you probably had this pain already but if you adapt the developer you probably had this pain of like getting attraction from users and from liquidity of different chains as well so what we need to do typically when you

have a growing complexity and you want to really get a usability on your technology you need abstraction today I want to explore how we can get to the state of abstraction of of l2s but I'd really like to focus you on that we are talking about an L1 which is scaling so in this case ethereum scaling with l2s is also like there will also always be other l1's but we believe that scaling and L1 has fundamentally different properties than cross chain abstraction so the reason for us is um first of all first of all l2s inherit

kind of the security of the underlying base layer but also it's the same Community where the ethereum community and we should see in a way the l1s and the l2s as the broader ethereum ecosystem the broader ethereum Network so in a sense you could argue is arbitrum another chain or is it just an extension of ethereum and additionally when we're talking about and limiting ourselves in the thinking uh for l1s and l2s we have different security properties and different Technologies we can use to abstract this away um so but why do we need abstraction and I'd like to steal a really nice analogy

I saw yesterday in the polygon movie for example if you use a car you don't need to know how to use how it works internally you only need to know how to use it and you have this user experience to bring it to you from A to B and this is really how we should look at ethereum and when we want to have mass adoption for normal everyday users so end users should maybe know about their wallet they should know the depth that they are using but they should never care about the underlying infrastructure and the the L2 ecosystem and where the debt is deployed where the funds are they just should be

able to use ethereum securely so before we go into detail how this abstraction layer or the stack would look like and what what we can like Leverage um we should really like Focus first on um what what are we actually talking about when we have this fragmented world so we're talking about interoperability and interoperability We have basically three types of use cases or like of categories of use cases which can be solved differently so first of all we can we should we can transfer assets transferring as is pretty simple and straightforward use

case but typically users want to use their assets somewhere on some depth so this is basically investing asset transferring the assets and do something with it and then the third and that is actually like the probably the broadest category is state reading so typically people refer to as a general message passing but this gives you a mental model of like we want to push some information from chain a to chain B but what we are actually doing is we just want to know some state of chain a on chain B and this really depends on the use case um if it's uh if it's what what kind of properties it needs but I will go into

detail a little bit later so let's go up this abstraction layer stack from low level to high level so at the very bottom we have the core infrastructure the l1s and the l2s and the very specific thing and that is why I want to focus today on only abstracting away an L1 and it's l2s or even l3s is we typically have data availability on L1 and in fact by having this we also have the L2 to L2 availability as well so what we can actually do by having this enshrined into the base layer we can do storage proofs of what is

actually happening so we have the data there so we can do storage proofs what is actually written on chain a on chain B with ZK storage proofs we can vastly improve the efficiency and there are great teams like Herodotus who are working on that but what we really can do is we we already have a path to verify the state however typically and as as mentioned before um we have this finality latency and sometimes it's not it doesn't fit for the use case to wait seven days to read the state and additionally there's a lot of research going with shared sequencing which could also improve uh stage sharing between at least a subset of roll-ups

but if that is not enough and we want to have a faster or different properties in interoperability we need Bridges so that is where bridges come into play and here we have different architectures which have different properties and are have their strengths and weaknesses about how the message is transported how the state is transported so there are typically two architectures out there and you can also combine them one is the optimistic proof architecture where you basically claim that the state of chain a is like that and then there's a challenge window where anybody can challenge and basically stop the message if it's a false claim

then there are consensus-based valid data sets which is a set of validators which just assign what the state of chain a looks like and you basically have to trust this very data set and here you can see that the implementation of the architecture is much more critical than the actual architecture type so it really depends if anybody is completely permissionless to challenge or if only a white list can challenge and then also on the consensus based part it is really a big much bigger difference if there are only 10 validators or if there are hundreds of validators if there's a high stake of if they have a high stake at risk or of a

low stake at risk but what we can see in the properties here is that optimistic proof architectures are typically more secure but slower they have a higher latency because we need this challenge window on the other hand validator sets they have an economic bound which messages that they can transport but they can do it faster because we trust this validator set on top we need a vital and Active off-chain network so if you think about users want to use dabs on different chains we need these off-chain actors who actually help relaying the messages and the intents of the users securing

the bridges and um expanding on the account abstraction part to even like improve the usability of of the whole network additionally nearly with nearly all Bridge protocols we can have a liquidity layer on top so that is a simple thing um I'll simply explained for for use cases where you just want to transfer assets and invest them maybe or like have a user has an intent to do something with assets on a different chain typically of chain actors can just upfront the tokens and do what the user wants to do and then use the bridge protocol or even the layer 1 storage

proofs to get back the tokens on the other side from the user along with the bounty so this fast liquidity layer really improves on the um on the speed and the ux in this in this regard and then and that is very important we need an interface around it and that is where we are lacking in the community in ethereum community we need to create Open Standards because currently and I will go into a little bit in say a couple of words about it bridges are racing against each other and this is causing harm to the community so we need to sit down together as infrastructure providers and work together for Open Standards standards which where dabs can

basically build on choose the protocols and the providers based on their needs based on the types of messages they want to send and based on the use cases they want to implement and gain this abstracted vision of ethereum and build on it and just fulfill the intents of the users and so we as infrastructure providers need to provide this to the depths so that the depths can actually provide the seamless user experience on ethereum to their users and this is like what we are talking about this abstraction protocol where we

are actively researching on it so I just mentioned it a layer where devs can confidently build on which has Open Standards where new providers and new bridge protocols can come in where you can plug in and plug out and devs can choose what what Bridges to use and and what are the properties of these Bridges what they need according to their messages and allowing like crypto users and people to become crypto users and use ethereum security securely so where we do where are we today and why is this not happening today so if we look at the bridge space today actually we are in a very unhealthy situation where Bridges race against each other don't collaborate and just want to get

the biggest share of the market but this results in really raised to the bottom where the first cut they do and the first compromises they do is typically on security so it's not as I mentioned it's not about the bridge architectures it's about the implementation if you look at the most of the hacks we have seen in the bridge space it's actually because they're highly centralized that they're supposedly decentralized but validator notes run on the same same machine poorly executed a web to isec so here we in order to survive and in order to grow the market so that actually we

make the market bigger and bridges which are successful can survive we need to collaborate and need to create this healthy competition so just a couple of words about Bima we are currently a token bridge between Roll-Ups and R1 we are deployed on ethereum arbitrum optimism and since this week also on polygon zkvm and in our biggest goal was to provide seamless token transfers between these roll-ups so that users can seamlessly send tokens from A to B as a first use case in this vision of the abstraction layer therefore we have a fast liquidity layer

of our liquidity providers which then basically settle the trades on an optimistic proof architecture which is completely permissionless anybody could challenge that and if there is a challenge ongoing and there's a dispute we leverage L1 storage proofs to resolve the disputes correctly so last lastly we are actively researching and building on this abstraction layer and we need to understand the needs of the depths so if you adapt developer if you're a bridge builder or a core info Builder and want to build the seamless future of ethereum with us together please reach out to us thank you very much and if you have some questions please

ask [Applause] does anyone have a question no what are your thoughts on the recent proposal by connect on this cross erc20 template uh you mentioned that there's a need to build a kind of standards of cross purchase what are your thoughts on that attempt

yeah that's actually a great question so I believe the way connects is working on that is is the right approach to create or to propose standards and so that we can get in discussion and can get into the needs of uh or I can get into the needs of the depths and and builds together standards if it's actually the right way to allow Bridges to win tokens I don't know but I'd love to discuss and with them and I think um but it's a it's a very good step to get Bridges together and get the people who are working in the space together and actively like debate on um on standards like this

I'm gonna ask you one more question so it's not necessarily related to Bridges but in a uni swap recently announced that uni swap X which of course it has Bridges behind the scenes but it also goes beyond uh you know chains but it can also involve let's say Sexes and and other OTC providers and whatnot do you feel like in that model you are kind of going Beyond Bridges and bridges will not be the only thing to think about when you are combining a uniform kind of a universal network of liquid that combines both on-chain and off chain components yeah yeah totally so I I think bridges are only like a little piece in this whole stack and um it is and as you have mentioned like it can go Way Beyond even

chains it can also go be in in into like web 2 networks or like Sexes or something like that however I think there is no one model to rule it all we we have to um stick to like different domains and see what's the best solution for the domain another question okay thank you so much Frederick and thank you everybody [Music]