L2 Interop Working Group #18

Transcript

Uh just some some context for those of you that are not familiar with broadcaster. Uh it's a protocol initially developed uh by the ricum team, the offchain labs team. Uh and it's meant to be a fully trustless uh message passing system. So uh inside of we are using this for as an oracle. um it's relatively slow because it needs for settlements to to be executed. So in a lot of cases this means over 7 days of of confirmation for a for the oracle to be viable. But um we are obviously depending on the network that time can

be smaller and as you know the time of of rollups hopefully will be reduced in in the mid to long term. So this was initially developed by Oxin Labs by the Arbitron Foundation. Yeah. 2035 and uh we from open sine took over the the final development and and polishment polishing of it a couple of months ago. the initial um core contracts of the protocol uh have been audited and and I think the audit uh report will be public this week for sure. So we can share that

when when it's ready. The architecture of the system basically requires a core contract a broadcaster contract on each network and then for each architecture of the networks to have a specific prover. So we are we've also developed provers for six networks uh or six architectures arbitrum optimis linear CK sync tao and scroll um those provers are ending the the development um cycle right now and are actively being tested in test nets. uh we'll probably do an audit in February and after that we'll

be deployed to to mainets. So this is a fully decentralized protocol. Anyone will be able to deploy their own contracts and verify their own messages. uh open settling will deploy the reference contracts and provers to be to be used but again any particular team that may be interested in running their own set of contracts for whatever reason will be able to do so depending on the network uh these ma messages are broadcasted and passed along automatically uh some networks basically put the status or or the

information from the layer one into the layer two um automatically while others need a pusher. Uh that pusher will also be available and guides on how to transmit the the pusher will will be available for the public. So, um, the broadcaster protocol is likely going to see like real use cases in the first quarter of the year. If anyone is interested in tinkering around, playing around, experimenting with it. Um, right now it's in a decent status so that we can get started on on testing test nets.

So if you are building on it or you're interested in exploring, breaking, auditing, testing, uh feel free to to reach out to me through Josh or directly in in Telegram and and we are happy to collaborate on on that. Uh can you send some info on the test net? I will I will now share um the existing deployments but there is no um kind of app to interact with these things is it's meant as an oracle so anyone interested in interacting with

the contracts will have to generate their own proofs and uh it's not a lightweight protocol. It's pretty heavy. it comes is the drawbacks that comes with real decentralization and and real uh trustlessness. Any questions? Cool. Thank you, Pepe. Appreciate the last minute jumping in. Excited to have this. And yeah, thanks to Arsham and everyone who's been a part of this.

excited to have it as part of the OIF as the uh yeah broadcaster Oracle. Cool. So So maybe we can switch back. I think we'll have some more OAF updates later on the call, but uh maybe we can switch uh back over to you Noah um to share some uh yeah presentation I think you have prepared on the ZK sync interop. >> Sounds good. Glad to share. >> I just need to request the sharing thing. >> Yeah, now you're cool. Thanks. Okay.

Do I not have this enabled? >> I'm going to have to quit and reopen Zoom. >> You probably don't need to. Just try. If it's Mac OS, it's a fake warning. Just try. >> Okay. Yeah, that worked. >> Worst always comes through with that tip. >> It's so annoying. Like they've had this for years. >> Yeah, it is a bit silly. >> Yeah, excited to be presenting today.

Today I'll be talking about scaling Ethereum's liquidity with L1 interop that is provided by ZK stack. Our goal with this is to solve D5 structural cold start problem. And my background is I'm the director of interop on the product side at MALABS. So the current issue and we see this with every single new chain whether it's um an L2 or L1 we saw off bar chain we saw plasma we've seen it with all the different L2s is every chain starts from zero currently every single application that you want on that chain needs to redeploy. We need to rebuild liquidity. They run these massive liquidity mining campaigns where they spend tens if not hundreds of millions of dollars to essentially subsidize DeFi liquidity and you end up having very very very

mercenary capital that comes onto your blockchain and gives you the appearance that your blockchain is succeeding. But when those incentives dry off, Ethereum still holds the majority of real durable DeFi liquidity that stays for cycles between cycles essentially. So the structural cold star problem repeats across every single new ecosystem and it's something we noticed in our ecosystem as well as other ecosystems that we're launching as well. So for the longest time Ethereum Ethereum has used L2s to scale its performance but for the first time L2s can now scale Ethereum liquidity via ZK stack. So the reason why we're able to do this and I'll more into the tech part of it later is we recently came out the CK sync atlas

upgrade which is our new upgrade that gives us even equivalents 15,000 transactions per second one second CK proving time and our proving costs have dropped dramatic have dropped dramatically as well. The second thing we recently came out with and this has been in development for a while as well alongside the Alice upgrade is something called Zcasync private. So it's the first blockchain platform to essentially unite the verifiability and interoperability that we've come to love of public chains with the control, privacy, and compliance needs for institutions to actually operate on chain.

