L2 Interop Working Group #12

Transcript

get started. Welcome to the interrupt working group call. This is call number 12 in the series. Uh we have a few presentations today and some good updates. So I will share the agenda in the chat and if you're watching the recording, this is issue 1626 in the PM repo. Awesome. Um we'll starting off with Jacob and Boundless. >> Yeah. Um, can uh everyone see my screen?

Perfect. Um, yeah, thanks for having me on. Excited to chat about sort of like an effort, you know, currently going on in the boundless ecosystem to sort of um help move more trustless interop forward. Um, who am I? My name is Jacob. I'm the product lead um at Boundless um where we're sort of you know trying to democratize access to CK infrastructure and just make it in general easier to use. I think we're all familiar with ZK at this point. It definitely hasn't been the easiest thing to use for the past four or five years, but we think, you know, we're making strides and hopefully making it more accessible. Um you know, might have seen us on Twitter. Um if you see berries, that's that's probably us.

I apologize if it's overwhelming um at times. Um but here's a quick diagram of what boundless actually is. Boundless is a set of you know just like onchain offchain um and a novel cryptographic primitive that again just makes CK infrastructure. Um happy to chat offline more about people that are interested in using it um but don't want to get bogged down in all the details right now. Um here's um sort of where we are in our journey. Um, we went to like mainet beta a few weeks ago and a big focus for us was, you know, we have this new piece of tech. We want to like try to help solve an open problem instead of, you know, just having people send sort of like fake proofs to the market and whatnot.

Um, and we wanted to attack this problem which I think this group is going to be really familiar with, right? Like it is really hard to read the state of Ethereum unless you're running a full node. Um you know in the past this has um forced people to use alternative solutions which are not the most trustless. So you know like multi-igs um oracles and then there have been some great attempts at you know some light clients um with this. So people have tried um Helios which is a good attempt. The economic security does not match that of of Ethereum. Um and this is you know sort of what we set out to do and solve. And we've had uh what I sort of refer to as the ZK sizzy uh occur. And

first of all, if there's one thing to take away from this um presentation, it is the word sizzagy. Um it's an alignment of celestial bodies in three 3D space. Um and we've had some great things happen over the past month. So we had, you know, a new version of the RZRBM come out. It's now 5x faster. Um you know, I'll give you a sneak peek. we might get a similar performance bump with v3 which we're planning on releasing in the upcoming months. Um the next is the balance market. What really is happening here is we're moving from ondemand AWS cost which is what we've historically priced people at to onprem um hardware where these you know providers are now in regions of the

world where electricity you know at times is even subsidized by the government um which we're seeing you know it's sort of insane like another probably magnitude in in cost reduction. Um and the last and probably most important uh and is now my favorite EIP ever um which is EIP7549 which took attestations um out of the sync committee um which then reduces the amount of signatures we have to validate when generating these proofs and this was a 100x you know cost reduction for us um which we love uh we thank anyone that worked on that. Um so the solution right that we sort of come up with here is what we're calling you know formerly is the signal um Ethereum

now originally was called ZCasper but it's this full um validity proof that an epoch has been finalized um in Ethereum. Uh we call it a a full ZK consensus client. Um we're not running the full like you know beacon chain um client within the ZKVM like we're not doing the STFs. So it's really more of like a full finality client. The reason why we say it's a full ZK consensus client is because you are um you know checking the full validator set. So you're having the same validator set that secures Ethereum um you know back these proofs as well. And the output of this program is you get that checkpoint block hash uh and you

are guaranteed that this is a checkpoint block hash um at the end of two epochs in which the epoch two two uh two two epochs ago is is finalized by that validator Ethereum set. Um the TLDDR right we're just taking Casper finality gadget running it inside of a ZKVM checking that the exits entries are are being dealt with properly and updating that. Um the good thing here is okay you have this like block ash and we have this other library that makes it really simple to interact with this. Um we have this library steel where it you know essentially makes it you know easy to run solidity code. So we use alloy we transpile that you know EVM bite code into risk by bite code so it can run in

our system. So now you know solidity is obviously very good for interacting with onchain state um and doing version like that. So you can sort of take that existing logic um take that ingest that you know verifiable block hash that we generated with Casper um and then compute over that data. Um so in practice this sort of looks like okay I'm going to take these proofs I can take um this block hash to any chain um regardless of an L2 or an alternative L1 um take that verifiable block hash and start computing over Ethereum state um not just over what that current block hash is but we also have the ability to look back in time um so you can look back all the way to Dencoon currently um you can look at events within these

