L2 Interop Forum

Transcript

all right good to go W thank you everybody awesome thank you all for coming we can uh just start off with some quick intros and uh maybe what makes you most bullish on our ability to solve interop in 2025 and what topic are you most excited to to get to today if you want to we may we start with H can't hear mic is not working for haen let me save the date okay

okay oh no perfect hello everyone oh sorry hello I'm hi Chen I'm co-founder from scroll um I guess like so scroll is building the ZK evm ZK evm for Z Rob um so what I mostly excited about this is like I think we like all of the layeres get sit down and then talk about how to solve the interop operability problem I think that's the most important since I will see like the for this event yeah yeah should that be good oh there we go all right I'm Mark Boron I'm the CEO

at polygon Labs I think for Relevant purposes here we're contributing to the a layer to build out interoperability across ethereum uh I'm excited because I like fundamentally believe that we can create an aop that makes ethereum feel like one again the way it did you know a few years ago uh and so I'm I'm kind of like pumped to come together to to make that happen no hello hello oh it works so I'm Nicola I Le the line team got to backround in this s on reearch we started the reearch on on rollups in

2019 and I think as everyone the main point is to to make eum compatible again as much as possible uh and there's a lot of work but we'll be able to do it hey my name is Mark and I a contributor to the optimism Collective I am really bullish on us making a lot of progress on shipping interupt in 2025 there are just so many lwh hanging fruits and we just got to go out there we got to pick them we got to focus on user stories right we have to kind of come up with a a shared vision for what

we want the user experience of using ethereum to be and then we can work backwards from that we don't need crazy protocol changes to do this we just have to agree what the ideal user experience of using ethereum and all the l2s are and there's a lot of uh stuff we can do outside of the protocol at the application layer and a lot of the L2 Tech Stacks are maturing um we need to kind of get out of this fight for survival where we're stuck making short-term decisions and now we have credible competition from other

ecosystems like salana and I don't think we would be here right now if it wasn't for salana you know growing challenging us and I think this is a good thing you know competition is good so you know I want ethereum to win and I'm a big believer in turning zero some games into positive some games I think that if we just start deciding to play positive some games with each other I think that we can you know make positive some games the best outcome for all of ethereum and grow the whole

pie hi everyone I'm Ed Felton I'm co-founder and chief scientist at offchain Labs the original developers of arbitrum uh and I've been saying on panels all week that uh I reject this Narrative of ethereum fragmentation uh or fragment a in the ethereum stack where others see fragmentation I see diversity customizability and user choice but the key to really moving not only the narrative but more importantly the reality from fragmentation to diversity and choice is interrup um and that's why we're all here um and I think I agree with what others have said that um if we focus on the progress that's available to us uh we can make user

experience much better in the near future uh testing okay it actually works yay um so I think uh for me I'll give my like one sentence definition of what the goals of interoperability are uh basically the I think the goal is that the ethereum L1 plus L2 Universe needs to have the same security and convenience properties that we would have expected in demanded ethereum to have had we done execution charting um so I think if you think about it that way than every single item that we've talked about whether it's uh cross chain sends or addresses or light clients or um like smart wallets or any of these

other topics just like naturally falls out of that and so I think for me like having that as a cental goal is something that's uh really valuable and I think the reason why I'm excited is uh that like ethereum has uh always had a strength of having diverse teams that are all taking approaches and doing different things but at the same time actually working together where it counts this is a thing that we've been doing between client teams for a decade and uh to me this is the first time where we're taking that exact same approach and repeating it with both layer 2 protocols and with wallets right

I think ethereum ecosystem and operability is not just a layer two problem it's also very much a wallet problem and I think having people from both sets of ecosystems here is going to be valuable and I think we'll get like actually make some very concrete agreements and steps today and uh get much further toward getting ethereum interoperability done hello I'm I'm marching I build on ethereum what i buildt is actually ziki sync and I think this is the common thing for all of us here we are the we are etherum Builders first and second is for all the features that our l2s are

proposing the thing that makes me most bullish is the fact that we're all here maybe it's sponsored by Solana you're right maybe they are the ones who cause us to come but we're here in person it's not you know quick Twitter pinks left and right but we're actually here and ready to talk on how to make sure that not only our systems get better but also users kind of get benefits from it rather than trying trying for us to lock lock users into our system we want to establish these ground rules we want to establish these common patterns to make it easier for future Builders to be able to choose from diverse systems that we're building so

very excited to be here and talk about it hi I'm bre I work at Tao uh so yeah we're like a based rollup and I guess like one of the benefits of being a based is that you have like well in theory at least you can like work together you have like compos composability between the Bas wops andess the exciting thing here is that there are actually more base rups now popping up so like for a long time this was only like TECO but now there's like many projects that are trying to build a based rollup and all these kind of like based rollups do have like kind of like the intention to kind of closely work together and yeah try to kind of like solve some of the fragmentations or whatever you want to call it uh so yeah that's kind of like exciting people kind

like excited about it based Wars are getting better better like a day or two we had like the first based prec confirmation on mayet uh there's still quite a long road to get there but again these things are getting better uh we are trying to be like composable and like I'm very excited for to happen thank you all uh so first topic for the group what is the biggest obstacle to solving interop uh and this is something that we've all been talking about the past few days is actually something uh that is not a technical challenge it's more of a coordination and communication human challenge uh we we all have this shared vision for what

we want ethereum to become and we all genuinely believe that solving this thing getting this thing is critical to actually unlocking that Vision um so yes what is the biggest thing that we can do to make meaningful progress not in years but in months hopefully in the first half of 2025 maybe whoever wants to start first we can start on this side right so as you mentioned the main problem is not technical the main problem is if you think about it as a prisoners dilemma with this crazy lock where on one side the current status quo is if we each one of us look selfish the current status quo is like hey let's build something

special just in my ecosystem and let's try to get people into the ecosystem at the same time time this is something that will cause us pain going forward right so the thing is tldr it's not technical it's about us sitting here in these discussions that will start here and will continue over over the internet and actually talking about these layers of common common things that we can we can build together to me it's more of a coordination problem there are a lot of us there are a lot of l2s a lot of l3s L different L2 app chains um and uh many of the things that we need to do are not that difficult to do we just need to

agree on the details of how to do it what are the formats what are the expectations and so on I think we all know how to do that we just need to get in the room and do it and so here we are in the room yeah I mean I think for me like I also feel like there's this limiting belief like there's this perception that like oh decentralized ecosystems can't coordinate and if they do this requires this like years long winding standards process and I think we can just get past that if we just agree that we're not doing that like I personally want for everyone's here today before we get out of the room to agree one we are doing onchain configs two we're doing chain specific addresses and just agree flat out before we get

out so that these are things that we're doing and agree in an approximate road map for that and I think if we can be aggressive on the timeline then we can make meaningful ANS before the end of this year I think like the one important things we seeing here is like align the goal what is the goal for the inop like Isle like like example some like clusters which inter uh within achain cluster good enough or should we like push for all of the layer tools like in a Sim to be have a way to inter with each other I think if we align the goal then we can set like what's the pass to that goal I think the go the way to think about this is um the goal should be rooted in a desired user experience

