L2 Interop Working Group #19

Transcript

All right, I think we can get started. Welcome to the L2 interop working group. Uh, this is call number 19 in the series and it is issue 1899 in the PM repo for anyone watching the recording. Cool. Uh, we can kick things off. I've dropped the agenda in the chat also in the Telegram group. Um, the agenda has shifted a little bit. We will start off with an update on the onchain registry for chain ids using oneth. Um we have the unruggable team and Thomas whenever you are ready.

>> Perfect. Thank you. Um I've just request screen sharing if that's possible. >> Yeah, try one more time now. Good. Um, okay. Perfect. Is Is that working? Can everyone see that? >> Perfect. >> Perfect. Um, yeah, I'm Tom from uh Unraggable. were ENS service providers and we've been working with the team uh at Wonderland and Josh and uh Barnaby at the EF on this um chain registry resolver and the associated specifications um 7930 for the binary interoperable address and

7828 for a more human readable form. This update is uh I'll keep it brief. Um, we have momentum at the moment. Things are moving forward. There's been a lot of conversations going on behind the scenes and finally it looks like this is all coming together. Um, so the the chain resolver code is complete and finalized. I can share a link to that on the chat. I'll I'll do that afterwards. Um, if I change my tabs, I'm assuming that people can see the changes as well.

um the executable proposal uh to register the on.eth ENS name and to set the resolver to the onchain registry resolver is in motion. So I'm hoping that within the next 24 hours or so we will uh have that up for an executable proposal. The timelines for those are uh seven days essentially and uh there has been um complete support from the ENS community. So I don't anticipate there being any issues in terms of getting that passed. I will additionally share that link such that if anyone wants to

um join the ENS forum and share their insights and opinions uh please please do so. There is also um a companion associated post on the relative uh the related specs on ETH magicians. Again I will get that link and share that if anyone wants to comment there. Uh in addition to that we've been kind of to get to this point we have set up uh an experimental registry resolver on mainnet on cid.e ETH and we've been playing around with that and testing that that is fully functional and we the few issues that we did encounter have

obviously been fixed and now everything um is in uh a good state hence why we're moving this forward to the productionized setup on the on uh second level domain. So uh if people want to just have a play around with the the fun little additional user interface that we set up, you can visit cid.e.limmo and uh you can have a play. uh that pulls data from that experimental registry and displays it in line and that is simply a friendly user interface to allow people to to visualize what is

contained within that registry. [snorts] In practice, we anticipate that people will be using the registry uh for chain specific address resolution. So that's uh example.e ETH at base uh whereby that base label gets resolved to uh 7930 interoperable address which is this binary address here and then you can utilize that um to uh resolve the ENS name which is the the first portion of that address because it's been queried uh a few times some points of note in

terms of kind of how we architected that registry. There will also be aliases. So if there are uh multiple labels uh by which a chain is represented, OP and optimism for example, they will all point to the same canonical underlying metadata. We uh are still in the process and conversing about exactly the process behind how we're going to allocate these names but uh the kind of anticipated plan is a multisig made up of industry participants um probably people from the ES people from ENS and if you are interested we're open to kind of having

that conversation and making sure that kind of everyone's needs are met in in that regard because I appreciate that if people are relying on this for their chain metadata, it needs to be appropriately secured. Um, I imagine that Orca from [snorts] Wonderland is on the call. Um, we've been working closely with them and they've been doing fantastic work as well. I think he's talking about open intents after this. Um, but I'll briefly mention uh is interopaddress.com which is a website that they've set up that looks super cool and uh additionally provides a lot of kind of context and insight into how this works.

Um, but this animation at the top vitalic at followed by the chain label which will resolve the metadata from that chain registry is particularly cool to me. And um Orca recently told me that their SDK which is linked from here now has experimental support for that experimental chain registry. So if you want to kind of begin integrating this into your products, you can now kind of play uh around with that experimental registry by setting a flag and uh in 7 days or so uh we'll be in a position to um add the functionality to to use the

real productionized uh onchain registry. another question that I've been asked, the onchain registry is uh a registry for all metadata related to um a blockchain. The intention is that ownership would be handed over to control the metadata associated with a particular chain identifier to uh the the multi-IG or equivalent um associated with that chain operator. Again, we're working on defining the process to make sure that we actually do hand off that ownership to the correct people and

teams. But ultimately as well as the 7930 identifier which we're pushing as um [snorts] uh hopefully the future uh way of kind of representing chain specific addresses. Uh this registry resolver will be able to be utilized to share any and all metadata associated with uh a chain. So this is the experimental registry which just has some example data to demonstrate that. Um that was uh quite quick. Um I'm happy to answer any questions and I will uh share any links um that I just outlined