blocks as well um And you can do ranges. So you don't have to just look at one single block. You can sort of look at events over a range of blocks as well to sort of what I call endlessly compute over Ethereum state regardless of where you are. Um and the cool thing here is that it doesn't stop at Ethereum. Um we wanted to start with Ethereum because it's been a long known pain point with some of our partners. Um to be honest, it's the hardest one to do. um not from a cost perspective but from a technical complexity perspective. I think we've all dealt with Ethereum consensus in the past. It's complicated. Um big shout out to the multiple consensus teams we talked to. Big shout out to the multiple

people at the EF that helped us um in this process. Um but the good thing is going to an LL2 can be actually much easier. You're confirming much less, right? you're like sort of just verifying that a um sequencer on that L2 is signing off on blocks and they're they're including in the DA layer. Um and we've actually started to prove some more chains already. We just haven't publicly announced it yet. Um but we're hoping to make those available as well. Um, and again, you know, I think in the past ZK has been more expensive, but we're just having this cascading compounding effect of improvements with, you know, open markets and and better software and, you know, possibly like A6 FPGAAS that even now to prove these rollups is not too bad. So this was a

metric you know we took last or in March which is probably already outdated and I should update this and you know we're proving a base transaction for 1/100th of a cent um so it's starting to become economically feasible and and with the boundless market we can sort of subsidize these these costs for people to start using um before and sort of what we envision with all of this um yeah I I can answer questions at the end um so and sort of what we envision all this is you know I if you remember a few years ago there was like sort of this vitalic blog post um around the proof singularity once we start proving a chain we can sort of combine the these proofs um and imagine you know we're proving arbitrum one in Ethereum

mainet we now have one proof that represents that state and if you have that proof on OP mainet you can now start talking to both those chains in a trustless way just by reading this this block hash um so we sort of prove a chain and now you get out outbound gateways to every other chain. Um, so we think this, you know, can lay the foundation for, you know, more trustless interoperability. Um, a bonus here is we can start to get sort of like clients for each chain, which we find interesting for wallet providers, less relevant to this group, but you know, if we paired this consensus proof and execution proof, technically you could verify this proof in the browser. You can actually do this on our website

right now. um and you're now, you know, tracking that the Ethereum validator set is, you know, honestly, um providing you block hashes and whatnot and can be safer for for wallets possibly. Um so we think, you know, with this we reduce bridging cost by, you know, not having to pay sort of like fees on on um multi-IGs and whatnot. We reduce trust because you're not trying to you're not you're now trusting the validator set um and our ZK system to be fair, but not a small group of people. Um, and we think we can start to open new applications, you know, doing crosschain queries and and whatnot. Um, our commitment here is to maintain this fully working CK client. Um, to operate operationalize it, um, which we're in the process of

doing right now. Um, we want to audit maintain it. So even in the next fork, um, we'll continue to work. Um, and then we're actually going to try running as a public good for as long as possible. We ran a little donation campaign and we raised over 900k USD to um cover the proving cost. Cool thing is on the market right now. Uh people just do them for free. Um which is which is really nice. Um and then we also have this additional you know mainet incentive that will help subsidize proving as well. So you know it's really hard to say how these costs will adjust over time. Uh it is an open market. We don't control it. So, I can't like, you know,

fix it or or anything. Um, but I think at this point I I'm willing to say that these proofs will be up and running for at least the next year. Um, and that might be, you know, just being underestimating everything. Um, you know, we're working with a great set of partners as well. Um, everyone on this list is is interested in integrating it and supporting us. Um, and we're pretty much open to working with anyone at this point. So if you want to, you know, use this, I'm in the this interup group. Feel free to reach out to me. Happy to provide an API key um and assistance in in integrating this into anyone's protocols. Um yeah, that's the that's the presentation. I can start

going through question or >> Yeah. Um so what so yeah what are the latencies of the proofs? Um great question. So currently most of the latency uh at full tilt actually comes from the need to wait 12 minutes for an epoch to finalize. Um I am personally a huge fan of uh three slot finality for this purpose of of improving that. That is just my opinion. I understand you know there's trade-offs here. Um, but that is actually most of the latency. The cool thing also is we're not actually proving

bound on any giant proofs anymore. We're we're bound on execution. So the execution for this proof at max tilt takes about uh 12 to 12 to 15 minutes, but you can sort of start that before the epoch finalizes and whatnot. We do have a set of improvements coming that should greatly improve this. Um, we're releasing a V3 really soon that gives like a 3x bump to the um, executor performance and then um, Jordi Bina and the ZISK team have done just phenomenal work around this and we're huge fans of what they're doing around like getting this execution up to up to gigahertz essentially. Um, which could reduce, you know, that 16 minutes of execution down to just a few.