so saying something like any ethereum user can reliably transfer their funds from one L2 to another L2 in 20 minutes like that might be one uh goal and then we kind of have to work backwards from there towards uh the technical requirements to enable that okay what is this 20 seconds number 20 minutes number 12 seconds come on Rost can do two seconds optimism to arbiture I'm like come on get off your butt here I just picked a random number if we want to become more ambitious let's do it yeah okay low low value amounts that liquidity providers can handle um let's say three Slots of the slower of the two chains

like three Slots of the slower of the two chains yeah okay yep should be possible Right mhm you come on like cross is like literally doing it between you your guys already all right somebody better better be taking notes I mean I'll I'll say the thing that most people probably don't want to say I think incentives are like completely misaligned is just reality like um I think uh I I'm not going to hold polygon up to some like higher standard like we are building an interrupt that is intended for everyone we will connect op stack and ARB chains in the next month to the a layer and we will connect ZK stack

chains to the AG like the goal is for something that is ethereum wide and frankly I actually think that we're getting to a point where we benefit from certain assets coming into ethereum EOS system beyond that but leaving to ethereum like I think the thing is this is already possible and I think Mark the way you're describing like that user first experience is 100% what we need to describe but I think like to be like super explicit about it like um almost everyone here has a token that has been issued and that creates a certain set of incentives and I think we should be like very realistic about like how that fits into future plans because I don't think like we're going to solve anything if we don't actually acknowledge that reality and then say okay so knowing that reality what do we now do with it to

reach this goal of kind of inter up with an ideal user experience so so did you say like if we do our job well layer to could be obsolete in like 5 Years and we're okay with that I mean the reality is like um ethereum should be building towards the best reality possible and like um my view is like right most of web is going to be eaten up by web 3 there'll still be some normal use cases for web to it makes sense um ethereum can't do it on its own so there's going to be need to be something that exists on top of ethereum that's the whole point in the road map that actually exists right and so then the question is given that road map what is the ideal user experience in five years from now right and if that

means less l2s then that means less l2s like that that has to be like the the target if that's the end goal which it is and so yeah like I I I think we're going to be at a a point where uh I mean we're already at a point where we have too many of the same l2s uh I think we'll look fast fast forward five years from now and probably say we don't actually need that many of them um and so yeah I think we'll have a smaller number than than we actually all envision if we kind of do this right as well I mean there's when we're speaking about interoperability there multiple dimensions one of them is actually the developer experience Dimension which is having uh the same smart contract deployed without any

other aits in main net or in other Layer Two so there's really this developer Dimension and there's the user experience Dimension which is all I can transfer easily from one roll up to another but it's as well the way the gas is estimated is it the same the AC abstraction logic is it the same or do we divide the user experience by layer two and then we do have a contradiction which is maybe not even the incentivization but it's okay we we're not sure about what to do so we do bet on some options and the other are going to do bets on other options and how are we going to reconcile and there's really this strategy do we try first and then do we try to reorganize or do we think first and then do we do things uh so I do believe that it's interesting to

think first and to try to coordinate to try to um to look at what the others are doing and are doing and let's do the same thing I think it's useful as well to be ready to change if we're saying that we're doing something and we see that there's a majority going somewhere else and we should change this for example the state representation at a very low level is incredibly different between all the layer TOS but maybe we should actually converge to a single representation the next five years so I think we should build for change that's quite important uh and I think we should be very careful on your point to think that we're going to be smarter than everybody else individually uh because yes we can be incentivized to be smarter speaking to a VC yes I'm smarter than everybody else I will have the best

solution that will destroy everything I don't think it's going to be that true actually so we should sa a truth to V which is oh yeah we're doing something because it's important but actually on the long term maybe we won't be differentiated because it will make the cake bigger uh even if you have a smaller piece of it but Mark you had a very good point is that yes incentives are aligned in a different direction and here the other Mark actually brought a reason why we're here now because we as the whole ecosystem have competition now sure we we will be fighting of course on Twitter we'll be like hey you guys didn't do this we did this of course it's natural but usually what brings people together is a common

goal or common enemy and we suddenly have both hold on on I want to dispel this myth that like ethereum suddenly has competition it did not before this is like I think a way more narrow view than we should have look sea single hero payments area that is credible competition it's just uh improved massively over the last 10 years payments inside of the United States like fedwire all of the improvements in moving money within the United States credible competition improved massively over the last 10 years in 2012 if you used bit like if you remember how Bitcoin was advertised Bitcoin was advertised as being the cheaper way to send money you did not have to wait multiple days you your transaction fees were less than one cent PayPal took 30

cents and you had to pay 6% for anything International like most of those uh barriers in the centralized system are now like five or 10 times lower than they were before right the then let's look at AI right so if the decentralized world doesn't step up then like the freaking centralized world that's based in San Francisco is just going to like take over everything and possibly blow up the world in 10 or 20 years okay so like a ecosystem like the centralized World itself there's a much bigger than this and it's moving forward very quickly and uh if we want the thing that we really need to be keeping up is not like putting ourselves against other blockchains it is with [Applause]

that I guess sepa is not on Twitter so building off of what uh vitalic touched on earlier with onchain configs and chain specific addresses I'm wondering if we can what tangible and specific commitments we want to make here today um in that sort of in that Spirit or perhaps uh what we've also touched on earlier um perhaps this idea of having a formal some sort of formal working group that can uh sort of the bare minimum here so yes we at least agree that we will have Representatives at this working group that will work towards things like uh onchain configs and chain specific addresses just to yeah I'm I'm curious what what the what

everyone here things around those those ideas and and making specific commitments here today y let's do it maybe hold on on let's uh we're gonna put every a fire under everyone we're going to go left to right and no one's leaving until people say yes so your turn onchain configs what do you think it's going to be a long panel yes yes I agree I agree these are very important things we have to do okay h sure okay yeah let's get to work on it mhm yes but conditional on having a very clear user story that shows end to end how it solves a problem for an ethereum

user today okay um I can give the uh the the user story so the difference between um onchain configs and the status quo is that in the uh status quo in order for a user to be able to communicate with a chain at all that chain has to be on chain list and if it's not then like you don't have a way to communicate with it we're also going to have many more ler toos examples of that would be a chain that just gets uh quickly spun up for some game or some or some voting instance there's more and more of these coming up and uh we want user like we want to have a world where as a developer your story is it should be permission for you to set up a chain and be compatible with things does that

satisfy you yes okay your turn so yes as well with a small bird that we should Define exactly what we want to do CU if we don't put uh some precise goals it will be a lot of meetings without any finger Shi at the end okay um as precise goal how about at the minimum take in the uh information that is on chain list.org including chain ID and like very basic parameters and agree for that information to be on L1 yes okay your turn uh yes and and I'll just repeat the caveat I think what Mark said is just like bottom line is as we go through this just keep in mind all the time okay