on the chat. >> Thanks so much. Any questions for Tom? Super clear. No questions. >> Um I I guess I have a question. So Thomas, I saw the the interop address.com Wonderland site and think it's really interesting. I like that little demo showing you you could put jamesback and put chainbas and then it shows you what the interoperable name format is.

help me just understand next steps for this to be something that everyday Ethereum users can take advantage of. Is it required that people, you know, wallet companies implement the interop SDK? Is this something that the Ethereum Foundation Josh is like really pushing as a wallet standard? Um, often times ENS is only as powerful as its implementation and not all wallets are implementing ENS the same way. So I'm I'm curious kind of like how this goes from research to idea to now executable to then actually useful for people.

>> Yeah, absolutely. Um, I'm sure that Josh and Orca can potentially add context from their side, but in terms of my side and obviously your side um coming from ENS, uh I think ultimately with specification development and the the um tooling that supports those specifications. Yeah, getting uh a specification complete and signed off and merged in is is the first step of the puzzle. and then um getting people to want to use it is the next stage. And in many respects, that's why kind of this has taken longer than we originally anticipated because

um ourselves and the Wonderland team and uh the team at the EF have been debating and discussing exactly how we can kind of format these uh specs so they're accessible whilst also being useful to um the widest audience possible. Ultimately, we think that we've uh we've got there. Um and we've we've been conversing with uh the people that will be utilizing well this and if if there's anyone considering utilizing this, we're happy to kind of converse with them and discuss implementation.

But at the end of the day, yeah, it does come down to uh wallet teams and DAP teams um implementing these specifications and taking advantage of the uh the onchain registry resolver. Um and in that regard, I spent the past week uh writing up kind of some fairly complete and thorough documentation for all of its functionality. And we're hopeful that kind of by providing um really in-depth specifications and documentation and additionally supporting with integrations uh hopefully kind of the the pitch uh sells itself and people will want to uh

and then it will just grow naturally. We're hoping. >> Yeah. Prem. >> Yes. I just wanted to uh say uh it was good to see you last week, Josh. Uh we were in uh in Malaysia together at the L2 Feb 2 event and I was able to have a conversation um or a presentation of 7930 uh 7828 and the onchain registry and I'd generally say that the the feedback was very positive. Um I think uh from ZK sync they said uh you know just ship and uh they were they were very supportive and uh there were some other L2s there as well that that um were supportive. So

I'd say that the feedback is good and and the the idea at this point that I've uh uh talked with Josh about is the idea that we just need to ship and we have a kind of a short um window I think to to get the most bang for our buck in in getting the news out. So, uh, if we could all coordinate, work together, I think it would be great to, uh, ship something and see how far this project, uh, can go and hopefully it can be successful if we all work together. >> Awesome. Cool. And anyone uh, feel free to I think um, Thomas and Prem and myself would love to hear from more

people. Um, so yes, please please reach out. Cool. Let's uh keep going then. Thank you. Yeah, thank you, Thomas. Next up on the agenda, we have uh Palace here to share some work they have underway on 7702 combining 772 and 5792 to execute multi-step crosschain actions. Hey guys. Um, I'll request screen share here.

Okay, there you go. All right. So, um, we have a light paper and if anyone is curious to dive into more of the technicals here, um, feel free to reach out to me on Telegram. You can scroll up a bit. I'm in the interup group. Um but I'll just briefly present the um deck to give you an overview of what we've been working on here at Effortless. Uh just confirming everyone can see my screen still. >> Yeah, we can.

>> Okay. So what we're looking to tackle is um the high friction UX for cross L2 um L1 to L2 user experience for retail users specifically for new users who are not as familiar um and haven't been as involved with crypto over the years. Um, so we had an example flow um, someone searching for how to bridge to base on Google and how they would actually get there. And we're looking to reduce that friction drastically so that while maintaining self-custody

and trustlessness so that decentralized self-custody can compete on UX with uh the centralized solutions that are coming out for crosschain experience for retail users. Um the way that we do this um and and here you can see that um we allow complex uh multi-step actions and uh with single click approvals. Um that is the goal here and um the way we do that is leveraging 7702 and then also um 5792

um to make it userfriendly to allow existing wallets um also applications that want to build on top of this standard um or any crosschain aggregators to be able to provide an experience to users. with their existing EOA wallets that users currently use. Um that is more in the experience that centralized um providers are now providing retail users which are starting to see adoption.