So our solution essentially marries Ethereum or CK proofs by combining the most neutral global settlement layer with the strongest guarantees and the largest network effects. Open CK proofs to allow institutions to operate compliantly while still having interoperability and allowing for high throughput at a low cost. So what L1 interrupt is is the first thing that we demoed a couple of weeks ago was users on any ZK chain. It can now deposit into a on Ethereum borrow assets like go or USDC or any other asset on a Ethereum defy without switching networks. They maintain one wallet, one identity and one streamlined user experience. And privateiums allow institutions when they're operating their own private execution environment to access these markets as well. So instead of each

individual institution needing to have a forked instance of of a Morpho or any of these other large D5 protocols, they can now tap into Ethereum D5 from their L2, allowing them to do thing things that were previously not possible because typically institutions do not want to operate on public chains showing off everything that they're doing. But if you can allow them to operate privately for the things that need to remain privately private essentially but actually still tap into one defi we've seen that that they are very excited to to use that primitive overall and we think that's how you bring institutions back to DeFi essentially.

So the way it works at a high level is a user signs two transactions on the L2. Transaction one is essentially having your funds get withdrawn to cryptographically bound alias account on the L1 and the second transaction is an interop bundle that contains a list of L1 D5 actions. Optionally, you can also bridge tokens back to the L2 automatically as well. So the way it works and and this diagram just essentially goes over exactly what I said before is to the user they just fund their alias account in this case with ETH. They execute the action which is depositing into a on L1 getting a real position. They they receive the A token in that account on L1 and then they can view a unified balance. So the user it's like they're never leaving

home and well this work still happens on Ethereum. So there's no co-mingling of user funds as well which is crucial for systems like this to scale. So the reason why this is now possible is due to us having much faster CK proof and generation and settlement than in the past. So air proofs typically can be generated around one second. Oh, are there comments? Oh, got it. Sorry, saw chat. And withdrawals can finalize on L1 in minutes. We also have a multi-implementation sequencer which hardens against bugs and attacks. And the elast account is a deterministic L1 address mapped to user's L2 account. And they it doesn't require new keys and it doesn't require another custodian on

top. And it's very easy to support as well. And the interop transaction bundles can essentially contra contain arbitrary actions. So in in this demo we did of a it would be relatively straightforward to do it with morpho unis swap pendle anything else you want to do on ethereum. It preserves the full ethereum build it and the bundle is executed via the alias account and it's a really seamless UX. So these borrowed tokens can be bridged to the L2 and the user never has to leave the chain, never has to handle all one gas or accounts manually. And with privateiums, this allows institutions to get private access to lending markets, liquidity pools, yield markets, usage of existing protocols, not forks, internal workflows stay private while the market

actions still here. They can also do things such as optimizing collateral for treasury and credit funding operations, moving funds between L2 and L1 in minutes, and accessing intraday liquidity and hedging gate builders, private operations on L2, market interactions on L1. And the thing that I'm really excited about as well is really around the trading use cases and more advanced use cases I would say where you can essentially run all of your more computationally expensive logic on the L2 like a matching engine credit systems like order books things such as that on the L2 but still access collateral on ETH1. So that allows for essentially there's a structural

mismatch right now between ETH one liquidity cost and ETHL 2. We actually went and we spoke to all the different teams that run the liquidity farming campaigns and run the different vault systems. And what we realized is if you look at Morpho and AIA on ETHL1, they're users are fine receiving a lower rate on those protocols than they are if they're on an L2. So if you're on an if you are an L2 or or an or an alt L1, you always have to pay greater than the A or Morpho rate that is on Ethereum because there's the ex existing not existing there's the extra risk of me moving capital to your chain and there's quite a few LPs or equity providers that don't want to move

to those chains. So due to this you can actually get capital for cheaper. So this offers a structural advantage for L2s that tap into the system because they're able to essentially get capital that would be fine with a lower rate compared to every other alt alt chain system or other L2. And longterm we believe this allows Ethereum to really become the capital hub. CK chains and private allow for sovereign and sometimes private compute. Ethereum gets the shared settlement liquidity base and usually get the best of both worlds having institutional privacy, public market depth and a unified ecosystem rather than fragmented islands and frequently asked questions as well.

Today a separate account finalizes withdrawals and executes bundles but soon applications will be able to charge L1 gas on L2. Supporting new protocols is very straightforward. It's generic so it's very quick to add them. Um protocol teams can also do this themselves. Feel if you are a protocol team interested in this feel free to reach out. we'd be glad to support and it only costs a couple dollars per transaction. The main delay is Ethereum finality and the final and essentially the SE the frequency of settlement as well and when transaction is coming soon that will likely be done with an account abraction system. So yeah, that's everything. Thanks so much for having me.

questions for Noah. Maybe one question to start off. You mentioned it here a little bit, but I guess um yeah, can you share more around how fast is like it sounds like this is sort of on the order of minutes rather than seconds >> for most blows today bottlenecked by the L1. >> Will that in practice prevent a lot of the usefulness if this is minutes? like are is like how do you think about this and and users willingness to to wait minutes for certain flows?