But yes, definitely is a trade-off with this approach of you need to wait the 12 minutes for the epoch to be finalized. Um, and I understand that's that's >> and another 15 minutes for the execution or why don't you just execute continuously generate traces and then prove? >> Yeah. So, we can paralyze essentially. So, it would be a three minutes. Uh, that feature is not in it's in a PR right now. Um, but yeah, great point. Um, and it is a trade-off when using this um stuff. What's the proving time for a 30 million gas Ethereum block on an H100? Um, so with these proofs, we're we're really that the the gas of a block does not change anything because the 95% of

the proving time just goes from checking the the million validator keys. So the proofs regardless of of block size are pretty similar. um I think they fluctuate 1 to 2% up down right now in total psycho costs but it's um that thank you for the kind words heart um for the L2 proofs um that will then be dependent on execution size um currently you know we can do a batch of I think a batch of uh maybe like I I think it's like 150 blocks on base right now is 20 billion cycles. So that

would take um 5 to 10 minutes if you started reducing the batches. Like let's say you just want to prove like one block that a transactions occurred. Um that is probably getting around those real-time proving numbers that you're you're seeing around. So 8 to 10 seconds. We should have more clarity soon on what those actual numbers are. We actually just got our like data center set up. Um, we'd only been running stuff in the cloud and we're hoping to post some numbers around that that soon. Um, what's the best? Yep, that's my Telegram. Feel free to reach out. Um, nice to see you again, Jim. Um, do you match old light client API basically JSON RPC supported? Um, we don't have

any out ofthebox JSON RPC support. Um, right. What like how easy to migrate from Helios? Okay. So, yeah. Yeah. Um, so we actually are working on this as well. So, we have the proof and we have that audited what I and we're trying to like get the times down right now. Um, but we also are going to provide an EVM contract um where you could sort of like set an anchor. You have to set like a trusted anchor essentially just right with any other lay client. Um, and then you'll just like upload those. If you are on a colllocated chain of a boundless market, you actually don't even have to like verify the proof. You could just like call call the auction where where it's occurring. Um, if it's on a chain that the boundless market is

not on, which is not on many right now. Um, you just have to grab the proof from the market and submit it yourself um to the chain. So, we're we're really trying to like I mean I I'm a product person. We're really trying to like get the full out of the box solution. Uh I'm also you know completely open to feedback on other things that might be useful to to make this more usable from you all. Um what's the latency for just the EVM? Oh no answered dreams shorter batch submissions. Yes 100% aligned. Um, yeah. Any any other questions, sweet. Um, yeah, thank you guys. Again,

this is really short. Happy to answer any other details. And again, we really just view this as a public good for the the Ethereum ecosystem and wider. um that's there's not really any like catch. Um you can see the the proofs being generated on the market um right now and we just want to get it in the hands of as many people as possible. That's the that's the dream around this. >> This is great. Thanks so much, Jacob. Maybe we can have you back in a in a month or two for some updates on on how things are going. >> Yep. Yeah. And uh yeah, just reach out to me if there's any feedback or or things that like might be interesting for people to use. I'm all ears uh to make it as easy as possible to use.

Awesome. Cool. Up next on the agenda, we have some updates on the open intense framework. Maybe we can start with Pepe if you're available. >> I am. Hello, Jos. Thank you for the intro. So, sadly I don't have such a fancy presentation as Jacob. Sorry for that. I mean that's the problems are going second. I guess so I will assume a lot of you are already familiar with the open intense framework but just a quick summary um is basically as a way to standardize intense um to facilitate interaction between clients solvers and different

people in the in the ecosystem in the space. So it's been going for a while. It's a public goods initiative as well where different companies are collaborating. I see people in this call that I've been meeting and and having conversations with um in in different groups. Um and I want to share a little bit on the current status and progress because we are in a very pivotal point uh of of the development. So first we have been doing or suggesting some changes uh into the 7683 standard which is basically optimizing for performance and completeness. So I'm not sure if anyone here or checking the

recording is actively using this standard or similar ones or are considering using this standard. So if you have a wallet or a crosschain product, feel free to reach out because we really want to check that all the changes we are doing are going towards like something practical and useful for everyone. So uh it's now your opportunity to really adapt things to make your life easier and we want to make it happen. Um, aside from the standard itself, we are working on a set of tooling for the ecosystem, the main one obviously being the solidity contracts um, as a reference