and yeah I'll say yes okay amazing okay let's everyone collap we have our first agreement so we're done right I mean we can keep we we we can keep going if we want I think we can keep going uh there any opening it up to the panel are there questions anyone has for anyone else on the panel for vitalic or vitalic do you have questions for the panel here okay how about we'll just uh increase our like level of buoyancy and do around two of this which is uh if we have chain specific configs does that does it feel a good idea for us in the longer term doesn't have to be first priority to also specify how to do

things like State proofs so that we can have Universal layer to light clients that's a more complex thing because the main dilemma is how much we want l2s to be different to be able to explore different trade-offs right versus we want them to follow like one standard and of course it's it's one of these things where you know it's hard for us to predict what will be in a couple years and if we decide on okay this is exactly the format we want then you know maybe in couple years there's some new breakthrough whatnot and it will suddenly be like yeah but no one's exploring this because everybody has to stay on the same okay so I think actually for me the idea of putting in the config actually precisely is the flexibility maximizing

approach right because the flexibility minimizing approach is basically we go around here and uh we basically say everyone has to adopt veral right and uh I'm saying let's uh not do that let's support maximum flexibility but let's support the goal of putting out information in a standardized format that enables L2 litecoins which uh follows the goal which is uh we want l to have the same property the properties that we would have demanded ethereum to have had it done execution charting and one of those properties necessarily is like Cent friendliness so what T we always like purest right we always stick to whatever eum does uh but like how do you kind like enforce the same security right

properties if there is diversity right so that's kind of like the problem I have with like these well right okay I want to customize but like how do you have like a uniform kind of like experience yeah in like a different way so I'm not how you combine it yeah yeah I agree there's like there's two axes right one of them is having a format and then the like having a Common Language and then the other is like the thing under the common language actually like being secure any other thoughts on that topic curious like what is like you think the property like we should uh like enforce like or like putting like l22 to to be like a compatible with yeah I mean okay so my underlying goal right is that uh I want like I want a world where if my ethereum wallet tells me that I have

coins across L1 and a collection of l2s I want that to be verified with like CL proof so the number is correct without me having to address rpcs so this may be as much as anything a uh a uh around creating standard apis yes and then having a convention that will provide open source software that people can plug into their wallets or other tools y guess this seems like an obvious win especially if really popular wallets integrate it and then that will create the incentive for the l2s to actually conform to the standard because if the popular wallets are wallets are able to be like clients for some chains and not other chains then you know the other chains will you know want to also

be uh you know like client compatible so starting with a standard that chains can you know opt into seems like a really good approach good I think like one one thing for the unchain uh like client it's like the you need to post the state rout like otherwise it's not like like Cent I think for the zik robs it doesn't seems like a big problem because the finality for the the state rot finality for the zik Rob is very short so like you can read very a more like recent State rout but I guess questions like for optimis Drs because you need to wait a long time for the state route to finalize uh on the layer one so how would this onchain uh State like Cent work I think okay so for me actually

it's equally a problem for optimistic and validity rollups and the reason I say that is that like I don't think like having proven access like provable access to the chain should be this like afterthought that that you have to wait even 10 minutes for I think it should be the default standard even for like very uh like rapid um accesses that users do already and even validity rollups right you have uh like unchain data dumps more frequently than you have state routes um you often have pre conf more frequently than you have onchain data deps and like these are all things the verification for which can also be standardized okay I mean maybe uh is a

do you think it's fair to summarize this as like this is a desired goal but this is clearly an earlier stage research topic than the than other things definitely yeah it's like see this is good okay we yeah one I want to added to that it's like a I think like this is a good directions and then we need to think about what are the real impact to the users like what can this enable to users I think yeah I mean I think yeah that's uh like I don't like I to be clear like I don't even think it's necessarily useful to have this uh solved before most rollups are out like stage one and stage two right and I think historically like that's been the reason why up until this year no one has really even

bothered to solve the problem right but now like we have uh stage one rollups and we have Helios actually doing some uh light client work so it's one of those like things that's worth uh like putting in the uh you know the medium-term budget so one one thing that will probably cause us to accelerate this is something that didn't happen yet and you know knock on the with it will not happen soon is scammy rollups yes right with more and more app chains us working very hard to make easier and easier for people to loue the up chains rollups we will we are bound to see rollups that are created just as honey Paws just as a way of kind of getting people assets out and that would be an interesting experiment to see yeah

agree since we're at a pause I would like to make a pitch that we not forget the l3s uh right nowadays about half of the total gas consumption in the ethereum stack is in l3s um and whatever it is we do I hope that we can some of it will just transfer or apply directly to l3s but in some cases the fact that there may be two layers of settlement may affect what we're doing so just a a plea to uh to not forget about the l3s do we have any l4s already or not uh yes I know of at least one wow you know there used to be a company doing SD channels that was called o4 cool so uh maybe taking a quick step

back and going back to what we started off with at the beginning we talk a lot about how yes l2s are ethereum but arguably we don't always do the best job at perhaps uh walking that and and actually treating l2s like first class citizens so I wanted to maybe pose that to vitalic vitalic you initially and see what you think about that and and then yeah open it up yeah I mean I think there's like two levels at which it happens there's like third party dashboards that try to say like position say I versus arbitrum versus optimism and then they I think like create this confusion that you know the difference the distance between ethereum and arbitrum is like the same as the

distance between ethereum and you know Monet or binance smart chain or you know like Bitcoin or the US banking system and uh like that's an outside ethereum thing that I think we should like push to fix but there's the inside ethereum question of uh is for example the corev process like taking L2 needs into into consideration strongly enough I feel like that's not for me to answer actually maybe that's a a good question to everyone which is like what are things that the ethereum core research in Def process could do to do a better job of taking L2 needs into account so so one thing I would mention is first

thank you for the 4844 in blobs this helped a lot this was like the biggest gift we have gotten there so thank you you one thing I can add is food and shouting ship like earlier so that yeah so I think like the now we're seeing the blobs it's at like the some level which like it will increase the price very soon like the with more RS spin up now seems like we are like uh urging like or somewhat like a relative more urg like to having the full tank Shing yeah as finally finality is quite important I think it's important for uh basically the layer one to continue to uh to go ahead I mean we

need enhancements in the evm around for example cryptography there's a lot of things that have been discussed forever that should be happening I believe and because that's how you create differences if the evm does not evolve then basically you need to add features in your own execution layer and then everybody adds different feature and then it to Recon it so I think where the EF canel P up is really into pushing the evm for the execution and the fast finality uh for the consens part so there's some technical things as well as cultural things that this makes me think of um on a technical side you know um

ssz receipts um would be super helpful that allow us to delete a lot of lines of code in our proof um then also faster block times faster block times is always useful for finalizing you know the the data that's published to L1 more quickly um on the cultural side it would be really nice if there was more of a customer um and provider sort of relationship between L1 and L2 um we found that you know when we make suggestions on how to uh modularize gu for example uh the GU team you know