>> Yeah. So on that side, the primary customer for this is actually institutions. The majority of CK sync L2s are that are coming out that are new L2s are using our private stack. So they're institutions that are managing collateral. So, for them, when we're able to tell them, okay, you can now manage your lending workflows and it's going to take 10 minutes, rather than them having to call their lawyer, um, enter in a new counterparty agreement and go through all of the headache, um, like like currently lending in traditional markets, it just takes a lot longer. It's it's not as programmatic.

So the fact that they can do this for any asset at any time and set this up in a matter of minutes is like a massive change um and much faster. So for crypto people it's obviously something where it's like it's not as fast as they're used to. But I think over time the bet that we're making is the majority of new capital and new users coming into blockchain systems won't necessarily be cryptonative and it'll also be used more and more so in a backend like capacity. So if it's a back end like capacity, you don't necessarily mind as much about things like this because it's so much faster than your current system.

>> Yep. first >> um on the uh 1 second latency within the cluster. Um what makes it such that I guess it's like a zk stack L2 or L3 getting like a proof done for I guess some significant gas. Why is it so much faster than actually proving to be L1 in terms of uh prover time?

>> Yeah, the way due to like hashing or like zik friendliness where is this big discrepancy from? >> Yeah. So the reason why is there you can obviously sell to the L1 more frequently um as well over time there what the gateway is doing is essentially aggregating the proofs. So when you need to aggregate proofs across multiple chains that's all always going to take a while. And there's also within our system we essentially have two different types of proofs. We have the fry proofs which are very fast fast and then we have the snark proof which is the proof that gets verified on L1. The snarkification process takes what a couple of minutes currently. Um so that

that obviously causes delays for things. Okay. Can I answer >> couple of questions in the chat, but maybe Lumi, do you want to read out your question? >> Yeah. So, the chains are settling to ZK gateway as pseudo L3s. So, you basically the chain operator or the user needs to wait for ZK gateway to settle onto L1 before any actions can be executed, right? >> Yeah. >> How frequently does ZK gateway settle? Currently >> it's for us right now CKGK will be settling quite frequently >> isn't there still three-hour withdrawal period like artificial delay

>> once we had now that we have the multiple implementation of sequencers we don't have the three-hour withdrawal window delay anymore >> just to quickly inter here uh I think Lumi knows the error implementation more which has this uh finaliz but the new zinc gateway They will be on the ATS upgrade so it's not really relevant here. >> Thanks John. >> I believe I can pronounce that. >> Hey yeah that's right. Uh so uh I did not follow much of development of the previdium but can you give me a a sort maybe a a gist of how does it achieve the privacy guarantees or what are the

things that it offers and how does it do that like >> yeah so for privateiums prividiums has a role-based access control system on top of it. So it gives you privacy in the same way that you would have privacy in like a traditional database. You're able to essentially choose which users see which different smart contracts and you can do different roles for different users. You can even allow for different applications to see different smart contracts as well operating on the private. It really allows for a much more granular level of control for the chain operator um that previously wasn't available.

Hope that helps. Uh yeah, but does it use anyhow stealth addresses for transaction unlinkability? Maybe >> privatium is an enterprise product. So it's not necessarily doing privacy like Zcash. It's more privacy like a institutional level privacy. So privacy like Snapchat or email. >> Okay, makes sense. Thank you. >> Yeah, no problem. So that means you guys are not using hiding like you are not using zk uh snarks you're just using snocks or stocks right >> for private >> for privium in particular we it is a zk rollup it's it's a zk rollup that is a

bidium and the data is held off chain and then we have a rolebased access control system to essentially allow enterprises to choose who can see which things on their chain and they can define user groups, different roles, different even contract level permissioning. So that's the primary use case for it. It's not necessarily designed to be used like a mixer or anything like that. >> Gotcha. So it means in particular you are posting a normal snark tol which leaks information about what happened but you assume because it's like in practice quite little that it's private enough >> and you basically restrict access on RPC level.

>> It does not leak information to what happened. The way that our system works is you are not leaking information about what happened on onto the execution of the L2 itself. >> Okay. So it's a different prover than the airbend. >> It is the air bender prover. The way that we have designed this system is any personal identifying information for the different institutions that are operating their own privateium is kept private and kept on their own service.

>> Okay. So maybe this is just a theoretical new instance. So is it adequate to say the RPC is the gateway to uh like uh basically authorizing this user to access this data and another user to access another data. >> Yeah. The gate the RPC for the privateium is where all of the rules rules are set. >> Makes sense. >> Cool. >> Um, we're getting a little bit low on time. Maybe I can read. There's one question from Franio in the chat. I'll read it. How many of these providiums are there in prod currently or coming soon?

So we currently have one live already with a company called Momento that's operating it for Deutschbank and we have other major Prideium announcements will be coming out in Q1. So we have a lot more that are on the way. Um so yeah most of them are going live in Q1. We have a few they came out that were recently announced such as Elnet that's doing that's launching private a lot. We have a lot more that are essentially coming in Q1 and Q2. Due to the nature of most of these customers, we can't say them publicly until they're announced, just due to NDAs.