implementation and as as a core element in the ecosystem. We already talking with partners that are interested in in using these contracts and therefore we've adapted them already to be very modular. So we are very confident in the capacity of of the current architecture to a scale to different use cases um from like crosschain swaps uh payments and any kind of spec specifically crosschain utility can benefit from this. We are also working on some off-chain systems. Um the most clear one being a reference

implementation of a solver. So very quick summary of what an intent is to to be able to understand this. The user will say I want to receive 100 USDC on base by giving 100 USDT on Ethereum. So someone will pick that intent fulfill it and once that fulfillment is proven then they will unlock the the money deposited on the original chain. So there are different players in the space. Most of them participate in this forum. Um I see uh we have across we have like more people in the in the space. Um but we are creating a baseline solver so that

new chains, new ecosystems can on board fully by like their own um cloning this expanding in a modular way and having a basic solver. We obviously aim at this being competitive and good but it is not a direct kind of competition of taking out the different players in the space. The OIF is an open intense framework and that means that it it will empower everyone in the in the ecosystem. Along with that the the that solver we are also standardizing some APIs and building SDKs around it. APIs mainly now for offchain components. So you probably

caught up uh if you want to send 100 USDT from Ethereum to 100 USDC on base there will be a fee somewhere. Um, in order to get that fee, in order to understand what the different solvers are going to offer you, we are standardizing an API that can connect to those different solvers so that wallets and users don't have to be uh implementing five different interfaces for connecting to the different protocols and rather have a unified one that is fully compatible with with every single player. Um along with this obviously when you get the quote you will get several quotes and you will be able to submit that intent. We are also

working on that along with status updates and more quality of life elements. This when we were talking about all of this we identified the clear need of some sort of aggregation service. So uh we are also working on an aggregator service that is fully of chain to help applications communicate with all the different um players in the ecosystem through this aggregator. This is fully optional. Okay. Like I understand because we internally have also had a lot of discussions about risk for centralization. This is a fully optional model. You can still connect to the

solver or put your intents on chain. This is just a helper element for players in the space that may want to integrate more easily for for their users. So as you can see we are building in different areas. Um I will recommend and I will ask if you are building in this ecosystem or if you are interested in participating uh please reach out to to Joshua to Josh direct directly um he's coordinated a lot of things we can get in touch and the next couple of weeks are going to be pivotal we do have um a pretty good speed in terms of of development and pretty high expectations

for deliveries over the next couple of quarters. So, if you want to join the party, feel free to reach out. Um, we are super happy to collaborate with everyone in the space. >> Thanks so much, Pepe. A great update. I think we have one of the other key OAF contributors in the room. Jim, if you're available, did you want to share anything? >> Yeah, I mean, I think Pepe said it the best. Um so I won't kind of uh repeat it but yeah if anyone's interested in collaborating um I think we shared some details there and we'll we'll certainly refine the process. I think just like some more tactical updates on our side um we have been working on um having the OAF support the finalized 7683

uh specification. So that's been a a big effort for us. want to make sure that that comes out of the box and of course we're adhering to um standardized interfaces um across the whole ecosystem. And then the second thing is that we are also working really deeply uh with the Wonderland team and on the Kohaku wallet. Uh I know a big kind of requirement has been multi-chain inputs. Um so the ability to if you have a similar asset on different chains be able to express an intent that basically combines all of that. And I think that kind of solves the issue that um I think we we discussed a few months back around this like fanning out of assets. It's like if you have a home chain but you

start doing a bunch of intents on some other chains, you slowly start accumulating assets on a ton of other chains that maybe you don't want assets on um you know at the you know in the in the in the finalized state. And so this is kind of just like a simple cleanup method to simplify that complexity. So that's something that we're working hard to add to the OAF because we know it's a huge potential UX problem in the future. >> There's a question from for Bree in the chat. Um maybe I guess I could try to answer maybe Pepe or Jim.

>> Yeah. Uh let me open it. Uh is the plan for to support nonvium chains from the get-go? Um right now for like the very first milestones probably not since the main implementations for the contracts are in solidity but we already have in the code base I think mostly inherited from the fi oracles from like bitcoin for instance. So the standards the concept is ready. If a player or like in this case if Coinbase were to be interested in none EBMS I'm pretty sure we can have the conversation to like adapt road maps timelines and and priorities to to accommodate for real world needs.