wants to be credibly neutral and not necessarily make um abstractions that allow it that allow us to more easily maintain our Fork whereas there's other uh clients that focus more directly on you know all l1s and l2s as their customers and they want their goal is to make it as easy as possible to integrate and if we were able to reduce the amount of time that all L2 teams needed to spend rebasing on top of gu we would be able to focus more on getting to stage two more quickly um one one question just

probably to be helpful to the room um why not uh give up on gu and instead build on top of say nether mind or reth or some other team that's already more like customer Usery toward you guys yeah that's a great question um it's already starting to happen um I think that you know everyone loves to say rust is the future you know I think go is great um I think that nethermind is also great I think all the clients are great um I think that it's just still so early and as the L2 teams mature they're able to take on more scope and you know own more code bases it this tradeoff between you know

getting to stage one getting to stage two just fighting for survival um versus you know taking on a full multic client approach yeah so so it's there's a huge cost however in foring and having your own version which is the risk of having an Insider doing modifications to the code it's deployed everywhere and then the fraud proof are not detected because everybody's running the same version uh there's as well a huge risk in terms of having a single team uh maintaining a very important piece of software so the fact on the layer one that we have a guest client implenting in golang another one in Java another one in basically every languages including n

for example for for status I think it adds a lot of value in terms of security and yes we can uh be faster by doing Force by doing changes but we as well much less secure so being a little bit slower I think much more secure I think it's quite important I think all these specific asks and specific questions are important and I'll let me plus one those but I also want to get a little bit meta and talk about the governance challenge of how to ensure that there is a really robust conversation between the L1 core developers and the L2 teams um our team includes core developers from arbitrum and from Prism uh you know one of the

leading L1 consensus clients and we found it incredibly valuable to have those conversations between those two teams to really understand deeply the implications of L1 choices for L2 and L2 choices for L1 so I would love to see this sort of model of conversation be exported across the whole ethereum world how to do that not so easy I think um in the very sort of large and high stakes ethereum governance process but but I think a really important goal I think the the cultural challenge is the one that that you mentioned Mark is is quite tricky because you ask what we as L2 want to get from L1 but the general perception I see is that if

you're like an L1 developer you see these l2s just asking and grabbing and like not giving too much back right so the important thing is also for us to to flip this and be like okay what l2s can do to help L1 and you know it's not only technical things it's also cultural thing it's also the US showing that we're actually built on top of ethereum right which sometimes we forget yeah and some of the things that L1 might ask themselves do we want to do this that are difficult to do we might be able to say actually we don't need that so much yeah not much to add the a lot of important things already said but yeah I guess for from us personally is kind of like false block times and kind of like the the cheaper data availability um that would like a big win for us uh I

guess like in general also kind of like yeah to work towards this kind of like Unified chain like all the the work being done on like the formal auditing for like zvm uh and kind like this enrin zvm uh would be like great to have I mean the only thing that I'll add is I think there's an interesting discussion to be had around like um uh again I'll bring in like the the economics here uh which is a reality like um we look at things like if I look at things from like a polygon perspective um we've spent uh enormous amounts of money on ZK technology that benefits um eventually every L2 actually is going to benefit from that um and I think there's a question to be had is

like um where where is that relationship on where like um an L like it's it's I think it's an odd thing to say l2s should push a certain technology that ultimately will end up benefiting everyone but they should incur that cost like holistically like on their own don't get me wrong there's others doing things I'm not I'm not saying otherwise um but it creates uh more economic Distortion again when that actually happens and so the question becomes like at what point in time is it that you know when we know a technology is headed in a certain direction that that it's actually something that that we all should be funding collectively um like I still think like actually there's no thinking we know there's a lot of work

to be done on on ZK Tech um why aren't we funding that collectively I actually think we should be there's one dimension on this uh which I do believe that in the future it will be very important to have uh different provs to validate and update ofup this famous multi-prover thing I do believe that when we will have four different ZK evm we'll be able to move this to the layer one and to prove a state of the layer one with the tech developed by the layer two I totally agree that from a financial point of view there's a huge issue because all this will be available for everybody for free and so yeah what's the incentivization to to do this uh I do

believe there's one however which is we make the ecosystem much bigger by doing this so even if uh our part might be small might be a little bit unclear might be a little bit shaky uh I still think globally we will be much bigger uh much better in this situation than just trying to build a small island somewhere yeah and I would never debate like we should pull resources around one effort that would be like a huge mistake um but pulling resources around like mixed efforts would be a very good idea yeah there are some stuff that actually the EF is doing already which is funding the formal verification the formal verification is highly risky it's highly difficult and anyway it's interesting if it's done by driven by an external team I mean we're ready to contribute and

we're doing it but doing your own thing and doing the verification of it is a strange so that's an easy way where the foundation can already this but can go very far and I think it's very expensive so it's useful if they do it to if they finance it to and yes you again you have a very good point about reality right reality Financial reality of we're all working on open source code which means our mode is one PR submission away right so it's it's very tricky to figure out how to finance this while still maintaining a little bit of the benefits and you know competition so yeah it's not easy but it's crypto so Financial things are crazy anyway so uh open source is great but I mean if

a team goes away uh it can't go anywhere so I think we should understand that the the value of a team is quite important to we it will evolve it will have to be maintained so it's not like oh yes everything is going to be stolen by anyone tomorrow morning we're actually much more comfortable situation than this I believe I mean I will bring up a maybe maybe controversial point but like I think there should be alignment on on like the open source open source nature of what we develop like um I I I think that's like literally the lowest hanging fruit to um all l2s working together um and and working with ethereum is everything should be open sourced

because the moment that's true now we all to some degree are working together regardless of any competition um I don't know that we'd ever reach agreement here that people want to but like my perspective is like we should we should have a lot of social pressure on on things being open sourc across the board amongst delt stupid question who is not fully open source in this room arbitrum has a revenue share license you can do what you want if you share Revenue sorry Ed I didn't realize you are the only one I did not mean to Target you I actually I actually did not know that he was the only one with the PSL license sorry so last question I think before we

turn it over to audience questions the one group that we don't have up here today is is wallets going forward how do we best bring wallets into this interrupt effort uh because obviously critical component here who here in the room is a wallet developer quite a few okay cool um maybe we'll ask you guys some questions in the next 40 minutes too actually do we want do we want to do this right now okay so let's do this right now um let's uh send us down and bring them up yeah well yeah come on know come on get up to the frontu and I see

you yeah just like sit over here anyone else okay um well I mean maybe we'll start off by asking you guys the same question which is what do wallets want out of the ethereum L1 CF process um yeah I think one of the biggest problem is the um cross L2 thing uh for example uh we all know SM wallet is the future of uh ethereum because of uh it's it will be Quantum safe so for users they will need to deploy different uh SM wallet on different chains and uh it's quite annoying and especially to keep the same wallet address uh the same