Um so we're using the two EIPs to allow um these users to execute complex multi-step actions. Um, so you can bridge to an L2 and then do a swap or bridge to an L2, do a swap and then put it into a staking um contract or a lending contract um all in a single transaction. We ourselves will be building a product on top of this for retail in order to leverage the technology, but we also wanted to provide it as basically an open standard that um is separate from the monetized

product that anyone can use to improve the decentralized trustless self-custody experience. Um the architecture we're using in addition to EIP 7702 and 59 5792 is we are going to have an L2 for purely recordkeeping. So the L2 that we are going to have is not intended to have anything on it um outside of recordkeeping of crosschain chain transactions so that there is a proof in one place um outside of the various chains involved or L2s involved

um and then we believe this is going to support um various applications on top of it. Uh various use cases on top of it. We will be building on top of it ourselves. Um but yeah, that's that's the introduction. Um we're we are going to be using solvers to optimize certain parts of transactions and using array of intents for other parts of transactions. Um, we've been working with uh, Bonarbe and also spoke with Alex a bit on this and um, yeah, we we'll be sourcing feedback as we um, build this out. Um, we're currently working on the

architecture to make sure it makes the most sense in terms of how we are um, creating the the logic for building out these transactions. Um but we want to you know create an experience where retail users can uh express in layman terms what they want um potentially in in our product to an AI agent and that AI agent will create a complex transaction for them where they need to uh usually do one signature and then are able to execute that transaction themselves from their self-custody wallet rather than transferring their

funds to a third party smart wallet or a third party AI agent where the agent is managing their money. Um, in this solution, they will completely maintain self-custody. Um, yeah, so that's that's what we're working on. Um, if you're interested in learning more, feel free to reach out. Um, we would love to, you know, walk you through, uh, what we're building more in depth and get feedback and, um, see if this makes the most sense for who we're building it for. Our plans is is not to make this protocol competitive with any existing L2, any existing wallets or applications. Um so

that it's a value ad to the ecosystem that you know other other applications can build on top of um wallets can potentially um integrate for their users etc. Um and happy to uh answer any questions if anyone has any. Uh here any questions for Palace? >> I added one in the chat. I asked about um will the L2 act like as a as a MI poolool?

>> Um so the L2 will act purely for uh recordkeeping. So we have uh a atomic intent protocol. um which is where the solvers were will bid for a transaction and um try to provide the most efficient path to solving the transaction. Um so that would be uh separate from VL2 which is purely for um you know recordeping the various transactions the confirmations as they happen on the various chains.

So I I still don't quite understand. So is the L2 kind of used for like the settlement of the intents? Uh the L2 is used as a place where all of the various confirmations of transactions on the various L2s is um like kept so that um you know because there's going to be the confirmations of a transaction on Ethereum on base or whatever L2 and those are all in different places and so the L2 seek seeks to be a place um to represent all of those so that it it you know tracks

the finality across the various chains and so um that's that's what in one place you know >> I see so it's like you're kind of like mirroring the transactions on all of these other L2s to the effortless L2. >> Yes. >> Yeah. So it's a a pretty simple purpose chain. It's it's purely for record keeping. Yeah. >> Thank you guys for letting me present >> Awesome. Yeah, thank you Palace for coming on.

Cool. And anyone Yeah, reach out on Telegram to Palace. Cool. Up next, we have a quick round of updates on the open intense framework from Orca and the Wonderland team. Orca, hello. Um, yeah, let me share firstly. Can you see this guy? Yes. [clears throat] Perfect. Um, so let me see this.

Perfect. Um, so quick update I guess on the if um I guess it goes without saying. Um, the is collective work from many many teams. Um, I think there are lots here. I guess I'd specifically call out Open Zeppelin, LiFi um, and and and unis swap. uh um for some of this uh recent work as well as of course the um EF but lots of people have been involved and I'm mainly just presenting um uh the collective effort. That being said, the open intents framework I will um quick overview. So it's a full stack framework for intentbased crosschain interop focused obviously on L2s. Um the idea is to bring intense to all of Ethereum as a

best-in-class technology stack and an open source public good. Um what does that actually mean? It means making really simple to set up um set up intents on a chain um and to um run ongoing operations. We want to avoid vendor lockin um want to have this open um open interfaces where folks aren't having to pick one particular vendor. Um over want to reduce fragmentation and deepen liquidity um and while giving people modular settlement options uh and in particular we want to highlight trust minimized options as well. So um there's quite a lot going on there. Um and I guess want to go into what that means in practice and I guess it's a mixture between sort of standards and specifications and useful software. Um