Pepe, I might also add to Frisa's question. Um, there would be a need to like create a 7683 standard for non EVM 2, like like an SVM standard, which I think is a new thing. I don't think anyone's created like a standard across EVMs yet. Um, so, uh, I'm excited to do that. I think it'd be fun. Um, but, uh, yeah, for I think there's there's something that should get done there and it's very much on people's road map. It's just uh kind of a new thing too. >> Yeah. Just just for reference, our aggregator implementation is using um the crosschain standard address. I don't remember the

exact number uh of the standard but it already is prepared for Bitcoin, Stellar, Cardano, other ecosystems non EVM based Cool. Okay. I think that was a solid update on the OAF. Unless there's anything else, we can keep on going.

Next up, I think we have some words from T1. >> Yeah, thank you so much, Josh. Thank you guys for having me again. Um, I'm super uh happy we've just had Jacob from Boundless because at T1 we are trying to also find a niche on the whole spectrum of tradeoffs between like this super hardcore native interoperability and uh the full on trust me bro models. Um and uh this is um I think basically uh in the same vein as Jacob's assumptions. Hey, how can we make um

DAPS living on this one L2? Maybe one that already exists probably base on or arbitum or or super chain or whatn not. talk to adapt living on another L2 that already exists and and and be realistic and pragmatic about it today and not hoping that all of the big L2s adopt our fancy based and and uh native um rollup um architectures tomorrow. And so we try to um bring that about in a slightly different um manner where we instead of focusing on trustlessness with ZK uh where we um like like I guess boundless

try and um bring uh block hashes from different L2s into your home chain. we instead focus on this trade-off spectrum on being fast and uh um I guess nowadays when when when you say fast you can't really have this aspiration of waiting for finality from the perspective of the L1 that is the 12.8 8 minutes uh for an epic finalization if you want to have a real use case alla 7683 um you know couple of seconds of delay for bringing stuff crosschain and so instead at at at T1 we try and uh find a

way of bringing about what what they would call permissionless interoperability or optinfree um composability ility between existing L2s and the L1 via having some metrics of when do we deem a certain state in a certain contract on a certain chain is sufficiently finalized and we expose that to some sort of shared infrastructure crosschain infrastructure and this um shared view we aim to actually prove to the L1 in every L1 block. So, um the idea here is that if you are able to have your um

crosschain infrastructure layer reorg together with the L1, if the L1 ever were to reorg, you don't need to wait for L1's finality to credit uh for instance um deposits or to credit any events that you listen for on the L1 to your chain because you know you will or so it's fine. And so the only thing you still need to care about is proving to the L1 the thing that happened in your chain. And so we try and make this possible via using TES that actually are able to prove basis and arbitrums and optimisms um state to the L1 in a matter of uh

milliseconds rather than uh 15 minutes. And so yeah, the whole idea is instead of the current um infra um situation where we have those different rollups and we can go via the L1 and have a full on native interop but at the expense of waiting for for hours basically or only being restricted to having solvers fill very application specific intents. We want to create this layer that would uh have a view into other rollups and convince the L1 about its view of the other rollups.

Uh now yeah what is interesting about this approach um I would say an interesting item is the um how to make this secure and so um of course the can be broken and they will and so you don't want to just have a TE convince DL1 about arbitum state right arbitum holds um a lot of TVL and you want to enable your users to be able to tap into it without being bound by the security of a of an enclave. And so to that end um we came up with this idea of having um different roles for people who are

running maybe just a sequencing node that uh orders transactions and is econ cryptoeconomically secured using something like ABS and then there's a separate role just um uh executing those blindly sequenced transactions that are for instance Hey, bring me this arbitrum contracts um methods output for a given arbitum block into the uh crosschain liquidity layer and uh they would be doing this within a trusted execution environment but in a way that's reproducible. So the critical item here in order to actually be able

to apply cryptoeconomic security is to know what the output um is supposed to be in a deterministic manner such that if someone breaks this determinism, they be able to to be attributed this fault to which enables you to slash them for instance. So detect it after the fact. And this is unfortunately something you can't have with confidentiality with using um for instance TEES for confidentiality because leaking information is not attributable but uh claiming that arbitum's smart contract ABC had this output at this block height is an attributable offense and so this

is a second role that you can envision where um a cryptoeconomic budget can be applied and now your otherwise this glass ceiling for security would be the uh the stake and so you don't want to be bound by that either and so um in this design I propose a trade-off that kind of complements boundlesses maybe and that we um only require as DKP of a um state transition in in the system once the value at risk approaches the cryptoeconomic security budget. And so this enables the system to proceed under most