across different chain and currently we still don't have a share agreement on uh how the uh a chain specific address will be and also for user to recover uh a or change a key across all their rups is very it's very very difficult they have to do it on different chain uh specifically and set up like social recovery Guardians specifically so it create a huge fragmentation on account level yeah so I'm not sure that we will have to do this actually in a perfect world if we can put the state of one rollup into the others then you will be able to send a transaction to a rollup you have never used saying actually I I am this

user on this over rollup and that's how you can verify your signature so this is clearly a little bit rearch it depends mostly on your capacity to update the state to to plug the state of every rollup into every other rollup but I do believe that it should be possible to do this type of stuff and I do agree that if we don't it's going to be incredibly messy but I do believe there are Technical Solutions to the type to these type of problems I mean I'd argue I chain specific addresses have use cases other than smart wallets right like users do want to specify that they want to receive at on a particular L2 or on L1 instead of somewhere else um maybe um any other wallet developers here yeah I'd love to take it uh Eric from fireblocks um so I think first of all an

interesting maybe like where in the truth uh kind of saying out loud things um so we work very closely with pretty much every L2 here they're all Partners we work with them all the time we don't really work very closely with ethereum like that's a different distinction between the two um probably relates to to kind of like uh um setups in the world of ethereum being earlier and kind of more established before but I think that's interesting and that also goes to the governance process right like we've been trying to be more participating but it's definitely it's not an easy process to get to be more participating especially like in just for the people in the room less familiar as an NPC wallet right we're not a smart contract wallet which everybody wants to talk

about whether an NPC wallet um that's obviously just part of what we do but that's kind of like a I think it's a interesting place in the space that's kind of I don't know been acknowledged differently I have other questions as well afterwards but that's just kind of like a statement if anybody wants to talk about it I'm happy to uh Josh are you in touch with uh okay well you will um yeah so I think two questions that are more specific to uh topics you discussed so you talked about onchain configs right and basically which basically would allow a situation where um possibly we can have uh um in time addition of the chain to the user process so if we're talking

about user stories for example Cosmos has like a different way of doing wallets than ethereum in Cosmos the DAP might let you know that this is like a chain they want to interact you with you as a wallet we're not familiar with earlier so it creates a different proc process of interaction I don't know how much of this has been discussed like how user standards like wallet standards need to adapt to a place where you have a lot of chains that have onchain configs and you kind of assume that the user Journey will read onchain config and interact with it and work differently so I think that's an entire topic that needs to be talked about I don't have any answers uh maybe there's better ways than the way Cosmos is doing this but it's definitely something it like we can end up building uh uh the

configs but not building the user interaction flow with those configs and then we basically added another half a year of wallet standards uh conversation to any road map you define so I think that's that's maybe again a topic that uh um uh needs to be addressed and the other topic that I wanted to mentioned and this kind of goes to um all of the l2s and the L2 ecosystem but actually also goes to the entire process of like the roll calls the RPS so um any new chain and again like the l2s here know this any new chain that comes up has a few things they need to take care of and one of the things is integrating with infrastructure tools in the ecosystem wallets being part of that and that

process can look very different depending on which Tech decisions you made so if you're fully evm compatible that might be easier than if you're not fully evm compatible but evm compatible is not a defined term so a lot of people throw out um evm compatible uh it goes well when you marketing but then you go to the wallets and they ask you so which eips do you support which eips you do not support how does that look like so did you do the gas modifications right did you do all those different things uh I think we need to talk more about what it means to be evm compatible I have some broader definition to evm compatibility because now Etha is going to be supporting uh going to be evm

compatible with 7702 before ethereum is that evm compatible or not and they're going to have 7712 before ethereum is that evm compatible or not some or chains already have 7712 so like I think that entire conversation needs to be much more robust we need more terms than just evm compatible uh and we need to understand how we work with this because again there's going to be some new chains coming up and they'll stumble into the same problems and it's going to slow them down okay thank you all right we might go for some question from the public so I'm going to throw this Cube um the ethereum foundation will not be held liable if someone get injured

um there one over there who where oh okay go first go first okay uh just to pick up on the the wallet conversation so Stefan from uh from one balance um we've been working with uh with a few different wallets and apps to help solve the fragmentation problem for them and uh I think my main observation is that there's actually not much governance that's required to uh to solve it if anything um there's these things called the uh kyes so tanip shock did uh Improvement proposals and um those need just more attention and more conversations being had towards them um in particular I think there's sort of a

a shift that's going to help a lot of the wallets um to offer uh a better user EXP experience which is to move away from the current way that we do asset indexing towards actually communicating with uh with apps the spendable balance of the user as opposed to the exact amount of tokens that are within a storage slot on the chain that they're querying um and those kinds of sort of coordinated changes to the uh the Json RPC apis has been historically the sort of hardest thing to coordinate right so you have this standard that was designed in I don't know 2014 for the Json RPC API that's being used for communication between apps and wallets and just any change to that and upgrades to that have

been incredibly slow to to adopt so more attention and focus on those things would be great um and then um yeah hopefully uh with those things we'll be able to to actually universally solve the the fragmentation problem directly at the wallet level without actually having to do anything at the uh at the chain level all right thanks if you can have a direct question for the audience uh for the panelist if you want to come to the Roll Call I also do protocol support and coordination just reach out to me and here you go I speak this one test okay so one thing I wanted to bring up as um yeah from the perspective of uh wallet

providers or wallet uh developers um it's not just always about the highest level of security but uh we care lot about latency like how good is the user experience and often we want to have a user experience that has like is below this two level uh two second level latency barrier and so for some interactions we don't actually need like for example gas sponsorship cross chain gas sponsorship we don't need the highest level of security for chain interoperability but we are actually fine with um with some optimistic uh protocol potentially there and uh also would be happy potentially potentially to rely on some standards and intermediate actors that are willing to

take a bit of uh risk in terms of that optimistic functionality so yeah the main thing I want to bring up is not always we don't always need the highest level of security something sometimes it's also worthwhile to have something in the Middle where we have some optimistic inability which is um yeah where maybe intermediate actors are taking some risk and um which gives a better latency for the user experience but that's not a question really oh well sometimes yeah I just want to agree with this it's important to be able to think in these terms sometimes you need a party to take risk but sometimes you

just need a party to out of band or offchain verify something that can be verified offchain but not onchain right and so there's not even necessarily risk associated sometimes it's just a part A protocol that involves some onchain plus some offchain actor who Bears the consequences if what they attest to turns out to be wrong yeah and the really important flip side of this I think is that going back to the original goal right we want the ethereum L1 plus L2 Universe to have the same properties that we would demand had we done execution sharding and one of those properties would be that doing things from one Shard to another Shard should not require like specifying and trusting a specific centralized actor right and