so just to orient and this isn't a description of every type of OAF flow but it's certainly indicative. Uh you start on the left with a user they'll request a quote. Uh those quotes will go to solvers who are returning quotes. The best quote will be selected. Um that's intent will be submitted. Um and then sol the solver will fill that quote. uh and then they'll prove that they that that they've done what they were required to do. That proof will be validated. The assets will be released and that essentially is the full sort of life cycle of a of an intent. Um from a user perspective, it's quite interesting. Obviously, they're mostly just interested in submitting their intent and then getting their output assets. Um but there's obviously all this other stuff that happens under the hood that um lots of people here will be

aware of. Um so I thought it' be interesting just to break down the different parts and progress across this um flow. So uh starting with I guess with the RC7683 um so this is an interface a standardized interface for crosschain trade execution systems. Um and people will be familiar I guess with the standardized event um which was initially defined um and uh people may not be aware of the um recent uh or actually um quite ongoing effort to essentially revisit this standard to move away from um standardized events. Um and you can look into the details of why that wasn't the best fit to um standardize on onchain resolvers. Um and so uh this essentially takes a standard which caught uh the popular imagination

or collective imagination quite a lot. Um but which has se hasn't hasn't gained the traction that we might have hoped. Um so I'd encourage people to review the youth magicians post and provide feedback um and and engage with that because we think that it's a new pattern. This resolverbased pattern is a great way um for lots of protocols to be supported in a way that the event-based approach uh didn't uh manage to accomplish. So that's essentially the representation um part of the flow. Um we've then got this big chunk over here which is the OIF contracts. So this is an open source repository. So these are modular smart contracts for intent settlement consisting of settlers um and oracles essentially um managing all of this part which says okay was the intent filled

did they do what they said they were going to do um and repaying the solvers um and so these contracts have been audited and and they're ready for use this worked on by opens up and through a large part last year um and these are largely good to go there are still um opportunities to add additional types of oracles and um and and and there's still some uh iteration in terms of making these support um more like essentially more things maybe multiple inputs, multiple outputs. Um but the the contracts are good to go. Um the broadcaster is is one specific contract which is um underway at the moment or being worked on at the moment. Um so this is a reference implementation for ELC 788 uh which is essentially a storage proof based way to pass messages from one chain to another where they

share common ancestors. So this is really the rollup um and like in in in the rollup context and this is a a call back that we want oracles and we want ideally to have trust minimized oracles. So the broadcaster is a trust minimized um option. Uh and these contracts currently being ordered again this work by the open zeppelin team. Um next steps for this would be integrating the broadcaster into the deployment process. So new networks don't need to depend on any external oracles to get started with the um the specs. So again coming up here this is at the other end of the um life cycle. So uh this is essentially standardizing the interface between the user when they're requesting a quote um and then also when they're maybe

broadcasting a quote if they're doing that offchain. Um so again this is a uh an open and open repository uh which standardized quote in and quote quoting um intent submission and asset discovery. We're currently implementing these uh both on client side and on the solver side which we'll see in a second and we're testing and hardening them for robustness and usability. We'd encourage more and more folks to review the specs. So if you're an intro provider um be interested in your take um particularly to weigh on in on some recent changes.

So we've moved away from some of the binary represent umations that Thomas mentioned. So the 7930 to the more human legible um text identifiers um at the API level um rather than the smart contracts are still uh 7930 addresses but um again this was based on feedback that it was quite hard to integrate um hard hard to integrate when you didn't have slightly readable um uh uh essentially addresses and chain identifiers. So we'd encourage folks um who who are interested in this um part of the life cycle um to take a look and familiarize themselves. Um finally the or not quite finally but the solver. Um so this is essentially the reference implementation of the specs and it's also an out of the box solver that can

be used to provide ink tank based liquidity. Um this is available for testing. It's on arbitrum based and op with mockuous DC tokens. Um and open zeppelin are also working on a userfriendly onboarding flow for L2s to set up an solver for their network. Um so that's the current um current priority search energy making it work out the box with um with minimal configuration. Obviously people could run solvers today um but this is trying to make things more user friendly. Um and finally uh we come to the user end of the spectrum which is uh the interrop SDK. So this is an interoper interoperability toolkit for wallet and app developers. Um Thomas mentioned the addresses module. So this supports interoperable addresses but um here we're most interested in the um the