circumstances and only every now and then require this like super strongly aggregated ZKP to reset the value at risk counter. And it would only need to be halted should some situation some user um require a very very valuable set of transactions to happen very fast one after the other. And so yeah, this is uh the idea I wanted to present to you guys, get your feedback, get your thinking, and my aspiration is to try and uh fill all of the uh potential niches on the um kind of spectrum and hopefully have something for every app's needs.

>> Just one quick question. >> Any questions? >> Yeah, sorry if I missed this. What is the next big milestone for you guys if you're able to share? >> Oh yes. So um the next big mile for us is actually going to be bringing what we have live on testn net today a an ERC7683 um test net that allows fillers to be repaid roughly in a matter of seconds rather than the otherwise common 1 hourish uh delay to mainet. So bringing that to mainet um and uh this is just a demo of what you can do with a primitive um of this sort where basically any developer

may require that T1 bring any fact about any supported chain um to their home chain. And so one way of using this primitive is to convince an 7683 escrow contract about the fact that the fill happened on the foreign chain, right? Um and then the second big milestone is going to be expanding um the use cases or like adding more uh use cases that in particular allow developers to require rights to happen in this asynchronous way in this best effort way that is um fundamental barrier to not having a shared

sequencer. But that seems in my um estimation to be a good tradeoff in terms of uh feasibility. >> Victor, >> Victor, you have your hand raised. >> Yeah. Um can you guys hear me? >> Okay, sure. >> Yep. >> Very good. Um yeah, my question basically is like you mentioned the idea of of requesting ZKP when the value kind of like at risk reaches some kind of crypto economic security budget threshold. Um what I was thinking about there is in addition to costs which kind of are definitely non-trivial but also kind of lower than we expected maybe a

few years ago. Um there's the latency uh considerations as well which are not which I think the latency I'm really thinking about is kind of the one I'm the one we talked about earlier which is like if you want to read from Ethereum L1 and you want to use a CKP to do so you don't really have a way to do so unless until you wait for finality or you maybe you accept a smaller subset of the consensus set like a smaller attestations but then you don't get the same security guarantees basically the cons consensus itself health has a latency that seems like it would be >> um going beyond the thresholds that you're trying to achieve with your architecture.

>> Have you I guess what your thoughts on that so I question? >> Yeah, ex so let me paraphrase if I got it correctly. Um maybe you can have this like fast interop with the L1 but you will be bound by the fact that the L1 needs finality because otherwise it could reorg. Is this is this a part of the question? most fundamental power as well, which obviously you you could you you you discussed addressing that by the idea of having the L2 reorg with the L1 and I guess >> I'm curious what your thoughts about how that plays with the kind of um ZK as needed way of doing things.

>> Yeah. Okay. I see. I see. Yes. So um yeah, how we treat Rios, we reoke together with the L1. So that's kind of doesn't work for the real life, but it works for chains. how we how this is compatible with on demand CKP is and the nature of this variant of a kind of multi-prover system I'm not suggesting an architecture like Vitalic and Medam and Serge and Tao people are suggesting when it comes to combining TE and ZK to mean hey we need um some quorum so that we deem what they say as true. Instead, what I'm suggesting is we trust the TE

and to be precise, we trust the quorum of uh stake rest towards the TE enabled AVS up until what the rest slashable stake is. And uh as the system detects that the statements made based on this trust level are becoming so valuable in aggregate that they would soon exceed the cryptoeconomic budget beneath it. The system would incentivize market participants to voluntarily also submit a ZKP on top. And if the ZKP ever

is submitted, it would reset the value at risk to zero. And it may never be submitted at which point I think the situation you might be having in mind would happen where the system would need to halt in order not to exceed the cryptoeconomic security. So the idea TLDDR is let us only require a ZKP when needed. where needed is based on a cryptoeconomic calculation and we try to make it rare. >> Yeah. And that makes sense. I think what what the core of my question may be like it's not clear to me what that ZKP attests to. Um so for example like in the boundless case we're talking about

the basically with the signal um attesting to the finality gadget going through. So the Casper finality gadget we're is what we're running versus in this case if you haven't reached finality yet. It's unclear to me what you would use ZK to attest to. >> I think Josh might be signaling we have three more speakers to go, but I would love to take this offline. Please hit me up on my Telegram or my Twitter. I put both links in in the chat. Thank you guys.