>> Got it. Thank you, Noah. This was great. >> Thanks for having me. >> Appreciate you coming on. Next up on the agenda, OAF. Some more uh updates I think on that side of things, and I will kick it over to Orca if you're available. Hey. Yeah, sure. How much how much time um is there just for context? If you said we were a bit behind, >> uh I think we can Yeah. Uh we got at least 10 minutes, let's say, here for Yeah.

>> Cool. Let me probably Well, will not reach that. I guess I'm going to run through a couple of things. Can you see this screen? Great. >> Um okay, great. So uh I guess just a few things OAF related and then one interrop address thing just to make folks aware. So first is asset discovery. Um so interop providers invariably have an API for their chain or asset support. Um so and but this wasn't part of the OF specs sort of API specs currently which just cover getting quotes and sending orders.

Um, so we've added this to the OIF specs and it would just be good to get feedback if if if you're a person who either has such an API or like has opinions. So it's pretty simple. It's based on the solver um the existing OAF solver implementation um just as a starting point but there's probably room for a bit of bike shedding but also just be interested in um people see it because you see different approaches. Some people have a separate endpoint for chains and for tokens and some support roots specific roots. Um so making people aware of this and soliciting feedback. Um similarly we're um at Wonderland uh we're working on the crosschain module of the interrop SDK.

We're trying it out on different OF compliant interrop solutions um with our with a OAF provider which basically influence the spec. um we've existed found some areas where existing providers are not aligned with the eye of specs. So I think that's one where we're talking to open zeppelin about the solver and aggregator and we've also been trying out um lifi um we'll be reaching out to teams to check if things are expected unexpected in terms of any like um digression from the spec but if there are other folks who are running a compliant solvers or endpoints um we'd love to take them for a spin. So, um, as I said, we're aware of Open Zeppelin and, uh, LiFi, but let us know if there are others, um, that we can be testing

with. Um, I'll keep I'll keep rolling. Um, in the same vein, um, in the SDK, one thing we're looking at is um, quote validation. So, this is when you're actually interacting with an API, you'll send maybe a an intent and you'll get back a quote and something to sign. Um, obviously there's a risk there if it's a server you don't trust um because they could give you back anything to sign. Um, so one thing we're looking at adding to the SDK is obviously sort of client side validation. Um so if uh anyone else is thinking about those kind of things that's passing whether it's a transaction to make onchain if it's a user submitted um intent or if it's a

712 thing to sign making sure that you're actually um signing something that you're happy with that actually meets your initial requirements. Um we'd be interested to talk to any other teams who who've thought about um that problem of not just trusting trusting what you get back from an API. Um and then lastly um 7930. So this is in the slightly different thread but related so interoperable addresses. Um this is the spec which undergone a lot of revision over the last couple of months thanks to the I think the unruggable folks who are on the call um who've um been collaborating with us on this. Um so we'd love to hear hear any feedback if if folks someone read the spec a little while ago and thought it wasn't um wasn't that clear. like

hopefully it's better now. Um I think I did just want to draw this group's uh attention to um one thing which is a bit under discussion. So um currently 7930 defines both the interoperable address which is binary machine readable would look something like this if you were to print it out um and it also defines interoperable names. That's a sort of a complimentary um string which is passable by humans. I think there's some debate over whether it's readable by humans or not. Um, so here you've got the uh address, you've got the um separators, and then you've got CIP identifiers and a check sum. Um, and then the other uh interoperable address ELC makes them more human readable by

introducing ENS support for addresses and chains. Um, and the the point of discussion has been whether having both the address and the name in the same ELC um is confusing um or or potentially confusing for uh people who might be looking to either use the standard in in in other ELC's or or or just implement things. Um so again, welcome folks. Uh we'll I guess be posting on the forum to notify the the recent changes to get any eyes of people who haven't looked at the spec for a while. Um uh but would also yeah we're thinking about this or we've been discussing this specific question just be good to see if there are any other opinions um out there and that's I'll stop sharing

and look at the chat if there is any chat and yes thanks folks for showing the EC's friendio Okay. >> Can you clarify what's being discussed? Um, so the the interoperable names are currently in 7930 and you are discussing whether to remove those and move them elsewhere. >> Um, yes, I think I don't know if Prem is on on the call. I think he is. Um but I think uh yeah this was uh based on some of his feedback uh which was just

saying that having the the names and the addresses in the same thing then made it a bit unclear what a 7930 address meant which of those sort of formats it meant. Um and so I think that there obviously like a couple potential approaches um from where we are today. Um but yeah maybe Prem if you want to outline your case. Uh can you hear me? >> I can. >> Okay, good. Uh yes. So I um I think this uh discussion started I think Teddy had posted something about uh clarifying the difference between the interoperable address and the interoperable names. And uh my opinion was that it should be very clear when someone says 793

address uh what they mean. And uh I noticed uh in the 8092 spec um that uh sweet Katherine of base names was going to a particularly high degree of intention to specify the binary presentation uh versus the interoperable name version and I just thought this would be a burden going forward for people who are having to specify 7930 addresses and it should be a very easy uh interpretation. So if we move the um interoperable names portion to 7928 uh 7828 uh then it would be clear that we have a a binary specification and then a more more human readable specification uh in the 7828.