crosschain module uh which essentially implements the OF specs interface allows you to interact with OF compliant uh protocols and also some others. Um we're really interested uh now that uh we've got like the initial functionality in place to talk to wallet apps and other teams interested in adding crosschain capabilities. So um this is uh and and we'll also be releasing releasing some demos and the initial version and documentation of this um imminently. Um and so that was a whistle stop tour. There was quite a lot there. Um overall we um we're at a point where we've got a lot of really great stuff we want to talk to people whether those are L2s and rollupers as service providers in terms of getting the OF up and running on your chains. um solvers are interested in

talking to them about getting started with filling or if intents and starting to think about these interfaces and um how to integrate with whether it's at the um 7683 level or um at the API interface level um interop protocols and infra providers um how to leverage the OF how to think about it um we're obviously interested in folks maybe um applying or or building in line with the specs also just interested in having discussions about how the can fit in and then as as I said wallets and apps we're interested in um talking to people who might integrate the O of or other interop providers um just to understand your pain points. So I know lots of those those kinds of people on the call today um and so uh yeah encourage you to reach out. Uh we're all in the telegram is probably the best place to start.

>> Thanks so much. Do you want to um yeah take Ellie's question on the difference between a 7888 and the crosschain broadcaster? >> Um so the so I think arbitrum's crosschain broadcaster um I know that the arbitrum team were working a lot on this initial broadcaster. I actually don't know the the difference between that but I can um follow up with the uh with the open zeppelin team. I do know that the other trim team have been providing a lot of feedback on the broadcaster design. Um, so I don't know if any of them are here.

>> Yeah, I don't see them here, but yes, we should um we can we can ask one of them to chime into the Telegram group. >> And in the in terms of the Telegram group, it's the L2 interrupt. What's the title of it, Josh? It's the >> Okay, just the base group. >> Yeah. Yeah. I think >> when we can Yeah. fork off as as required. >> Cool.

Awesome. Thank you, Orca. >> All righty. Next up, uh we have Jordi I believe here to share some of his latest work and research on >> explain a little bit the proposal that I met in the in the research. So the idea is about uh um who I see the inter roll up composibility especially the synchronous composibility. Um first of all I'm very quick I mean this idea of separating data and uh data and proofs uh I mean the idea is uh and if you have all the transactions imagine just a transaction of an L1 or a transaction of an L2 you can that's the only thing you

need uh the idea is that you can have the data you can have queries these queries generate the proof and uh you can have the state I mean the the query maybe is the result of a state but uh just having all the data is enough to reconstruct the state and proving that that state is is correct. Okay, in the idea of the m when you have multi multiple roll apps, let's forget about layer one for a moment. uh when you have multiple roll apps the idea is that you can have very easily cross rollup uh composibility is that you put all the transactions in that availability and this by itself it gives u [clears throat] it already you can already do calls between one uh rollup and and the other I mean synchronous calls for me when I'm

talking about synchronous calls is making a call I mean the idea is that you should be able from one rollup to do a call I mean an EVM call to a rollup that's in another uh EBM and the other way around and roll call in roll up two then should call to roll up one or you want to um to to to layer one okay so this is the I mean this is the idea of the concept so for when you have only rollups then that's quite easy I mean you just put data there this transactions can talk one each other and you just generate the proof that actually aggregates all these rollups okay but the in the interesting part uh The interesting part um the interesting part is when you go from L1 to L2

composibility and is the idea of the proposal is that without even forking L1 you should be able to from L1 to call uh rollups on uh layer 2 and uh even from layer 2 call rollups on layer 1 even without having to redeploy um I [clears throat] mean keeping all the the having to redeploy the contracts in L1. I mean they just I mean if you want to do an uh unis swap exchange from an L2 you just call to L1 and you just do the you just do the swap like if you were in the same uh L1 okay so how we do that and let's go to the to deep a little bit well the first thing is this idea of [clears throat] uh address I mean when you proxy addresses I mean when you are

doing a call in if you are doing a call how you say that you are calling to a rollup to you can do a specific interface for that but then you would lose um compatibility with that. So the idea uh that we propose here is to work with what we call proxy rollups. I mean these proxy rollups are well just are special smart contracts. That's a whole uh they emulate um what you would do in the in the other rollup and these uh proxies are um create to uh rollups I mean are counterfactual contracts that uh are already representing uh uh this.

Okay. So in this example for example when we have a we have a user okay a user is calling to a dowo and the dow maybe is checking in l1 again if it's in a way list or not and then it allows you to vote or not okay so that mean it's a dual call mean you are calling from L1 to L2 and from two to L1 okay well the idea is that you the user would call to this proxy contract okay and this proxy contract uh would uh do the call uh this proxy contract will do the call to the white list and then will return the result to here. Okay. So you don't have to cross there too because this U proxy would emulate what you would do actually is executing that. Okay. And how we do that? Well the idea I mean the main idea