>> Thanks. Yeah, sorry to cut you guys short. Uh, cool. Up next, we have route scan and interoperable addresses, aka chain specific addresses. Hey, Jack. >> You're muted if you're talking. >> Oh, yeah. Sorry. Can you hear me? >> Can you see my screen? >> Perfect. >> Okay. Yes. So um we um as as block explorers we we are heavily focused on like and and watching how the um you know the Ethereum interrop is is

going forward and also we we've had a lot of issues in general uh when it comes to um indexing more and more chains especially under a unified uh interface which we have. Um there were some issues that I also uh you know commented on the specific um on some on some specific um uh ERC that's been added or that's been you know merged as a draft and um and so I um you know I thought the best idea would be to actually you know get in and dive deep onto some to give our feedback and so that um the um DRC's are aligned not only to wallets,

SDKs and infrop providers like RPC providers but also for um block explorers that need to ultimately show uh analyst users and developers what's happening and help them debug. Um so after you know after um interropolis >> real quick I think you might need to adjust your screen placement. I can kind of cut off right now. Oh, >> can only see half of your screen. >> Better now. >> No, maybe.

>> And maybe make it full screen or something. It's because your screen is huge. >> There we go. Okay, this is better. Still small screen, but >> let me let me see. Let me try and change. Oh, yes. Can you hear? Can you see now better? >> I don't know why it was simply um sharing the the whole screen. Okay. So um so as I was saying um we were um we're actually looking at u many that account for inter addresses crosschain addresses and I believe the most one the the biggest one that I believe is not um you know uh considerable valued as much

as we block explorers want to is 77785 that it's um onchainident onchain identifiers for for chain NADS and um and so we right now we're trying to understand how to um you know um make it interact with all the other ERC's especially ERC 7786 about you know the standard format for crosschain messages and the idea would actually be to um like establish the best way to um unify the um unify are the interface of the 7786 that is now being merged a few days ago I believe um

with with what is currently the draft being added of the ERC 7785 um and uh the main issue about this discrepancy is that 7786 takes into account that um there's um there's a simple like no and definition um given to chains like arbitum.eth for example um but there's no way of classifying those chains. So um if I want to send Josh um one E from OP mainet to um to um arbitrum let's say I can say joshe at

arbitum to send it to Josh in a human readable manner and that's what 7786 um and 7 um 930 um talk about. But what it is isn't talked about and it isn't discussed and described in the in the specifics is actually uh what is the second part of the second part of the address. So we all know that interruptable addresses need to be like we need to have a specific routing for different chains and we need to know how to choose between like for example which USDC we need to um we need to um choose from an array of of possible USDC that I have on my wallet. Um and of course um we need

also to account for the fact that um the the destination address and the destination chains need to be clear from the user side of that site. But um and so this 7786 and 7930 solve most of these problems. But the thing is we are have a chance through 7785 of like solving not I mean I don't don't necessarily mean solving but like solidifying what is now a very precarious method of classifying EVM chains and possibly

beyond EVM. Um because right now um the classification of chains like which which chain id you do do I have um which RPC and box explorer link is maintained through a GitHub repo that it's not actively maintained but it's just open for maintenance when a new when a new chain comes in and adds a PR uh using their data and um instead we have a chance through 7785 to actually um use ENS or a specific uh naming maybe a genetic naming naming service to create an object of a chain because an

object of a chain has their RPCs. RPCs has a name, a chain ID, uh some other genetic identifications that can be nonem or EVM. It can have like a specific at destination that that solves to how many block explorers are there and it solves to how many um RPC providers what's their name and um and all kinds of stuff that right now through 7786 and 7930 is not um is not um you know discussed because it's simply a um 7930 is simply a chance to say arbitum is this and that's and

that's it. Um but 775 is actually could be seen as a dictionary for chains and when it comes to EVM adoption um and and we we've been uh you know we've been struggling with this because we've for the past six months we've been working on the state of the market report by you know accounting for how many developers are using and developing how many chains. Josh you have a question. Yeah, sorry to interrupt and yeah, sorry to be Yeah. No, no, but I just wanted to um Yeah. see if just want to flag that maybe we only have one or two minutes left for this. So, if you wanted to get to another part of it.

>> Yeah. Yeah. Yeah. Yeah. No, it's just it's not specifically like it's just this is just the article and of course you can see this in the in the in the link that has been shared with the agenda. Uh but uh but the main idea is for for also routes scan to start to champion 7785. So so they can it can really be like this dictionary of chains that can then be used by by any provider. It can also be used to do um heavy research about like what's actually the state of EVM chains being developed and what is actually the EVM adoption. That's now a uh open questions open question I believe. So yeah thank you. Thank you.

