L2 Interop Working Group #15

Transcript

Loading developers...

This is the L2 interrupt working group call number 15 and issue 1741 in the PM repo. We can yeah get started. The agenda today is starting off with fast synchronous finality followed by some updates on the ENS base chain registry sync composability from SSV network and lastly some quick notes on L2 withdrawal windows and the 7-day challenge periods.

Cool. Uh I will hand it off to you Roberto whenever you're ready. >> Thank you. Um, can are you able to enable screen sharing? >> Yeah, try again. Should be good. >> Cool. Yeah, >> cool. Um, yep. Um, I think Mik is restarting this.

>> Um, okay. Can you hear me? >> Yep. Yep. >> Perfect. >> Cool. Uh, hey everyone. So, um, fast synchronous finality for Ethereum protocol. Um, today many systems rely on economic finality as a signal and we all know that economic finality is slow. Uh but the problem the problem is that uh there are use cases that does not uh require that don't require that strong penality and uh they have to and relying on it they have to um

Fast Synchronous Finality Proposal: Discusses Ethereum protocol improvements

experience uh increased costs and latency and we propose fast synchronous finality as a solution to this problem. Yeah, let's go a bit into detail and break it down into uh three aspects. Um in the first place, uh it relies on the synchronous network. Uh which specifically means that any vote that cast by an honest validator is received by all honest other honest validators um at the end of the same slot.

Finality in this uh context means that uh if block is finalized uh then it will never leave the canonical chains chain uh if the um assumption above and the one that we will introduce later hold. Uh it also means that the block uh will be eventually finalized by economic finality. Um and uh the the last but not least drastically fast uh the block can be finalized within one slot time frame.

Uh we also assume that uh a portion of of the stake can be dishonest. uh the the max fraction of the adversarial state that is supported by fast synchronous finality is 25%. Uh this is a configurable parameter and by changing this parameter uh uh one change the trade-off between livveness and safety. So the higher this value is um the safer the block that is finalized will be.

Now let's compare it to um well-known economic finality that we're all used to. Uh the fast synchronous finality uh is tolerable to a less fraction of of the adversary and it comes with a zero economic security. It also relies on a um it has a stronger assumption on the network conditions. But given all that, it's 80 times faster uh than the economic finality uh which is uh roughly a 99% improvement.

Thank you, Mikail. So just want to go over a bit high level how this uh pass synchronous finality works just to give you an idea of how you know how we can achieve this magic of one slot uh fast synchronous finalization. Um so just looking at this example um we have a block B10 which for now we assume is canonical will always be canonical. I'll explain why we can assume this later. In this example, we assume that the weight of a commit is 100. And what we want to do, we want to check if we can if we can apply fast synchronous finalization to block B1. Uh so in this scenario and we

are currently at the end of this of the slot of B3. So in this scenario we have that um 80 we have a weight of 80 in terms of uh LMD votes for B11 and 85 for its child B13. So overall the support that B11 has received in terms of LMD or head volts is 165 and in order to be able to first synchronize finalize B1 what we want to do you see it on the right you want to check that the support of B1 is larger than half of the maximum support that uh any any uh child of B10 can receive. So

either B1 or any of its siblings. So more than half of this plus the maximum adver adversial weight that uh dishonest weight that might have supported B1 and this is because this uh this dishonest weight might be taken away because it's dishonest and so dishonest dishonest validators might give the weight to to be 11 and then take it away. So by removing this we want we still want to make sure that B11 the weight on B11 is larger than half of the maximum possible weight that can support any any any sibling of of B11.

So if we so that the maximum possible weight essentially is the weight of the uh committee from the slot of B1 till uh till the point where we we will run FSF plus this proposal boost which is an extra 40% of a commit weight that is given to a timely block and you see this in the formula. So if one substitutes every everything uh we we end up with a threshold of 160. So in this case uh the support for B1 is 165 which is more than 160. So we can fast synchronous finalize uh B1. This is just to give you an idea of what we do. We essentially counter

the stations and we have quite quite strong uh conditions to ensure that um what when we first synchronistize something it is actually going to be or is part of the chemical code J. Of course, assuming income you're muted, Roberto, >> thank you.