so it's fine if you have risk but it's not fine if you have to like specify you're doing your sent through like XY z. info.org right yeah exactly I think it's very tempting to do a lot of optimization saying for Vis case I can goow with a lower level of security for this one I can be do a little bit of this and then we said to the user do your own research uh I think it's a dangerous situation and we should spend quite a lot of time to be all the time a little bit the same level of Security even if it's maybe too much in many cases from a user point of view you don't have to think about the specificities and to understand the variabilities of everything so I think if we really want to to be mainstream we

should say there is one level of security you don't have to to write a white paper before knowing that should be sending a transaction basically but you don't necessarily need to have like one level of security for that like I I do agree with like this base level of security that we should be we should be targeting like we we want to you know avoid scam chains right like if we can do that but beyond that like they different chains should have different properties like we we've accepted right like that we can have full rollups and we can have validium like we've we've accepted that these tradeoffs are are are okay um and they make sense given the variety of things that we want to bring on chain I think the one thing that and and so that brings up the question should we expect users to

understand to some minimal degree um the the the risk or the security uh properties of a chain that they are using um and and I think I think the answer is like we want to remove like the lowest level of security that is just so high risk that like we should we should find a way to protect users from that but beyond that I think we should accept some amount of risk but what I think we should be targeting um and and this is actually interesting because this goes to Ed's point about um kind of like diversity and where we uh as l2s can almost be like better off than than than l1's which is like um if you we want to be able to protect like cross-chain

transactions and like going from a chain that you trust to a chain like and executing a transaction on a chain that you don't trust you want to be able to make sure that like you're not rugged by by that chain and like we need to ensure that that's actually the case but while living in a world where that chain can operate actually with much lower security much lower cost than than other chains and so I think there's a there's a world in which you can actually have like these different security properties while providing secur guar to like only the chain that says this is the one that I know that I'm actually on I mean users need help with this right there's a ton of chains tons of applications different counterparties all with different levels of risk yeah and it doesn't make sense

to just expect the users to figure that out right and this is a problem that's existed all across all of the layers of the internet even before we were around uh and when it works what works is where the user is relying on some provider like a wallet for example to just uh figure things out for them right to set a standard maybe the user says high medium low security maybe the wallet knows this is a low value transaction but users ultimately rely on various providers to make decisions for them right you rely on your browser every day to try to keep you from going to attack uh to sites that will attack you right and we don't we don't think about that

because it's built into the user experience that that level of safety and I think we need to ultimately that needs to happen here and Walts will play a big role in that I think it's a little bit too easy to push it to wallets and as well because wallets will have uh a strong incentivization or strong strong pressure to integrate with as many options as possible because users will be saying oh I don't want to use this wallet because it doesn't have this upch that was popped up yesterday uh so it's it's I mean it's good for us yes but for the wallets it's a little bit complicated I believe and ultimately it's bad for the user yeah I want to maybe post a question Jun since you're in the front you get this one again so imagine a world where we standardize not just chain specific addresses but also

chain specific payment requests so the idea that you have an app that can basically demand like hey I want one eth on this chain and adding chains is permissionless so case one you have an app which demands that you deposit one eth onto arbitrum case two you have an app that demands that you deposit one eth onto Tron with a config where there's a bridge between Tron and ethereum that is a fully trusted Bridge with the key controlled by Justin Sun um in this future how would you expect like so like how would you wish Soul wallet to show um arbitrum and that Tron with the Justin sunbridge differently to users is the Mike okay amazing um well I

think it it depends uh now now there's we use a lot of different Bridges and a lot of time we just trust those bridges so um so I think it really depends on the um scenario or use case if it's a low uh value transaction maybe like lower than one uh one e then probably we could treat them the same things uh the result is not that significant but once it go uh go above certain threshold we could give give us some give users some warning or education to tell them that like that this is our suggestion yeah what would the warning look like is it

like like would you like color the chain like red instead of green would there be an extra click through yes it's like some risk warning okay yeah like most of uh we do on the traditional web to fintech makes sense I think one way to think about is maybe we should go and look at the user experience of say using stripe or using a traditional bank and aim for the user having to think at most the same amount and ideally the user can think less you know then we build a better user experience than the existing system I do think that will be difficult but I think

that's a good goal I wouldn't want to go too far down the road though to emulating Banks because as we may know Banks sometimes have a habit of um not wanting to interact with completely reputable organizations I'll see like the so if we can look at the HTTP to https transition that like if like some like everyone is pushing for that standard um and then also like the cost to user experience is pretty negligible then everyone will by default to to using like https now like I think if you're visiting a website that's not https like you're thinking okay this website is not such good so I think like the more important thing is like if we can work something like Technical Solutions to to push that as a

standard and then like also with negligible like impact to the user experience that would be I think something that we can have all of users can adopt by default the question is what what do you want to push as a standard with more and more app chains louing it would be almost impossible for you to say which app chain you trust or not trust right The Operators of many of these app chains depending on the system might be able to do arbitrary things your funds right yeah I think like a fle you can like have like a a a certificate like okay this R up is like a this app chain first like I think like all of the stacks like we need to push up the standard or like you need to like by default choosing some minimum security features like you when you launch a new

chains and then like has some like L2 beat or some some like C party like to say okay this chain has certain security features that then and then user will say like I interact with the chain with more trust like I don't need to worry too much but now I feel without this label then user were thinking okay twice about should I do a large amount of transaction on this chain should I deposit a lot of things on this chain I think this could be like one way we can push forward we are putting a lot of on L2 beat and honestly they were doing amazing job yeah until now so there are like this hidden hidden hero in the background actually keeping us honest but yeah the question is how much they will be able to scale with potentially hundreds of you know up

chains starting that's it that's speaking of uh Collective funding as we were talking 30 years ago you know would you guys be willing to put more funding toward either L2 be itself or competitors yes easy okay done deal okay we should all just agree to the amount you've probably all received something you okay you all want to agree to 500k is that the amount that's what they want we should just agree to that everyone can give 500k no problem I think I'm serious so be good no nobody wants to okay I mean we need like they're doing a great job like and and we should recognize that and we should fund them like I think it's really important I'm going to push again on this stuff around

you mentioned validum for example and okay it's an option you can put the data ability of chain and that's good but I really believe that we should try to make full data avability on eum as a default and it means saying to the eum foundation hey guys it's your job to make uh sharding data sharding and full sharding happening as soon as possible so we're not in a very painful situation when we have to explain to our users actually it will be good to split the security in two for very critical you will go eum datability and then you will have something else for over so I think it's why it's important to to commit to a maximum to maximum security because then we can ask the right thing to the to the layer one but remember that this

is making it a little bit harder for all the l3e l4s and future l5s right because suddenly all this data would have to travel all the way to ethereum right which in some cases it does yeah but now it would have to you know well so in when it comes to security I think there are also things we can do in terms of if not standards at least best practices again we can learn from what you know what's happened in the uh Internet Security World there are some security properties that are easy to test do you you does a site support https or not others not so much but there's been this effort to develop best practices sometimes written down um and uh that's really useful it provides a kind of checklist um that