is building what we call this execution execution list. Okay. So the idea is execution list is okay. Um so the idea what we say is in this what happen if in draw up one I'm in this state and I execute a call to a vote. Well, then you go to this state. Okay. And in this case the the result in this case the result it would not be it could be a return. Okay. So the result is this. But in this case is just another call that happened in L in L1. Okay. Um we have another execution is what happened if in in L1 actually I'm returning. So I'm going from the old state uh in L1 I'm returning from the white list. I'm

returning whatever that is this is true. And uh well the what happen is that the uh roll the roll up will go to this new state and then will return uh the vote to one to true. So the idea is that uh of course this table can be in the storage and can be um uh puted beforehand by uh uh the the the the sequencer and then the idea how it works. Well, the idea is that when you are doing this call to this uh proxy call actually instead of so in order to execute what you do is you look in this execution table what happened you update the state. So this execution text actually you update the state on the roll up too. So this is updating this

state means that this execution actually happened and you emulate a return back to here. Okay. But the idea is that um I mean the cool thing of this is that um from the layer one you just see normal calls. Okay. The only thing is that they are to this proxy or from this proxy. Okay. But all the even if you have nested calls L1, L2, L2, L1, L1, L2 or even with um even with rollbacks or or or so you can emulate exactly the same things. mean you do a roll back then you can do you you a jig that with a nested place and then you remove from the from mean you can do a roll back also in the L1. So the idea of this at the end is that you are very much uh working with

many rollups uh is like working it's like if you were in the same space as if you you were in the uh uh in the layer one. Okay. And the good thing of this is that you don't need to do um you don't need to do um any fork. And the other thing is that uh rollups they don't need to be even of course they can be EBM and they can be a standard and fix on there can be like native rollups but you can it's very it's easily you can define your own rollup. It's it's it's it's good enough to have your own rollup. The only thing is that the rollup the state function that you define uh should be able to accept or make calls uh on that.

Okay. Uh so uh I think this is quite uh flexible. I mean you can maybe you can go to the we have some links um we have some links uh some references links uh they are all them in the research but you can you can check there. Uh we made a demo. I don't know if Martin is here. We did a demo of how this would work. >> Uh so Martin just pass if you want. >> Uh sure. I'm um happy to try to make this more uh hopefully even more concrete. Let me try to share my screen.

I have um have also a recording um uh so in case my demo fails I I'll share the link of the recording but um uh you can see my screen. Yes. Right. >> Yes. Yes. >> Okay. So um so here is um um yeah the rollup h and on the rollup um there is a very simple contract um this counter contract that just has um yeah that you can just you can call it with with get and if you call it with get it will return the current uh the current value but it will also increase uh the counter

by one um but I'm just copying here the address what I want to demonstrate now here is um the concept that Jordi just mentioned. So um I am now on the layer uh one in in this case is actually a live deployment on Nosis. Let's see if it works. And I just copy in this target address and now I specify that this target is not an an address well on Nosis in this case on the layer one but instead it's it's a target address on the layer two. Uh, and if I do this, I I get this. Yeah, this this this proxy address and this is um this is deterministic.

And now I can call this proxy address. Um, and let's let's let's see if this works. Um, and that proxy address should return the current I mean basically what what this this other contract on the layer 2 uh would return in a synchronous call. And of course that that is only possible um by a builder um anticipating this um call. Yeah. Let let me let me just show it to you. So this is a um a simple contract um that just allows me to to do a a call to a target address. And I'm using now this proxy address um with

with call data. And this is just the encoding for the get uh function. Um and let's me let let me do this. So this is now real transaction uh on Nosis chain from from my regular um yeah from from regular EOA to first to this logger contract and from this logger then to this proxy contract um and let's see I will look here at the um um uh command line and there's a builder running. So, so yeah, I would I should also say this transaction is now sent um to the builder and not to the general nosis meool because now the builder

should detect that this transaction is touching such a proxy contract. So essentially a contract on the layer two and now the builder needs to prepare the layer one by um by yeah by registering this call what um Jordy calls this Jordie what was your name again this uh lookup um [clears throat] uh >> execution table I mean it's proven >> execution table exactly exactly so let's see um if that happened um Yes. So it did happen. So 40 44 second ago um this builder prepared this um this proxy contract by doing register

incoming call um where it basically where it basically told this or where it basically prepared the um yeah um this this rollup contract in a way that it said or that that the role that the proxy contract could now look up the the result of this call. um in this registry. Uh let's see decode um yeah so so here it basically says um if the L2 is in this specific state and then this specific call comes then this uh this um this call will res return um