Um, as I said, we assume that the SAB11 is canonical. We can do this is SAB11 is the latest economically finalized block. So then we try to first synchronize analyze its child which is V11. If we succeed then we know V11 will always be canonical. So we can do the same to its child and so on and so forth. So that's very high level how um this this algorithm works. Um we do have we have been able to run some preliminary performance measurements. Now these are on proof of concepts.

Uh we ran this for a day for 24 hour. Uh and the results we got are my opinion pretty good. Like in nearly 95% of the cases we've been able to conf to first synchronous finalize a block in in one slot in less than 12 seconds. For two slots, we go up to nearly 99% of the times. And then uh above 99% for uh for being able to fast synchronous finalize a block in less than three slots. And as you can see it just in uh seven seven eight slots we get to 100% of the time we're able which

which is so if you look like you know less than a minute is we are basically there to 100%. And um one comment on this this long say long tail we think is due to late blocks or blocks that have um where the par the slot of the parent is not the slot before. So there is between the slot of a block and the slot of the parent there are empty slots and this because of the rule this this can impact the the the performance but we are working currently on an improvement uh for to to to mitigate this issue and we haven't been able to to run the measurements on. So we we

hope that um we can get even better result than this results. So just I want to conclude just uh giving you an overview of where we are and what the next steps are. So we currently have a draft specification and a proof of correctness. Uh there are two proof of concepts in tquin lighthouse that are tracking the latest spec and this is also proof of concept in prism that is implementing a portion of the specs. We have as I've shown you we have some preliminary performance measurements and also working on fixing this empty slot case.

Next Steps and Performance: Overview of draft specs and performance results

Next thing is finalizing what we have currently going on writing spec tests. We want to get more measurements. Uh we want to get some proof some of the proof of concepts of production and eventually have uh fast synchronous finality implemented in any client and importantly there is no hard for required for for fast synchronous finality. It's essentially that the there are changes that have already gone in long time ago and it's you know it's an algorithm that can be applied u just basically by an analyzing attestations as I've shown you before.

So with some references we share the slides later for you um and this is all um thank you and open to questions. trying to I guess I have the same question as Martin from the chat. Like I also I really like the idea and great to see this. um yeah being pushed so badly and yet I still struggle a bit with my mental model of how much stronger the assumption set for FSF is over economic finality like what Franchesco is saying

okay like an FSF final block will eventually be f finalized assuming the assumptions hold but we are kind of having this beta of 25 instead of 30 uh 33 Um, I think you frozen froze. Maybe we can come back to forest.

Any other questions in the meantime? Oh, okay. You're backwards. We lost you for a second. We heard the first part of your question, but the second half we missed. >> Yeah, I'm sorry. So, basically, I'm struggling to develop an intuition for how much stronger assumptions we would be introducing with FSF. Like my gut feeling is it's like 25 um or 75% of the notes are non-bzyantine versus 67% are non-bzyantine. So a slight um increase in assumptions. Is that adequate?

>> We yet for what we have at the moment. Yes. like in a way it could be possible to um so that the reason why we have this 25% is that if you have higher threshold the adversary can just prevent fast synchronous monization of any block just by not doing anything and now you don't see any progression in fast synchronous funality you don't know anymore whether it's because the network is bad or that's the vers is just not cooperating and that's really why there is in theory for safety only you can go up to 33% % but then again you have you enable the adversary to to prevent the algorithm from working.

Yeah, >> I think maybe another note is that like this definitely doesn't replace full finality and like they'll still be use cases that should probably wait for full finality, but I think for a lot of use cases today, um, this is actually stronger than what they do. Just like a lot of use cases today do not wait for full finality and instead just wait for like block confirmations and FSF is like a lot stronger of for that anyway. But yeah, some use cases should still wait for full finality if they don't feel comfortable with these trust assumptions.

>> Would it be fair to make this mental exercise? We could require that all nodes be synchronous and only treat a block as fastly synchronously finalized once, let's say, 99.9% of the previous validator set that was online attested to it. like this would be almost the same level of certainty but still probably doable in a couple of blocks uh rather than in in in 13 minutes.

So, >> what do you mean to >> So, are what you're describing kind of it kind of reminds me of I guess are what you kind or what you describing saying like you know the entire stake of an epoch would like vote on a block. >> Yeah. >> Um I mean that I think that that's possible. I guess it's just a very different paradigm of what we have now where like only a committee votes on each slot and then you get the entire stake over the epoch. >> Yeah. Then what you're saying basically you need to wait the entire epoch.