people can apply um and it makes it easier for the L2 beats of that world to do their job when it's sort of understood that of course you should do this list of things um it creates a kind of questionnaire that makes that easier and we might also get together and try to figure out what are best practices for operating a uh an app chain so we're at about 20 minutes left do we want to save time for a few more questions here we all feel good cool okay um first of all plus one to Mark's comment on like agreeing to fund l2b I think l2b is extremely important for this whole ecosystem um secondly I

wanted to kind of ask a question to italic when you said earlier this year like you're not going to talk about any role up that's not a stage one roll up uh after this year I think that was very effective getting everyone to be like oh we have to actually take this seriously and upgrade their systems um so you have a lot of ability to kind of get folks to align and we saw it earlier with founder mode balic getting crushing and address or like change specific addresses and so on like just right now aligned are there any other things you think like we can use this time right now to say like if we all got this thing done by like this time frame that would be like something you think we need actually I mean we we Technic we haven't gone through chain specific addresses

enough I mean do we have broad agreement around the idea that there should be an address that can con both the like 20 identifier within the chain and the identif of the chain and that's a thing that you should be able to just like put into a wallet and and that would get processed as a send on the high level maybe the devil's in the details and the concrete detail that we're talking about is for example would that thing be an a human readable ens or would it be some chain ID mhm would this thing be just done on the wallets or do we actually want to move it forward into some interrupt standard so that it's like embedded in there the

the problem and by the way we have a breakout session about some of these things later today where we're going to dive deeper I think from my perspective yes we should have something but this something you know requires a bunch of discussions and you know to make sure that we nail it that we don't have to change it you know six months down the line okay do you agree that we should have something yeah and also something that we can actually use in the evm would also be great um because if if you actually want to have like composability then having to have like the ability kind like specify an address that points to a different chain would also be like very helpful okay so we want both human readable chain um identifiers and we also want a standard for in evm chain identifiers I would think so yep okay

yep agree this is a useful thing to do we want to make sure that you can also name l3s agree yeah definitely a big fan of this um I think in the most simple form uh the safe app already supports this right and that has been super useful for me when interacting with safes um there's definitely more complicated ways to do it but um I'm in favor of just doing something simple safe is already doing something we could adopt that and then we could you know continue to iterate on the design yes so okay y great MH yeah I think like it's in general it's a good idea there's like some more like nuan

question questions to ask about for example like where is the trust list place you can register all of the this chain IDs like that which you can put it otherwise you can think of like people like make have some scammy things like trying to game the users to do that uh and then second question is probably more tricky is like if there's non evm compatible robs like if the chain derivation like the address derivation is the different how would they like deal with that I think yeah this is like I think some questions we may like need to continue discuss on on on that this would be a great ux feature because users will finally stop getting this warning of please make sure you select the right chain and it's all on you and then your funds are locked forever so um okay would you be okay with uh if if

this was the decision um ERC 3770 as is but you replace the current prefix which is de facto offchain registry with like some kind of ens based onchain thing I think that would be great okay and I remember talking to the ZK sync team they and um they were thinking of it in terms of a URL and I think that this could be a powerful feature because um it could be kind of similar to like the blink product that salana has where you can just encode a call or like a transaction um directly in a URL and then you can just stick that hyperlink in a website and click it and then start interacting with an app okay so that so that sounds like

everyone agrees on the principle and everyone agrees on the need to have some more breakouts to figure out the optimal version wow we''re going through eips really quickly yeah yeah list got 20 minutes left technically they ERC is and I think some of them can't decide if their ercs or rips but that's fine but but but still that's good all right I want to make sure we get some questions in the back so if you if anyone has any questions please raise your hand and we'll throw this over um one look over here sure maybe uh token back to the uh SC to hearken back to the scam chain scam app problem I definitely agree that

it's maybe too much to put on the individual wallets and it may be a little bit too difficult for something like L2 beads to scale to all the different you know possibilities in real time I wonder if there isn't room for uh standardizing some sort of way to aggregate prediction markets to solve this problem interesting I mean I guess my instinct is that's like out of scope for this like this style of low-level technical discussion but it's also a really cool thing that should exist and like when wallets I figure out start like showing users like some kind of warning based on reputation metrics if one exists that's good you know you should point to it um the and any wallet provider would

be willing to use a prediction Market as as a source of information about whether the chain is like you know green or yellow or red I see Lucas from safe he wants what is it that you're predicting in this Mar um yeah thing you're predicting I mean okay so my definition of a layer two being safe is uh if you have an asset that is inside of an uh L2 then you as a user can convert that into assets on the underlying l one so you'd predict whether the chain can pass some test like this yes you predict you predict whether or not an incident takes place that violates this rule got it hi my name is n Nathan from starware

uh a quick question about non evm uh l2s in general just how do you see them as part of this interrupt um um effort in general and how much input or collaboration you expect I think I'm speaking on my behalf we would love to take part in this uh and and make it more flexible and more diverse ecosystem but it's non-trivial at all when all the discussion assumes at some point some EVMS um yeah good question um would as would starnet be willing to support a standard that does cross-chain messaging and uh support that standard even while understanding that like the thing

sending and receiving messages is not going to be an evm contract oh uh I think the main question there would be what kind of security assumptions it would take so it would be just a ZK question I don't think it would be um stocket chiro stack question right and I think uh in this case the uh I mean the way that this would be practically implemented right is a cross transcend is basically something happens on one L or two and then you make a Merkel proof from L1 state to that layer two um and then you take that Merkel proof or you take a proof of it and then push it into the uh destination layer to and it gets verified and the security assumption is basically like

whatever like whether or not you trust the uh the source way or to yeah it's a bit of details but the finality of some of the l2s is not like I know that this is the current state is being propagated on this L2 but it's not final until it reach on okay so in this case I'm let's say I'm assum let's say we're talking about the most conservative version of cross chain messaging so this is like the thing that you would use to like say make nfts that can be moved between chains and so like if it takes a 7even day delay that's fine yeah so I'm sure we'll we'll be all for it and uh okay yeah yeah I mean I think personally I uh like I strongly endorse the principle that l2s and L you know l3s L integers and we can go into

like higher like L of or Mega cardinalities if we want but we should be able to uh in um support interoperability standards that do not require evm compatibility and at the same time be nonm thank you hey do you hear me uh Hey guys uh Hubbert fromb here so first of all thank you for all of the nice words out there and I just wanted to let know everybody that I have a demo with me called L Tobit inside and uh basically we already thought about presenting the risks of

you know uh interoperability uh to the users and if anybody wants I can show it to them uh and we are thinking about making the API public so you can integrate it either to your wallet or your you know uh or anything else right and I just want to make sure that this risk topic is not just thrown again on the wallet providers because when I talk with a lot of people during Devcon uh the guys from uh wallets are telling me that oh the guys from the chain will should take care of the risk the guys from chain tell me that the guys from inter op BT protocol should take care of that and the and the last ones are telling that the other two should do it so I just want to uh also like during this forum