>> Does that make sense? Anyone else? And I think it's maybe hard to get up to speed with all of this on a call. Maybe we can take the discussion to the telegram group but yeah okay anything else to touch on this topic orca pram anyone else >> I think that was it um there are a few links which I'll share in the channel if anyone does want to follow up as I said that was mostly a call for input. Um, and as Teddy says, the forum I think probably is the best place um, going forward. Um, and as you say, we're

trying to obviously, as with all these kind of things, balance um, uh, balance speed, but obviously also quality. So, um, we just want to make sure we get that get that right. >> Yeah. Yeah. Thanks, Teddy, for flagging it. take the discussion to the forum and we'll try to balance getting things right with endless uh discussion threads. And yeah, thanks again to Unugable, Wonderland, Orca, everyone for jumping in. Excited to have these released to the public very soon. Interoperable addresses.

Cool. Okay. Um, so I think we got through what was scheduled on the agenda. One thing that I added as just an opportunity for any open discussion. I'm not sure exactly maybe where where this will go, but um for anyone to sort of share their thoughts. Um I know there's a few folks here who who have been thinking quite a bit about this. The topic of uh full synchronous composability and Ethereum uh sort of the the value, the urgency, the priority, how should we be thinking about this as an ecosystem? The question of async interop and does this actually get us most of what we need? sort of a costbenefit question here for the ecosystem. Um, yeah, we we of course won't won't settle this in in 20 minutes

here, but it' be great to maybe just get use this as a as a opportunity for people to share their thoughts and and maybe we can um yeah, try to move this question into a more productive uh place together. Anyone want to jump in? I know um Allan uh you know you shared I think a really great research uh ETH research piece on this not too long ago. Um I encourage folks to read that maybe if you want to drop the link or I can find a link to that. Um maybe if you want to start with like a quick I don't know if you're able to sort of summarize it in a minute or two but uh maybe just sort of or you know sharing sharing whatever you want in terms of your perspective on on why you're bullish us prior to us as an

ecosystem putting much more uh resources into synchronous composability. >> Hi everyone. Uh Josh, thank you for having me. Um yeah, I would love to kind of uh open up the discussion. So I've been thinking a lot about interrupt for the past um six or eight months and obviously we've we've came along uh a great deal of of work has been done uh intense today's is the kind of the premier framework um but I I would I would uh maybe kind of suggest thinking about two things one is um like everything with Ethereum we we kind of uh going from the philosophical to the practical or the engineering, right?

So, I would start with the philosophical question. What is exactly Ethereum? Is it Ethereum DL1? Uh is it E the greater Ethereum as as I call it? Basically, Ethereum and all of its rollups uh and so on. And I think that the way I I look at it is >> I just want to leave. >> Sorry. >> I think you Okay. Um so um the way I look at it is the real power behind Ethereum is its network effects, users, DAPs uh and and really the flexibility of what it can do. And so I would suggest that or at least I I I view it as Ethereum or the greater Ethereum meaning that Ethereum DL1 and all of its

roll-ups should feel like one big execution environment. meaning that if I'm a user or am if I'm a developer, I shouldn't be uh experiencing moving between domains uh as if they're completely separate chains. And I think today it's it's very much the case. Um we we've gotten really good at at moving uh value between chains, not necessarily just even within Ethereum, between Ethereum and even other chains as well, Solana and so on. uh we gotten really good at that, but also uh we got pretty worse at fragmentation. Um I I I think that's a kind of a core question I've been battling with. Um, and I don't think intense alone or really fast asynchronous message passing can solve.

If if if the goal at least for me is kind of this one unified execution environment where me as a developer I can do arbitrary read and writes uh birectional arbitrary read and writes between uh different rollups and ethereum and rollups um and have it in a stateful way. I don't think asynchronous message passing or intents bring us to that point. Uh and so that's what kind of picked my interest in synchronous composability. Um maybe maybe we can follow up with that kind of what it what it can enable us and so on. But I I would kind of want to suggest that um a lot of has been done the past two years with synchronous composity. So a lot of the kind of uh notions of what it is

kind of actually changed the past two years and more specifically the past 12 months. uh both research on interrupt uh synchronous composibility interop has has gotten really good and also um zkate uh uh VMs gotten to a point where it's actually feasible to do I think in a way that is not intrusive uh and and and and and actually um from an engineering point of view and a product point of view makes makes sense um and so that's kind of how I look at it um um yeah I mean >> what what do you think Alan about the sort of the fundamental tensions that Mark from optimism brought up in the chat around this idea of synchronous composability the challenge around extending that across governance

boundaries. >> Yeah. So I I think that a lot a lot has been done um in that area. So uh it used to be the case that synchronous composability was imagined or uh thought of as shared sequencing. In that context I do believe this is uh not feasible and not something that we can bring to market. uh rollups leave independent sequencers for many reason um but but research and work has been done to actually uh not not require that anymore. So if if you guys are familiar with uh this the fabric team and their uh scope framework that they released I think around three or four months ago uh which is really really cool uh our work