Right. >> Right. I see. It's because of the committees that we can't make this mental exercise. Yeah. Makes sense. Gotcha. >> But I mean I Sorry, go ahead. >> I would say like if you want to do that, if you're happy to wait for an epoch, you essentially you can just at the beginning of an epoch, you you can fast synchronous finalized what was the greatest analyzed checkpoint that you saw in the previous locked. So you could do that and that >> and and that's safe against 33%.

So >> yeah maybe uh in the context of what you have said uh in the context of your mental model if we like say that the block is final uh we need synchrony to all other validators to vote on it in all further slots you know so that it will get more much more weight. Um this is like one of the places where synchrony is uh required where we rely on the synchrony. In this case once every all the entire set goes on it that block is uh like will have like a lot of weight uh which will be difficult to get

through to to reorg. So yeah, >> Ian, hey, my question's in a bit of a different direction. So I don't want to interrupt if this conversation is continuing but if not um the question is so in the context of L2 interop this is as interop protocol if I want to use this I have to be able to verify this finality mechanism on the L2s um which I think should be trivial you know you can hand wave away that problem of just saying that it's you can use a snark to verify this uh finality gadget inside of an L2 execution environment but you need a public input to verify it

L2 Interoperability and Finality Verification Challenges

against. So we need uh we still need that L1 origin view um and we or you know L1 s load or something to actually verify this finality gadget uh against inside of the L2 execution environment before it's actually like useful for interop protocols uh like onchain interop protocols it's still useful obviously for like node operators and other offchain activities >> um I mean Yes, you're right. Although I don't think it would be any different than than needing that information to today.

Like I don't I don't think it introduces any new anything new than just you today. You also need a way to verify like the state of the L1. >> I completely agree. I just feel like this still something that's like kind of neglected in these conversations is that none none of this really matters until that's solved. >> No. Yeah, it's a good it's a good point. There are questions.

Cool. If not, we can move on to the next agenda item. Thank you, Roberto Mikuel for the presentation. Actually before we move on Ellie did you have anything else that you wanted to add on this topic just in terms of sort of um I don't know potential roadmap and next steps. >> Uh yeah so uh if those of you who don't know I have recently joined the Ethereum Foundation and so my first task is that I will be working on uh fast synchronous finality. So um as part of that I will be reaching out to a bunch of people in this group uh to kind of get feedback on feedback on it to see you know how best different projects are able to use it and how it can benefit them. Uh so yeah look look for that.

>> Awesome. Thanks Ellie. We are excited to have you. >> Cool. Uh, up next, some updates on the ENSbased chain registry from Unruggable and Wonderland. Um, yeah. Anyone from Unugable want to jump in first? >> Yeah. Um, I'm here. So, my name is Martin and um, representing Unraul. Uh, we've been work Did we lose Martin?

ENS Chain Registry Updates. Discussion on ENS-based chain registry updates

>> The Wi-Fi day today. >> That is typical that Martin um has just his Wi-Fi failed. He's in Nairobi, Kenya. So, I know that they have notoriously bad Wi-Fi. Oh, is he back? Wow. It's is is it uh can you guys hear me well? >> No, we can't better. Thank you. >> No, you can. Okay, let me let me get started then. Sorry about that.

Um Okay, sharing my screen. Great. Uh you can see my screen. >> Yep. Amazing. well, uh, as I said, my name is Martin and I will be taking us through this, um, Ethereum chain registry. So starting with um Thomas, do you maybe want to jump in

while we wait for >> Yeah, absolutely. Um I know that Martin's internet in Nairobi, Kenya's um notoriously unreliable. Hopefully people can hear me and mine is working better. Um, I was expecting Martin to do this, so I don't have the presentation up, but I can just kind of >> give Martin >> My network my network is still bad. >> Yeah, we lost you again. If you want to give it another shot.

>> I'm so sorry about that. >> Okay, so where were we? Let me try one last time. Um yeah, we were saying I was saying we first explored ERC7785 which was proposing a 32 byt chain identifier which will be derived by using the chain name itself along with um some auxiliary attributes of that chain to derive that chain identifier. But in the work that we've been doing, we've come to um realize that we can achieve the same result without having to use the 7785 identifiers.