make sure that you know we'll tackle that problem and agree how it should be you know how we should proceed right about that concrete topic yeah I mean we can look at how this works on in the in the web in the web to uh there the browsers present to the user These Warnings but the browsers are not the ones deciding on the risk or compiling lists of the risky sites there is a kind of L2 beat for that which um actually provides a feed of um of sort of rating to the browsers which they then do with what they will um it's really important to have that body which is able to in uh in a neutral incredible way uh apply the

criteria uh hello Shahar from metal Labs you can see um yeah hey guys love the panel uh quick question vitalic there's a lot of um would you do this and yes and would you do that and maybe and let's do a workshop what's the ideal situation moving forward as far as you can see how we collaborate and how we actually make it happen I mean like I think it would be good if for each of the things that people have said either yes um or yes on the principle but we needs to work on it there's an active group and that group should include contributors from I think both the L2 side and the wallet side

that and then very quickly move toward having an ERC or an rip that actually gets published in a presentable form and then we like actually keep uh talking about it and uh at some point through like one of these online forums actually uh formally adopt things as standards and also like uh you know like may turn these in-person workshops into something that happens on a regular schedule in the same way that ethereum cin interrupts to follow up would you be willing to make it happen would I um would I be willing to do what part I mean I def participate in writing the the ERC is absolutely

come to Future interops absolutely cool thank you I had a follow-up question uh Hester of metamask uh product manager so please bear with me uh I had a follow-up question on the uh chain specific addresses uh because I heard ens uh registration as kind of part of that conversation um would we be able to ensure that it's still compatible with other chains uh at least for for metamask it's important that we have cross chain compatibility of address uh detection as well yeah and so the way that um actually there's a very pragmatic reason why even within ethereum that question needs to be

resolved anyway which is that we have to support test Nets right and the way that I think this has been thought about so far is basically you have e and uh there is a kind of implied offchain registry which is much smaller where e is understood to be kind of the like both referred to the ethereum L1 and specifically ens as a root registry and uh like we would also have dot like doia which would be a separate like root ens registry that would live on the sapoia chain and uh in principle like binance smart chain and other groups and whoever else would be able to spin up one of their own so this is like one natural

option for how that can be uh extended and then if they don't have uh that registry then like in principle there's an there's like an option to have a like a like put throw a chain ID in there in there instead as well so I think uh like the the standards are definitely being designed I think in such a way that like while this group takes uh only takes responsibility for making sure everything is compatible for ethereum but it's still like leaves space for other ecosystems to fit in in like in a very parallel standard got it thank you I uh have one uh unrelated question like clients what would be the minimal that

needs to get synced because we would want that to work on mobile without draining a battery or data um have you uh actually I'm curious has metamask looked at integrating he iOS I mean even even for the1 not to my knowledge doesn't mean it hasn't happened okay um so Helios right basically know sync committee based light client so you get a real time view view of the beacon chain and uh it's very light in terms of resources I think it's like a kilobyte a slot plus like 50 kilobytes to renew the commit or something like that right and uh for L uh for l2s basically I mean the way that you would read the state of an L2 is

like using the L1 and using ideally an L2 config you would be able to get the information needed to like ask some other network what is the state rout of an L2 and then grab the chain and uh these are things that are currently being done also by the kilios team actually they have I think for optimism and for arbitrum this right some like like basically custom written code and this is something that like you would be able to just add and everything I understand about it is that it is very light on resources okay awesome thank you um hi uh this is Francisco uh we hear a lot about synchronous

composability nowadays and I feel like in this panel it has hasn't come up at all so I just wanted to double check do you guys see that as something that's uh valuable that we should have or more of a distraction Maybe I think it's very valuable it's something that we are working towards uh so yeah I think it's it's great to at least have the option to to be able to do it especially if you want to have like liquidity on the L one and keep it there um so yeah I think there's like different opinions want it like is like scalable hour or not uh but I think having at least the opportunity to do it is is a very valuable thing to do yeah it seems today more in the realm of research than in something where we'd want to write and lock in a standard

I think that we can grow a ton with asynchronous composability I think that the bottleneck to growth is with user experience and not with crazy protocol features there might be a future where synchronous composability is really really useful and um I think right now it's a distraction to think about it I think that we need to as a community really focus on a simple goal that can be communicated clearly and align everyone towards accomplishing that goal what I think that goal should be is asynchronous composability

and basically saying that it's possible to send an asset from one chain ecosystem to another chain ecosystem reliably within did you say was it three slots yes I think the synchronized composability is something definitely good like the for the user experience but like whether it's technical feasible at the moment or like what other implication of having the synchronous composability is a question like we need to ask for example does it really require a centralized share sequencer like is that something that we want to have to making like the layer to become more centralized like that something

like we have uh as like a a prerequisite to to have that uh such synchronous comparability or not I think yeah we need to talk about more like on a technical details about whether that's feedable or not and this will be also quite limiting for more diverse l2s right because some of them will be very hard to actually create a synchronous connection especially if they have different different VMS with different cancellation patterns whatnot so yeah I think as well targeting very simple things like just sending a sets to another sh is uh is something absolutely possible uh so it's without any impact asynchronous comp composability is more

complicated because it breaks the fact that uh when you're executing a smart contract no Fe changes so I do believe that if we do in sychronous SCS between chain there will be a lot of side effects and new Poss acts for smart contracts and synchronous composability will be great in this regard but it's research project and uh it's going to take years uh maybe more yeah and I think like my view is that for the short and medium term synchronous compossibility is like C A a domain for layer to like differentiation and competition and I think that's uh like fully compatible with advancing all of the standards we talked about today yeah so I have to run off to another meeting

unfortunately but uh you guys are free to continue here or not may all right I have a last question for you so I'm coordinator in protocol support at datm foundation so there has been a lot of coordination question today you can guess my job is not easy every day so I'm going to try to um use that moment to get one more commitment for from you guys could you commit would you commit to come to every roll call every breakout that is interesting for

you at least send one person or if you don't send a message to explain why you couldn't make it this uh the world call is every two week and the breakouts can be like every week or so for a short period of time yeah we can commit to that yeah no problem don't have a choice I think so I commit sure let's uh let's work towards making roll call be super product focused so that we're making sure we're solving problems for users yes yeah we can send someone also appeal to uh to focus on uh on issues that are common across our

sector only if you can say this will be a productive time it will be a productive roll call all right under this condition sure yeah yeah we should make more an effort uh that's for sure thanks a lot guys awesome thank you very much to our panels think we can end there so everyone thank you for coming today um this was the I would say opening ceremony um from now on we are going to move into a very short break it's about 30 minutes uh when you go out here you can go to your right and

there's a whole chill out area over there where you can go there's food and beverage drinks whatever you want so it's going to be a short 30 minute break and then we're going to move into the breakout sessions there are maps around the area with schedule so you can you can um scan the schedule and you can see which breakout area or breakout topic you want to attend and again thank you for coming I hope this is a very productive day for all of you right all right good thank you thanks [Music]