at compose and and others um we don't talk about shared sequencing anymore um everyone has different approaches but I do think there's a feasible way forward with synchronous composability which does not require uh compromising on who runs the the sequencer meaning that rollups they have independent sequencers. Furthermore, rollups and and and sequencers of the those rollups can actually decide um how they manage uh interrupt in that sense. So for example, if you don't want to interrupt with another chain, you can make that decision and it's it's simple config on your on your sequencer. Um and so those things came a really long way. Um and and and I think that kind of puts it in

a really good place from again from an engineering and feasibility point of view to actually be adopted because it's much more lightweight than it used to be uh in terms of kind of the infrastructure to acquire this. I have other questions, but does someone else want to jump in here either on either side of the debate? Anyone from there's a few folks from Nosis team can I know Sebastian or Frederick if >> Yeah. So um hi I'm Felic. I'm one of the founders of Nosis. I'm here for the first time. So uh good to see you all.

Um yes um we were invited to uh this group and this call because we've uh recently started looking into um well more seriously started looking into synchronous composibility um with um real try real time proving um as a uh core um tenant of that. Um I 100% agree with Alon that um uh synchronous composability is where it's at. So kind of I I mean uh we we are big on intents. We kind of build cow and uh so kind of like it's it's not like I don't I don't want to dunk on that. But if you um want to um

if you want the wider Ethereum ecosystem to feel like one ecosystem and not um a fragmented federation of different um ecosystems. Uh for instance, if you want to be able to have an identity on say a very privacy respecting network and uh interact with um uh DAPs on other networks without kind of porting all of that over. I think um I think kind of being able to compose synchronously, so kind of being able to call a smart contract on network A from network B um and vice versa is absolutely key and I

think there are different ways of actually getting there. um the one that um we together with um Jordi from the ZISK team um kind of developed um functions somewhat differently from Alons but kind of ultimately um if if we end up getting one of these solutions um I think the ecosystem will be so much better off because um it's it's not just about shared liquidity um kind of yeah we can I mean wi with kind of intense frameworks you can move um you can move tokens over fairly

quickly you still need liquidity providers and so on but I mean it works kind of caus also works but for um more involved business logic that goes beyond sending tokens you need you need synchronous composibility Can you give an example for what use cases or what flows you would have in mind that would uh that would actually require synchrony rather than just composibility?

>> Well, everything where kind of you have where you want one protocol to interact with another protocol and they're not on the same rollup, right? Um so for instance if I uh if I have um say um Aztec ID on Aztec um and I want to do something on say ZK on ZK sync um then kind of I I need to be able to kind of prove my identity for certain um for certain use cases um uh at kind of in an atomic transaction in order to do something and this is only possible if you have synchronicity.

>> Why why do you care about this being atomic? Why not just send a message via the canonical bridge that takes let's say 1 hour to finalize on the L1 and then read it from the second rollup within 16 minutes. >> Terrible user experience. >> 16 minutes is forever. >> Yeah, that's a terrible user experience. So if you just want to do something on um on another network that requires proving your identity, you don't want to to wait for 60 minutes for that. I mean that's that's yeah I I mean currently people have to do this and I think kind of the the one argument that I hear against it is that kind of current DAPs do not require this but current DAPs do not require this because it doesn't

exist would be as my my point. But to push back on that, like for identity in particular, if you want to verify identity on chain, you're doing some form of CKYC, you're going to need a verifier for that identity. Why can't you just deploy that contract on the other chain that you need to prove your identity on be >> because kind of identity is much more than kind of just I mean identity is also just an example here, right? So kind of I I'll go into kind of the explanation for the identity um example, but kind of happy to kind of give more examples too. Um so kind of an identity is in in some um way it's a it's it's a collection of attestations, right? Kind of like what part of my identity kind of

I um prove um to what application should be um should be on me and uh kind of depending on what I do, I might actually have to prove different things, right? kind. I might have to prove um that I'm above 18. Um I might have to prove um that I am a citizen of Germany. I might have to prove that I have more than XYZ amount in assets. So I'm an accredited investor. Whatever. I mean there's different uh there's different facets of your identity. And it's to me very identity identity is not a one one-sizefits-all um uh topic.

Yeah, I I get that. But I guys, I've just I I struggle to see a use case for sync composibility outside of like crosschain flash of just I I used to work at a company that it whole point was trying to get synchronous composibility adopted. Um, like anybody that's been on these calls for a few years can tell you that like I was very bullish on synchronous composibility for a really long time and now I'm working on protocol that's focused primarily on async. And I think in general it's just the majority of synchronous composability use cases can be done with async atomic interop. Um, and as more privacy preserving tech needs to be adopted in crypto, I think synchronous

composability also gets harder and harder to adopt because doing anything at the sequencer level I think just becomes more and more difficult um to get adopted for synchronous composability because I I think in general expecting expecting like financial institutions to want to use a shared sequencer or like shared structures like that um I think they're just much more concerned erned on what is what does settlement actually mean here? What does finality actually mean here? And I think that in general it's I think shared settlement solutions are more likely to get adopted for the long term compared to shared sequencing or synchronous composability solutions.