And uh the path that we have chosen is to have this human friendly uh chain names um like you know optimism.c C or whatever um ENS domain will choose resolve to a 7930 identifier. So I'm going to send a couple of links on the chat that contain the original specs and as well as 7930 and yeah so the purpose of this is just to have um registry that can resolve from this human friendly name to a 7930 identifier and back So we have uh three main contracts

within this registry and uh we have the chain registry which is the source of truth. This links uh the chain label to its own record and uh lookups in this case are keyed in or rather the main lookup would be the the hash of the label which we're calling uh the label hash and uh we have the chain resolver on this other end which whose work is to return the chain the 797930 identifier from the label and the reverse chain resolver which does the opposite. It takes the 7930 identifier

and it returns our chain name for us. So these three main contracts make up the chain registry and if you look here this is the architecture I have mentioned that the registry here is going to be the source of truth and we have both resolvers the forward resolver that returns the chain the 1730 identifier and back both of them refer to the chain registry as the source of truth and uh that takes us to the chain registry itself. So this registry in order to work with this revol resolvers uh it needs to it needs to expose these two functions uh that is the chain name and

the chain ID. These are the these are the this interface is what the resolvers both the forward and the reverse resolver use to work with this chain registry to uh return the information that we're trying to pull about this registry. And moving on to the next contract uh the chain resolver. This returns our 7930 identifier given the label and the chain resolver is an ENS resolver that is fully compliant uh with the ENS spec ENSIP10 and what this means is that we can use

this resolver and the chain name that we will give uh for example base.c. that to be able to set and resolve uh specific type of ENS records. Uh we can I think we have once again lost Martin.

So I will just jump in again. I'm Thomas from Unugable. I've posted links to these slides and a demo um which kind of demonstrates this end to end in the chat so people could kind of look at this directly as well as a link to our learn page on that demo that links to all of the sort of external material um for anyone that sort of wants to upskill in terms of ENS specific specifications and architectural patterns. But the short version is that kind of having conversed with the Wonderland team who did kind of lots of work um in relation to these kind of resolver concepts um previously we've kind of uh essentially built an

ENS resolver that allows you to resolve um a chain name uh as a subdomain of an ENS name to its 7930 chain identifier. Our intention is to kind of document this uh within the um Ethereum Foundation's interop repo and kind of request feedback and commentary from the community here. And we're also going to kind of piece together a post to post on the ENS forum to get insight from uh the ENS community as well. Uh Unrugable's context is obviously ENS. So, kind of were hopeful that sort of we've architected this correctly from the

get-go and kind of we've discussed with various uh aligned stakeholders, but um yeah, in the interest of sort of uh opening this up to the community and making sure that we get this right first time, we want to um sort of uh at least have a a brief period where we welcome external contributions. But uh in the grand scheme of things, this is actually sort of quite simple conceptually. So we're hoping that we can kind of move this along quite quickly and uh have a kind of solution that people can integrate with that allows for resolution of chain identifiers on chain as opposed to utilizing centralized

resources like we do at the moment. For example, the GitHub repo, etc., etc. Um, I don't know if uh anyone from the Wonderland team wants to kind of add some additional context from their end. Of course, uh I'm happy to answer any questions as well. >> Sure, I can add uh just two extra things. Um first of all, thank you to the unravelable team. they've been uh shipping uh great improvements to all of these and they're basically uh getting this ready to be uh finally uh deployed and accepted by the ENSA as well. Um so besides that one note um to take into consideration is that the both the

registry and the resolver use 7930 but if 7930 is not enshrined neither on the register or the resolver. The main idea for this is uh for now we are going to be using 7930 as it is the uh standard that we currently all agree on. But in any case in the future that we might end up with uh an improvement or modification on how do we I don't know uh signal or or identify chain ids. Um obviously this uh what we we've all built is is dynamic enough for us to be able to switch to whatever other standard uh in the future. Uh also uh

and this is kind of important uh maybe Josh if you want you can also comment on this a little bit but the migration process from GitHub to onchain um has a script that we develop we can share the the the repo later it's a simple script um but this the important thing here is for any chain uh or chain operator or whoever that wants to set a new name. I know some of the names uh some teams might want to change. Uh they should do that as as soon as possible. Uh hopefully Josh is going to be contacting some of you uh just to try to get uh those changes in place. Um and we'll

Migration from GitHub to Onchain. Discusses script and naming process