>> Thanks, Jack. That was a great overview. Much appreciated and is a good segue to what we're going to talk about next. And we may have time for questions at the end. But um yes, we have the Unruggable team here as well as Wonderland. But maybe we can start with Unugable on their work on the 7828 resolver. And yeah, apologies. We don't have a lot of time, but see what we can get to. Hey everyone, my name is Martin from Unraul. We're an independent R&D firm within ENS.

And um the work we presenting today is part of our research, our interop research uh with a specific focus in ENS based identity. So I am here to talk about um EIP7828. Um just going to share my screen. Um just a second. Sorry.

Are you able to see my screen? >> Yep, we can. >> Oh, good. That's so I think I'm going to skip uh most of this because um it's been covered in the in the previous um presentations. But yeah, basically EIP7828 introduces a chain specific uh human readable addresses and um this is powered by ENS IP11 and um ERC 22304 which basically allow you to resolve a

certain identity to a specific chain that is you know um vitalic. on a very on a on the base chain and um this spec is powered by ENS infrastructure. So what uh what the resolver really does here is that it works with the coin types that have been specified by ENS um ENSIP11 that is for EVM chains and uh BIP 44 constants for nonem chains to get such uh coin types that is um for example Ethereum you'd get a 60 and

polygon 966 and you'd supply this along with an ENS identity like vitalik. Uh this person's specific chain uh identity. So what I wanted to present today was um the resolver. Um, we have the ENS7828 resolver that uh we've built and it's basically a library that allows you to visualize and um just play around with valid 7828 addresses.

Um, and it works with a centralized uh chain list repo at the moment to resolve these addresses. And um at the moment it's compliant uh with the spec and uh yeah what we really need at the moment uh I guess the ask coming into this was to find uh people to collaborate on this with along with 7785 as we move um 7828 from a centralized registry that's chain list um to having a decentralized registry. So um if you want to have a look at you

know the spec play around resolve some names see how it works feel free to just uh visit the repo and um yeah contribute uh and yeah open any issues you find as well and we're looking forward to any collaboration with some of the guys on the call routes and Wonderland to work on these um initiatives which are really just uh quite important to the interal road map. Um I'll stop there. Thank you.

>> Thanks so much. Uh so we only have two minutes left. I think we have the Axel team here. Um Axel, but if um yeah, we can we can spend a minute or two here or we can wait until the next call. Maybe I'll leave it to you, Ash, if you're >> Yeah, we we can do a super quick thing now and maybe we could dive more into the tech on the next call, but we could just do a quick demo thing right now. >> Yeah, that'd be great. >> Uh, hey everyone. Yeah, Ash from Axel. Um, building stable coin savings accounts. Super consumerf facing and love all this tech. We did a lot of stuff with Intense over the past few months and recognize a lot of the people here. I'm going to shut up and then we have Dev on our team who can do a super

quick demo and talk through it. Lots of stuff with tees, lots of stuff with 7683. why 772 wallets are better than smart accounts, stuff like that. >> Um, hey Ash. Yeah, thanks. So, uh, yeah, we were using 772 wallets using alchemy uh to batch all transactions together. Uh, for our previous product, we were initially using uh we were initially using sequential processing and also uh and also EOAS. So, we had to take account of all the gas. So this was the most convenient thing for us. I'm currently into these positions. I'm going to just withdraw and uh we're seeing transaction times of 300

milliseconds uh end to end. So I can already go to the block processor and I know that um these have gone through. Additionally, the volume that we can transfer through this uh through this architecture is beyond insane. We deposited around 100k USDC and it cost us 1 cent for for the entire process. Um this is in conjunction with our uh belief that every user should uh be able to export their wallets. I don't think you'll be able to see this but uh we can export private keys and users will have access to all of these pools. So if they go to Moro's website and log in through the wallet that they export through us, they'll be able to um do anything that they want to with their wallet. And the

way we're uh detecting wallet balances is we're uh parsing all ERC20 and ERC 4626 logs so that we make sure that all these uh all these actions even if they happen not on our platform are caught and uh we'll have an accurate an accurate depiction of the user's current status. Um so yeah, this is honestly like insanely fast. uh we we were surprised by it and uh I think we can handle up to at least uh at least a few thousand users and in concurrency uh if if you want to uh if when we did test testing. So yeah, that's all.

>> Perfect. Thanks. If you want to drop your contact information in the chat and people can follow up with you async. >> Thanks so much everybody for joining. See you next time. >> Thank you. Bye. >> Thank you guys. Enjoy. Bye-bye.