in in that specific value. And what we should see now is that uh first the logger here um right so so call five uh previously did um did nothing and yes here it it it it uh it got the return and it locked this return and we should see furthermore that um that this counter um uh right exactly so this counter is is now um uh what um let me see right so so here we see exactly so this is the um the

call yeah that that now increased the counter one more on the layer two but also immediately synchronously got this result of the call um available um in in in the layer Um yeah so so stop sharing. Um I saw I saw one question. Um so yeah uh sir um yeah I think it's okay. Yeah, maybe I just just pause here and um yeah, also Jordy and happy to answer questions or comments or

any other questions for Martin or DHY. Cool. Well, super cool, guys. It's important to mention that all this is possible. Thank you for to realtime proving actually the the what enables this is uh being able to generate proofs in in very very very low latency. Uh >> right. I I should I should I should say so the demo you just saw had no real time proving that that was mocked. it was um but but yeah I mean um so so the uh but but but yeah we we know it is

possible um um to to to generate those real-time proofs. So yeah, it's so so I think our our thinking now was really about um how can we how can we yeah provides a synchronous composibility uh as backwards compatible as possible. So that that that existing contracts that don't uh that basically just know a two address and it doesn't have a chain identifier for example um that it still works with with existing contracts that just have a two address and therefore we need this proxy this proxy design uh to essentially um um implicitly put the target chain into the into the regular

address. Um and and then we need this lookup table and all those things. >> Helen, please. >> Yeah, I just wanted to ask if you guys are starting to experiment with realtime proving maybe even for smaller blocks um just as a benchmark see how much it going to cost um latency stuff like that. Yeah, in in in Z actually we are proving real time Ethereum blocks. Actually the average time is about less than 7 seconds. Uh we presented that in in in Argentina. Uh we were at 16 GPUs.

Currently in the next version it's going to be around 12 uh GPUs. Uh but the cool thing is that this scales very well and uh the work the main work that we are doing right now is um try to pipeline the proving with the block generation data is that even while you are building the block you can uh start uh proving so that the final latency is when you finish to build the block until you had the proof available and uh here right now we we at this point could be maybe four five seconds but uh we believe that this uh can be below uh one two seconds for sure. So that's where we

are working on this um uh real when real time I mean is lowering the latency uh so that we can pipeline uh two things okay and also parallel uh the nice thing is that when you have rollups that they don't to join each other you build these proofs in parallel and then aggregate aggregation is quite fast I mean aggregating two proofs currently is around 80 milliseconds or something like that which is uh is what allows you to uh scale very I mean still is a technology that's evolving. We are improving day by day. Uh but uh yeah we believe that uh um I mean talking about 1 second two seconds uh proving time the

latency time this is uh doable with uh current state-of-the-art on the KVMS. Of course, uh proving is I mean it's expensive, but uh it's not that expensive compared to a transaction fee. So, it should be uh marginal uh the cost of proving with the cost of transaction fee. >> So, we have a few minutes left. I want to make sure we can get to the final presentation here. And thank you again, Jordy and Martin. Um Anu and the othermind team, do you want to jump in?

Yeah, I'll share my screen. >> Can you see my screen? >> We can. Yes. >> Okay. So, Jordi and Martin really simplified my life because they just gave a very good primer on synchronous composibility. So I guess I can skip that part. So our solution is also focused on L1 to L2 synchronous composibility. And today for this uh presentation we would like to focus on one half of it where uh if you are on L1

you can call any L2 contract and get a return call back to L1 exactly as if you're calling a contract on L1 itself. So let's say for this demonstration I would like to show you a crosschain DEX wherein you have liquidity on L2 and on L1's you just have your input token and you basically swap it using the L2 liquidity as if the entire liquidity was on L1 itself. So I'll give a quick demo and then I'll demon like run you through the uh architecture of what's really happening internally. So let's say I I want to swap ETH and I have ETH on L1 not on L2.

At no point will the user himself touch the L2. So here I'm swapping ETH for USDC and I have E on L1. The DEX is on L2. I'll get back USDC on L1 itself. I click on swap. I sign this uh user up and I'll get back to what's what this user op is. Now this user op is basically being sent to a builder/sequencer who is now sequencing the transaction and the swap is done and you can see I get I got my USDC back on L1 and this was pretty fast. Of course the

assumption is that I have uh realtime provings enabled but yeah right now it's just a mock proof. So what's really happening here? So this is based upon our same slot L12 L2 message passing research that was published by Lynn from Nethermind about a year ago. So in this design the builder/sequencer is essentially concerned about three separate transactions.