have a a simple flow for you to to communicate those changes. So we can basically um yeah get a clean migration with uh let's say cute or nice names uh over uh on chain which might be way difficult way more difficult to change in the in the near future whenever when everything hits uh mainet. Uh also uh one thing to note you might be asking hey what's the let's say the ownership or governance process of modifying all of these uh domains or handling uh this uh second level domain. Uh those are still undefined.

uh and we'll have more comments on that later but it's uh the important thing is to just move forward do this first step migrate over everything over on chain and then we can also experiment on different ownership mechanisms to handle this uh registry and resolver. >> Thanks Kelly. Yeah sorry Thomas if you had something. Yeah, I was just going to say kind of to add to what Skele said there, um, our initial intention is to kind of set up a multi-IG of some sort with community stakeholders and that will kind of be outlined in our uh, our specification within the um, interop repo and on the ENS forum and kind of we

welcome um, feedback on who people would like to see on that. Um, but we want to kind of do this iteratively. that will be sort of a a get this out the door multi-IG and obviously ownership can be transitioned over to um a different model as um appropriate. The the only other thing was I saw that Massimo asked a question in the the chat about ENS resolution. Um ENS uh has kind of adapted over the years and there are more ENSIP specifications. So there is kind of forward resolution and there's reverse resolution which is also kind of um often referred to as primary name resolution whereby you can kind of resolve uh the ENS name associated with

an address. In the context of this um it's conceptually somewhat different in that we want to for example resolve base L2E um to a 7930 identifier but we're not trying to kind of reverse a uh address back to a primary name. So it doesn't strictly fit into the kind of primary name paradigm. So that learn link that I posted on our demo does kind of outline uh a number of sort of ENSIPs which are essentially specification proposals for ENS specifically that allow for this kind of new paradigm whereby you can um

pass in a 7930 chain identifier and get the string rep representation of a chain back instead. Um and yeah similarly ENSIPs kind of from my experience it's uh people propose them and then implement them and if the implementation is good people copy and then it becomes enshrined as a specification. So we're hoping that kind of uh we could demonstrate this as a productionized use case that kind of proves the value of the specifications we're proposing and then over time they will become enshrined.

>> Perfect. Um so yes, we will be reaching out to L2 teams uh to coordinate on some of this. Uh I see there's a few L2 teams here. if anyone has questions or thoughts that they want to share right now. Um otherwise we can yeah maybe leave it leave it there. >> I I have a have a question and this um so is this um still just related to L2 chain ids or is this like from the from the get-go extended to all L1s and even on EDMs?

>> Yeah, the intention is to support all chains. Okay. Wouldn't wouldn't like um have a um extension be kind of biased in this? I I I don't like people would get just use like salana.eth to I don't know s.cid.eth to reference something. Maybe uh maybe a a new extension name would be um more you know less biased. That's yeah that's the idea.

>> Yeah. Yeah. I think Skellyy mentioned that you can that there's maybe ways around this and I think our primary like our our goal is to support all chains at the same time our primary focus is within the Ethereum ecosystem. Um we're not attempting to force or to necessarily uh sort of make sure that we are coordinating with all ecosystems here. But we do want to at least be compatible and and support any chain that wants to be compatible. Um, and yes, I think yeah, Simon also mentioned that there's there's other ways that you know, other chains compatible. So, yeah.

>> Okay, makes sense. Sense. >> Okay, cool. Um, well, just so that we're uh we're a little short on time, maybe let's go on to the next topic, which is SSV network and sync composability. Hi everybody. Um, I'm going to start sharing my my screen. Uh, hope the Wi-Fi curse does not hit us again. Sorry, I already started on the wrong foot sharing the wrong screen. no. Yeah, you're right. Okay. Um, so this is the this this the request to speak was actually kind of like an

Introduction to SSV Network and Sync Composability. New project overview

introduction of a new project that the SSV network is working on and we named it compose. Um, and uh like it's essentially an explanation of how we went about it uh what we studied uh in order to well uh create it and what it tries to solve. Uh starting with well this is the table of com uh contents uh quickly uh we're going to go through the um where we started with the uh um functionality that we want to achieve which is the Ethereum composibility um and extend it to the L2s and then the UX research that we did the the summary of it at least for brevity and the