>> But but but I think we we need to get off the table the shared sequencing part because that's really you know a two-year ago kind of approach. We don't have that anymore. uh we do have solutions for kind of keeping sequencers intact. But but I I would want to say in terms of um kind of the the the use cases which kind of debate always comes about. There's a lot of things we're doing in Ethereum which um enable new things to happen. Nobody's asking no DAP is asking for faster finality. They don't care about it. Uh but we still do that. No no DAP is asking for postquantum signatures. They don't really care about it but but we still do that. I think the thing here is that what is Ethereum exactly? If we require

developers to to redeploy their apps 30 times on different chains, I don't think this is kind of the vision of Ethereum we want, right? Um um if if users move between chains and and moving between Ethereum and Solana and Ethereum and Base feels exactly the same thing from a UX point of view, I don't think this is Ethereum at all. And and in terms of of how urgent this is, I would put kind of this as as kind of a um a point of reference, right? We are all kind of, you know, crypto trader is is is is outraged with the tempo and arcs of the world, right? But I think we're missing a big question. Why did they decide which are, you know, both of them are really hardcore Ethereum projects at the

beginning. Why did they decide to do an L1? There's two reasons I can think of. Number one is they want to control their infrastructure. But uh this this is also true for an L2. They can they can still control their infrastructure. The second thing is in my opinion is that uh spinning up an L2 is as hard as spinning up an L1 today because when you spin out an L2, you need to recreate an entire ecosystem. You need to convince major deps to redeploy their deps. You need to convince um um solvers to connect to you, liquidity providers and so on. And so it's not just about what exactly is the use case, it's also about um the things it hinders. Uh it hinders L2

advancements because it's very hard to spin up L2s. And so for me, the urgency comes from not ex necessarily the the things that DAP developers are asking or not asking today is also from the things we as a community lose. The fact that uh Tempo and ARC are not in L2 in my opinion is is a really big loss for Ethereum and in in in my opinion if we would have had synchronous composability the reasons for them to become an L1 would have been much harder to explain to the board of directors because the network effect of being part of Ethereum is so strong. Um and and so that also goes back to the urgency part. Uh I I do think it's a it's a it's a philosophical and any engineering question we need to

ask ourselves. It's not just about who is asking what because those things are not available right now and so people don't even know how to ask for that. >> Right? >> I never like the argument that we're enabling new programming paradigms and that's why we should have synchronous composability. The only answer anyone can ever give me of why we really need synchronous composability is flash loans. And even that you can do asynchronously like the the examples that you point out in this ETH research post where people give like needing to deploy the same DAPs over and over again on chains. Well, they probably shouldn't do that, right? You don't need a unis swap on every single protocol. If you're able to do crosschain swaps well and if

and and cheaply, right? So, not every L2 should be a copy of every other L2. You can start having like more specialized L2s. So I'm not I'm not throwing a big bone in this. If we solve like synchronous composability in a way that scales, which is the real question, most like no distributed computer system I know of in real life is synchronous. Like the internet didn't scale like that. No other network scaled to mass >> while being synchronous. So I think the real question is scale. The applications can absolutely be developed asynchronously and not every chain should be a copy of every other chain. Like you have deep liquidity chains like arbitrum that it makes more sense to swap on than your

random new out. >> But do you think sorry >> so I would I would say that almost every PFD protocol we have is at some point synchronous in in times where it's kind of a happy flow and and and partially synchronous in other times. Synchronous composibility does not require synchronicity between chains. They do not require the same block, the same sequencer or even uh matching up when block are produced or CK proofs for those blocks are produced. We've we've moved past those points. We do have the research and kind of engineering behind to decouple those things and make it in my opinion scalable. But but going back to the

point of of dep developers, but that's the kind of the reality of the thing. Uh DEP developers are redeploying their apps million times over uh fragmenting their user base uh bumping up their their ops uh expenses and complexities. That's not because they want to. It's because for them in order to touch individual domains, they have to redeploy their deps because each chain is its own thing. They're not part of Ethereum. Um they're settled on Ethereum, but they don't feel as part of Ethereum. And so I think that um and also goes back to the question of you know how many roll-ups do we want? How much how much competition we want. I I think it's it's not just about flash loans. It's about everything. Why do we need an interrupt vision where it's it's basically based on intermediaries and

and liquidity that that's that's it goes against what Ethereum tries to be. Are we actually saying that the future of interrupt is solvers and and liquidity for the top four or five tokens? What what if I'm token number 50 on CMC or token number 100? Who will provide liquidity for me? So I'm not part of the L2 vision. I mean it's very problematic. Uh and again I'm not I'm not dunking on anything. I think interrupt with intent is extremely important. There's things you cannot do with synchronous responsibility, but it's equally important to recognize that there's things you cannot do with intense >> like calling a smart contract from another smart contract on a different

network. I mean, if you kind of if if you look at um the ways that DAPs today interact on the same network, I if I mean, if they couldn't do that in the same block, I mean, you'd you'd lose so much. So um and I think kind of we're we're we're losing out on that in um in the wider Ethereum ecosystem between different air tools. >> Well, you don't need synchrony for that. Like you can of course there's things that you can't do with intents and you can have asynchronous and arbitrarily fast down to real time composibility and have all of that.