Firstly, the L2 call transaction which is a call to an L2 contract and then the actual L2 block proposal and this L2 block needs to have the L2 call transaction in it plus this thing called L hot L1 state. I'll get to what it is. And then eventually the L1 call transaction itself which is like the return data that is passed from the L2 call transaction processing on the uh on the L2 state basically and the builder's primary job is to sequence these transactions correctly as a multi call batch in this design. And of course the builder also needs to put the correct hot L1 state within uh the L2 block proposal. and and that's it from the

perspective of the sequencer. Once they sequence sequence these three batch they push it into uh the L1 and that's it. You basically get this demo once you do that. But what's really happening internally? So starting with when I when I start the swap this thing that I'm signing this is a user op. Now we don't really have a particular uh standard that we are advocating for for this user op. This could be like a safe wallet op. It could be an intent or it could be any related ERC. It's completely agnostic of what

this is. A def by default a user op will obviously have like a target a value and of course some call data and a smart wallet that uh executes it or a smart account. So in this case the user op simply sends or one of the tokens depending upon which one they are swapping and the swap direction over to an L1 handler contract and this L1 handler contract starts talking to the L1 bridge. Now we have not really made any modifications to the default L1 bridge that is offered in Tao stack. And again an important uh disclaimer here that we are using the

default tao/ search stack and we are using that bridge and we have not made any major modifications to that bridge rather uh we have made this entire system as like a plug-in for the existing uh bridge that tao based rollup offers. So this L1 handler contract, it communicates with the L1 bridge and it basically constructs the call data that enables the swap on the L2 uh on the L2 state. Now for the user, it's nothing diff not the user but more like the L1 contract.

It's absolutely uh indifferent from just calling let's say as if the L2 handler contract was on L1 itself. So it passes in the token and some call data over to the bridge and then the bridge communicates with the L2 bridge. The L1 bridge communicates with the L2 bridge and it just continues the trail of passing the call data over to another handler contract which then conducts the swap within unis swap or whatever dex we have deployed on the L2 and then the same trail repeats but now on the L1 side.

So the tokens are returned over to L1. Then the L1 handler contract is called back again and the tokens are finally returned to the smart wallet. Now what's the caveat here? The caveat is this the hot state. So what is exactly this hot state? So in the usual case like asynchronous composibility when you have when you are posting a block on L1 there's always a hot state and this hot state is at best the state of the previous L1 block right this is the state that you can sync with the current L2 block because in EBM execution you obviously don't have the

state of the current block with you right you obviously have the state of the last talk. So there is no way to get synchronous composibility using the hot state or the hot EVM state like the state root. But what we can do is what we can do is we can get the hot state of a single EVM storage slot and that is what we take the advantage of. So whenever this uh call data that we have here, whenever this is sent to the L1 bridge, we basically like let's say hash it and we store it in a certain EVM slot and we basically get the state of that

slot, right? And that won't be changing irrespective of what happens to the rest of the EVM state. the state of this slot or the value of this EVM slot won't be changing because we have already set it via this via this uh internal transaction. And what the builder now needs to do is the builder needs to record this hot state and push it within the block that it's proposing. If some of you who are familiar with Tao stack, you might know that this is done via the anchor transaction which is like a system transaction that has to be uh a the first transaction in a block. So you can pass this hot state which is just uh a 32 byt hash uh in that anchor

transaction itself. Now once you pass this all you need to do is uh just just go ahead with your proposal. That's it. And automatically these extra plugins that we have created on top of it, it checks that this hot state is matching the call data that you intend to execute and it processes the L2 state accordingly. And that's it. And then once the L2 state has been processed, all the the only thing that the builder has to do is uh push the L1 call. So when the L2 processing is done, the L1 call that is initiated also has to be pushed in by the sequencer. The

sequencer might as well, you know, just not do this and ignore this. Uh we don't really have a control on that. But then uh from the user's perspective, that's not a big issue. Yeah, it's a user experience issue. But the user can also manually like sequence this transaction because this entire uh process is completely permissionless. Uh and at no point the builder has control over your funds or can can mess up uh your funds in any way. So uh yeah that's uh the overall architecture that uh we have created here for synchronous composibility.

Thanks so much, Anu. We're a few minutes over, but um any closing thoughts on your side or any quick questions before we end otherwise we can >> demo. >> Thank you. >> Cool. Awesome. Sorry, I went a little bit over. Thanks everybody for joining. See you next time. >> Thank you everyone. And I