comparison between asynchronous and synchronous comp compatibility research we did on existing uh solutions and then our own solution like our own we think improvement upon it and a quick uh overview of well how it works in practice. So starting with I think what most of uh us in here are already familiar. Ethereum composibility is essentially the ability to um create uh well compose basically uh like Legos using like functions from some contracts and create a new contract that basically uh uses them uh once again like Legos.

The the best part about this is that wrapping some function calls in another uh rep in another function call makes sure that when a when a user actually calls this one, it has a guarantee that this will execute uh somewhat atomically. So all or nothing uh and uh most importantly synchronously in the same block. So um this is very powerful. It's obviously the reason why one of the reasons why the is successful uh and uh like in reality visually it looks like this where I can compose one single function call of many others and they all belong in the same blocks uh block like I said

um separated from from all of this like this is basically what I just talked about is the north star the target of what we want the sort of like the UX they want to achieve we wanted to achieve uh um and extend it to DL2s which is exactly uh the opposite at the moment. Uh we're going to see that uh later on. But the the next section at least is going to be about the UX of what are the tools currently available uh for achieving this uh or at least uh what the tools uh can do to facilitate this in some kind of way. And it mainly focuses on two uh things. Making uh like allowing developers to create multiple

Tools for Multi-Chain Transactions

calls and uh put them in a single transaction and then targeting multiple chains in a single uh go. It can be either one or multiple uh transactions but in a in a single uh let's say user interaction so to speak. Um, and the result is I'm putting I I skipped a lot of slides that I presented in a different call just for brevity, but the result is that we have account obstruction ERC 437 which basically works well if everyone switches to smart accounts because the bad side, the negative side of it is that uh users like the smart account has a different funding um and so there's there has to be some transfer of funds which is

another transaction that a user is forced to sign or you know uh it's not ideal in any way. Um the other thing is security concerns because uh user operations are signed using sign type data and the user is signing on a hex decimal string not knowing exactly what they're signing off on. Um, EIP5792 is wallet send calls, the additional wallet uh, RPC calls, which basically it it it lets the wallets decide how they want to support it. It's just a request of, hey, please batch some of these calls in a single go, but it doesn't tell wallets how to do it. The best uh result that we saw was MetaMask um

MetaMask implementation which under the hood actually uses uh EIP7702 which is setting uh the user's EOA code to an an external contract which basically it's kind of like a mix of the two a little bit. it it's by delegation by virtue of delegation and allowing the user to sign an authorization. Uh you have a contract living quote unquote inside of the user's EOA and then there's no movement of funds because uh the the singleton entity is kind of like using natively the funds of the user's EOA. But obvious but the the problem is this is not usable on its own because there is no RPC method to sign the authorization. uh MetaMask is able to do

it because it's an internal request with happening within the the wallet's uh back end and so they're kind of cheating in in that way and so it's also like why EIP 572 is kind of it's gated right it like Metamas can't do it because they're a wallet like if if I want to build a u a web app uh yeah web app using IP772 at the moment I cannot um for the second part the targeting multiple chains. It's important because uh if I want to achieve our goal which is synchronous composibility, the two different uh rollups or L2s need a way to correlate what are apparently to imp independent

Challenges in Synchronous Composability

transactions and uh we have not found um any we haven't found any solutions for this essentially which is why in the end we'll see we have come up with our own. Um now quick overview of uh what is currently like the what was currently available in terms of composibility and it's asynchronous composibility whereas um the uh the ability to compose different uh let's say intentions from the user point of view are made possible asynchronous asynchronously and this is why the the finality that the presentation that will was made before is actually uh comes into place because the the several minutes uh u waiting or

delay can be reduced using that but it's still going to be uh uh a delay um and it can only be reduced so so much and uh most importantly it doesn't guarantee the automicity like if anything uh breaks in here there's no way to reverse uh the course of actions um whereas what we want to achieve is this the confirmation that these actions are part of the same uh L2 blocks and they're going to be part of the same L1 block as well. And if one of them fails uh like nothing is going to be pushed to the L1.

Uh the way we went about it is by studying uh Espresso's uh circ. So we're talking about uh mailbox uh contracts that allow for sequencer to sequencer messaging. And this way basically the two sequencers can uh simulate um u the execution of uh function calls and they have to agree on uh essentially the number of messages exchanged uh or uh more importantly the status of them. Um I think this one is a better like v more visual representation um of it. So when on rollup one I lock some uh funds, I then send to the out uh outbox the fact