And it's way easier to actually >> Yeah. But but so so I would argue that a really really fast is is is as as complicated as synchronous composibility without automicity guarantees and without the birectional uh uh optionality of it. Meaning that each step is its own thing. It's it's very hard to compose things when each step is has its own latency inclusion time and so on and so forth. Um and so again I think it goes for me it goes back to the question are rollups part of Ethereum or their own chains are synchronous really fast asynchronous composability is equally viable between Ethereum and Solana. So is there no difference

between a roll up on Ethereum and Solana or or any other? >> It's very different. >> It's not equally viable because you get trust minimized bridging between a rollup and Ethereum L1 whereas you stand no chance of having trust minimized bridging between a non rollup and the >> Yeah. But but if you if you're routing all of your messages through the L1 through Ethereum, you will have really high latency. And so you either choose real-time asynchronous message passing which does not pass through the L1. And so you do have some trust assumptions or you pass it through the L1 and then you have at the very least 12 second latency between messages today or six message sixc message latency in the future

hopefully when we shorten uh the uh um the slot times. >> But you don't have long latency though. You don't need to wait like it's sync versus async is merely about the devx like it's better devx for synchrony right but if you are able to zk prove an L2 in 6 seconds on average you can go instantly the L2 just needs to reop together with the L1 to be able to have a view that's current into the L1 like these are questions let's not confuse the different dimensions >> no but it's not exactly the same Because if you want to have zk, you need to settle them. It's not just enough to

have a zk proof of something. Um especially in the in the way um rollups are built today, you have to settle them first in order to have that finality you want. Um >> no, no, no. You need to be able to create a proof that's going to cost sufficiently little gas on the L1 that you'd be able to afford posting it on every block. >> I agree. But but then you're ti tying yourself with latency of the L1. And again, every message is >> but but that's a really big thing like if you need to every message to wait six six seconds it's really a lot of time >> and and and that's thing number one.

Thing number two is not a single contract today on Ethereum is built for a synchronous message passing. All of them are built for synchronous >> advantage. Yes. >> Yeah. But but that's part of the single execution environ for for Ethereum. Is is Ethereum one big thing or not? Um, and so I'm not again I'm not against a synchronous match pass. I think there's a lot of value to it in specific things. Interop is not one solution as as anything in life. You probably need a a tiered system to solve interrupt. Um, but but I think that it's it goes beyond what uh we're trying to focus here on use cases flash loans not flash loans.

It's about DevX and UX. What exactly are the story we're telling for the our users when they move between arbitrum and base? Are they moving between two different chains or they're moving it between two diff two domains within an Ethereum ecosystem? That's a really important u philosophical question to ask and and I think that um again I I going back to the example they gave before tempo and arc. I think there those are cautionary tales we need to take into consideration because it's very hard to launch an L2 and so the difference between launching an L1 and an L2 is very minimal today. Um and the reason why is because there is no composibility to speak of uh in the sense that if I'm launching an L2 I'm

alone. I'm I'm an island and it shouldn't be the case. Uh and so it goes back to UX Devx uh L2 um innovation and competitive experience uh power contract interact with other context all of those things speak synchronous composability um and and and and and I do urge everyone to kind of I know it's it's a lot of time but synchronous composability came a really long way since you know two years ago or even one year ago um and so not all of those assumptions are are correct.

anymore. I think that we we've simplified a lot of different things and we're continue to simplifying things. Um even to even like the past week we internally found a way to move assets without wrapping them. So for example moving USDC between rollups without wrapping it uh using really interesting kind of liquidity provisions on a bunch of rollups and because you have automicity you can do that without automity you cannot. So things are improving all the time. kind of my my my my kind of thing that I wanted to to kind of do is is to make everyone aware of the advancements and also allocate time and resources to continue developing it. Uh because this in my opinion this is a really important

component of of future Ethereum we should we should kind of consider. >> So we're running out of time here. Um I think this is a great discussion. I would love to continue it. Um, yeah, I I think there's no question that this is worth more investment, exploration, discussion. I agree with Alan your earlier point that interrupt is almost certainly sort of a multi-tiered or require a multi-tiered solution. There's not going to be a single thing that comes in as a silver bullet that magically solves interrupt for Ethereum maybe, but I haven't seen it yet. Um, and yes, to me, there's no question that we need to better um yeah, continue to explore things here. I'm very grateful to have you and and everyone else on

this call that is that is pushing pushing us in this direction. I think we should keep pushing here. Um and I think we need to maybe continue to better at least from my perspective better define the things that are really truly only possible um in this synchronous world. And it it's it's like it goes into this sort of broader philosophical and prioritization. I think this is kind of where it starts to get a little bit messy of a conversation. But um I would love to continue the conversation. So yeah, let's do it. Any any other quick final thoughts?

Otherwise, we can end it there. Awesome. Okay. Well, thanks so much. Thanks for the new people joining and yeah, we'll see you all on the next call. >> Thanks. >> Thank you. Bye, guys. Bye. >> Thank you everyone. >> Thank you. Bye. Bye.