that I have uh locked them and so I request for the rollup B to mint uh on on the equivalent on on their side. And so when that happened uh the roller on roller B I can also chain the request to train them or do something uh like put them in a in a lending pool or whatever. And then when I want to uh let's say like this is an example of a flash loan for example, right? Uh so on the return once I traded it or it's no actually sorry it's a it's a swap not a a flesh loan. Um once I swap them I want to uh send back the funds to rollup A and so I do the essentially the reverse action. I lock them first and then send on the outbox the fact that I want rollup A to mint. uh rollup a finds uh finds this

message on the on the inbox and uh now the inbox and outbox are specular. So the simulation uh is is confirmed and uh I think we have a yeah sorry I'll get back to that slide later on but essentially once the sequencer have gone through the full simulation uh it has a confirmation that the blocks can be so that the function can be included. Um like I said this is uh probably not new to some of you but previous solutions were using a shared sequencer whereas with our uh solution we use a shared publisher and the sequencers remain uh independent entities. So there's no request to sort of like change uh

current uh L2 uh I don't know u infrastructure or the way they they design their own L2. Most importantly, a share sequencer is a a form of centralization and uh it also brings itself to scaling issues where with our design we we think that this can be uh overcome. Um it's and essentially it basically is an extension of circ uh to a means for distributed coordination amongst uh sequencers. Um this is like I said I already kind of explained it but the important part is that at the end of the simulation the uh sequencer sends a vote for um like

signaling the fact that simulation went okay and when the share publisher has enough votes it sends back an acknowledgement that the uh the decision has been reached. This we call this our um our agreeing agreement algorithm uh two-phase committee uh two-phase commit and uh at the end uh they basically send back the their own block and the share publisher publisher is in charge of publishing uh the block to the L1. Um I said that we come up with our own uh solutions because uh eventually like I said the two rollups have to uh find uh a way to recognize two what what could be looking uh like two independent

transaction uh transactions as actually belonging together. So the fact that they have to kickstart this simulation uh phase and we came up with uh custom RPC uh call uh that the sequencers uh implement and it's essentially um as as we see here like uh the identifier of the chain and the transaction itself. Uh the problem that we found ourselves is that obviously this the transaction has to be signed but commonly a web app cannot sign it.

Uh because the the methods to do that are like deprecated or forbidden and uh we turned ourselves to sign user operations because at the moment it allows the user to sign the user operation as a message and then the transaction that sends the user operation to the chain is a different thing. So we have another custom RPC method on the sequencer that basically takes a user operation and signs the transaction that should include it. And the conjunction of these two makes it so that basically the output of this compose uh build sign use operation transaction method um is a signed uh transaction and then you can use

basically the output of this one as the input of this one uh or making up the payload for a cross uh chain transaction. Then the sequencer are able to identify this operation as a crosschain uh operation and they start the simulation basically um like I have skipped the uh minutia of the zk proofs but of course uh uh like upon reaching consens consensus they also send a zk proof of the simulation itself the share publisher packages up the multiple uh proofs into um a uh an aggregated proof to the L1 Um and where there is room for improvement uh we have improved uh we

Crosschain Transaction Process. Discussion on user operations and zk proofs

think that we have improved by allowing by using user operation and allow you basically to compose like Lego bricks not by building custom contracts but by mixing matching uh contract calls into a user operation and uh the problem that we found is that uh what I already mentioned uh custom account current account abstraction solutions have significant drawbacks namely the funding uh but also the the the fact that the what the user signing is not uh very intelligible. Um we in our opinion my opinion it would be much much easier if uh a sign authorization RPC would have been implemented and supported. This would basically abstract

away the funds uh funds movement and you would act as if uh the user is natively uh accessing a a smart account from their own uh EOA. Um yeah, I think this is it. Thank you for listening. Thanks Maximo. There is a question in the chat from Ed on the trust assumptions of the shared publisher. Do you want to maybe share a few quick? >> Uh yeah, sorry. Opening up the chat which is incredibly small when you're sharing the screen.

>> Uh >> the question is what is the trust assumption about the shared publisher? >> Yeah the yeah go ahead. Oh sorry Alone. >> Hey guys Alan um um from the FSV team. Um the so the shared publisher is is as the name suggests only only publishes meaning that if the shared publisher fails uh the roll-ups themselves will be able to finalize um by uh by settling on the L1 uh independently. Uh of course the for crosschain transactions that that means that um they'll they'll there's no coordination layer for that.

uh they can still do crosschain transactions though the actual checks for the for the mailboxes is done by the shared publisher. Um the shared publisher is important to say it's it's going to be based on Ethereum validators. It's not a centralized entity. So Ethereum validators will be the one running the shared publisher um code and and actually be the share publisher. >> So that's an assumption about livveness. Are there assumptions about things like non-equivocation? What what do you mean? Uh if you can give an example.

>> Yeah. So suppose that the shared publisher tells chain A the message you sent was delivered to chain B, but it tells chain B there was no message sent. >> Oh no, no. So so so the ch the shared publisher is not telling anyone anything. So the shared publisher is um when they do the simulation, the sequencers when they do the simulation, we're using a 2PC consensus protocol. The shared publisher is the coordinator of that protocol. So they know the origin and the destination of the uh just the coordination phase or the simulation phase. The shared publisher main responsibility is to just produce an aggregated proof of the different chains. Uh and inside that aggregated proof, we also add mailbox proofs. Um so that that's the responsibility of the

shared publisher. And again the shared publisher is is not a centralized entity. It's going to be based on Ethereum validators. Um and so there is no trust assumption on like the shared publisher can fake it because he needs to produce ultimately a ZK proof. Uh now there is liveness uh challenges there. Maybe the shared publisher didn't produce any proof. Um that's why we're uh building it to be based and not a centralized entity to uh mitigate that as much as possible. >> Right? But what if it produces two different proofs that prove that two different possible histories?

That's the equivocation question. >> Oh god. So, so two two different histories you mean? >> Um, so again each sequencer is responsible for producing its own uh its own proofs and its own blocks. Uh, the shared publisher is not producing blocks on the behalf of the chains. It's passively receiving those blocks from the sequencers and then produces um produces blocks uh so produces an aggregated uh proof for them. Let's take this off off offline. >> Sure.

>> So, we just have three minutes left or or I see your hand is up. Is this something that you want to get to now or should we move it async? >> Just super briefly, this shed um like non-shed sequencing model would still require the individual sequences to have opted into the system, right? To actually consume like use the mailboxes. >> Yeah. So we differentiate between two types of uh roll rollups. Uh type one is integrated roll-ups meaning that they fully integrated it into the uh compose uh layer. Um meaning that they produce zk proofs and uh the share publisher takes those proofs and aggregates them.

There's another type of rollup called included roll-ups. Maybe the naming should be better but included roll-ups are are rollups that we did not choose to integrate into into the compos network. um rollups for example like base or optimism and arbitum um we we can enable synchronous composible uh transactions between integrated and and included rollups uh but we cannot guarantee obviously synchronous composable transactions between two included rollups because um two include rollups cannot roll that um or they don't guarantee autonomicity. So that's that's kind of there's two two types of rollups that can play along with this in this protocol. Thank you.

>> Thank you, Aland and Masimo. >> Thanks. So, >> yeah, sorry. I guess we can uh Yeah, we can end it there. Just I guess for the last agenda item, I'll just cover really quickly in the final minute here. Um topic is L2 withdrawal windows and reducing the 7-day challenge period. I guess just a couple of super quick notes. Um yeah, as many here know, this is something we have by design on optimistic roll-ups to protect against uh strong censorship attacks, but it's also a bit of a bottleneck on UX and interop. So, we are exploring designs and potential paths to reducing this 7-day period to something like potentially one day. Uh this isn't the first time that this topic has been

L2 Withdrawal Windows. Exploring reduction of 7-day challenge period

brought up, of course, and and want to make sure that we do this in an informed and secure way. There is a reason why we landed on 7 days. Um so so I I think that yeah hope to organize some discussions on this topic with L2 teams uh the folks over at L2B. Uh this is really just sort of an open invitation for feedback and anyone who would like to participate in these conversations. Um yeah so just wanted to flag this here quickly as as something that is on the radar as well. And if anyone has anything they I don't know want to chime in in the final 30 seconds here on this topic. If not, we can continue this on the next call.

Cool. Okay. Well, then let's end on time. Thanks all for joining. See you next time. >> Thank you for having us. Thanks. Bye. Bye. Bye, guys. Enjoy your sprint planning.