L2 Interop Working Group #10

Transcript

started. Uh, cool. This is the inter L2 interrupt working group call number 10. Shared the agenda in the chat. We have three main agenda items today. Starting off with a presentation from Bconomy on uh enabling gasless one-click Ethereum. Uh after that we have an update on the Kohaku wallet which is a prototype wallet for interop and privacy being worked on by the EF and Wonderland team. And then last up we have uh discussion on base rollups and how they potentially fit in into the general sort of interop acceleration

uh work happening more broadly in the Ethereum ecosystem. And we have a few uh special guests coming uh who will present their thoughts on based rollups. Cool. So uh yeah, let's kick things off with Musl whenever you're ready. Yeah, I'm ready. Uh hello everyone. I'm just going to do the classic. Can you see my screen? Yep. Yeah. All right. Uh great. So um got a lot of ground to cover so won't be uh saying too much. I'm Mislav. I'm the VP of product at Bonomy. been working as an Ethereum EVM developer, researcher, evangelist since 2016. So, been quite a while. And this is something I'm extremely proud to

present. It's the culmination of basically two years of my life and together with Bconomy and other people who have contributed on this is basically we call them verifiable multi-chain scripts. These are scripts which are injected into call data and executed onchain. But I'll I'll show you much more about them. uh but what they enable is gasless one-click Ethereum and a few other things but this is what we're going to focus on today. So the idea here is that the web 3 UX and DevX still aren't that great. We've made enormous strides since like I joined in 2016. The difference is now night and day and things things are going in a great direction but signing multiple transactions across chains is still kind of a nightmare. So you go you know

approve plus execute but then you wait for the bridge to complete then you do something on the destination. If there are multiple chains that are you know the destinations then it becomes even more complex. Uh writing smart contracts for simple logic is overkill. I am a firm believer that we are writing way too many smart contracts and that a lot of these things need to be able to be written in in other languages and then injected into blockchain through a scripting engine which which I'll explain and gas management and and transaction batching is still kind of complex and uh for batching I think it's kind of primitive because you you can only batch static call data which doesn't really respond to like changes with onchain conditions. Um the vision

number one make every action a single signature. No many no matter how many function calls chains uh or what span of time it it spans it should always be a single signature. Uh vision number two, make gas a thing of the past. Even for EOA users and I would say even for non7702 users, we need to like really get the entire Ethereum ecosystem forgetting about like manual gas management by by users. Um and enable division number three and this one it might be the most uh ambitious is enable non-contract developers to write like 90% of the application code for any any uh Ethereum application or EVM

application. And so I'm going to show you a quick demo of what I mean by gasless oneclick Ethereum. So you can see here I'm in like the worst case situation for an EVM user. I've got 10 USDC on arbitum that I want to supply to a morpho finance pool which is on base and I need to supply we so I've got the wrong token on the wrong chain and to make matters worse I don't have gas on arbitum I don't have gas on uh base and to make matters even worse I'm using a regular EOA account that hasn't been upgraded to 7702 and so what you can see here now that um we we are able Wait I'm on the local machine. So we are able

essentially to um to execute uh these multi-chain flows gaslessly and orchestrate them across chains. So what you can see now is I have signed an ERC20 permit message that moves my funds to an orchestrator contract. This is a smart account owned by the user. The orchestration across multiple chains is happening on that orchestration smart account owned by the user. And the end results after everything is done are transferred to the user's EOA. I can go to Morpho and see now that I um should should have sometimes it takes a while to update.

But we can check it onchain that I have actually executed two transactions on two chains with a single gasless signature by the user. And if I go to base scan, I can see that I did actually receive RE7 on base. So this is the type of uh type of things that we can achieve with uh multi-chain scripting and and the framework that we have built. Uh where's my presentation? So I'm kind of trying to get a lot across in in a little bit of time. Um so what we do is we change the model from transactions into what we call super transactions.

Super transactions are essentially uh multiple function calls across multiple chains condensed into a single hash by the usage of a Merkel tree. Basically, we hash all the instructions, put them into a Merkel tree, and then the user signs the root hash of the Merkel tree, which approves all the function calls across all chains. This is how a super transaction looks. So, you have payment instructions on any chain. And yeah, very important, this supports cross-chain gas. You can pay for gas in ERC20 tokens or sponsor gas across chains. So, pay for gas on optimism with like USDC on Polygon or or Arbitum or wherever. These are like optimism, arbitum, polygon instructions. You hash all of them. You get this super

transaction hash. When the user signs that hash, they approve all of the actions across all of the chains. Asynchronous ordering. Obviously, if you're going across chains, sometimes you're going to have asynchronous execution where the next transaction needs to wait for the previous one. We do this by the usage of preconditions. So, for example, in this case, the transaction on the destination chain didn't execute until it received a predefined minimum amount of funds. But this was not done by the relayer. This was not done by the bundler or or the offchain infrastructure. This was actually enforced in the encoded call data that was uh that was encoded when we were building this super transaction.

So the the destination chain transaction cannot even execute onchain until all preconditions are met. This is done so that the entire system is trustless and permissionless. Uh this is essentially how the ordering works. You simulate the transaction until it stops reverting and again all the preconditions are encoded into the call data itself. So it will keep reverting until like everything is met and then the relayer once the simulation stops reverting it executes the next transaction in order composible batch execute. So one very important thing is if you do a swap then supply you cannot know ahead of time how much you'll actually get from the swap.

Right? there is me, there is slippage, there is unknown runtime conditions. What we can do in this scripting is intercept any function call and instead of having a predefined parameter like supply 100 USDC, you can say hey supply however much was received from the previous transaction dynamically inject it onchain into the parameter during runtime. And this is basically how it's done. You say like encode composable function data lending protocol and instead of putting the amount as a fixed amount you say give me the runtime ERC20 balance of some token on some account and inject it as a parameter into the next function call. Um ERC these super transactions interplay really nicely

with EIP7702 and ERC7715. Basically, you don't really want these scripts to execute directly on your main account or your EOA because they can access all of the funds on that account where they are executing. So, you want to sandbox the account for security. What you saw in the demo was us actually approving a fixed amount of tokens to this orchestrator account to execute basically these transactions. So, it's always sandboxed. The script can never access more than you actually gave it. Right now we are using like normal ERC20 approve or ERC20 permit signatures. But when EIP7702 comes into play and becomes more prevalent, we can use ERC7715

to request funds from the user's account to the orchestrator account and then execute there. This is extremely extremely secure and it uses basically the browserbased model of like sandboxing requests from applications and showing to the user the maximum amount of funds that any application can access at any time. Um and now this is like very esoteric. We're still not there in in our building but we already have a plan for this. These scripts can be general purpose during complete basically they can include if else conditionals loops schedulings early hold and everything. So anything basically that you can build with like a contract you would be able to build with these scripts. They're not a match for everything that a smart contract is a

match for. But you could like store something to transient storage from the previous instruction, read it in the next instruction and then do all of this. So it's important you can it's all encoded in the call data. So this is very important for me to to emphasize there is nothing happening offchain in a trusted environment. There is nothing that you have to trust beyond the blockchain code itself. The real layer only posts this specially encoded call data on chain but then all validation of like conditionals loops holds preconditions everything is done by a smart contract on chain and we are now working on a typescript scripting DSL where basically it's a very easy way to write multi-chain scripts which are

verified onchain and and execute there but like you write it in a very natural uh sort of like domain specific language which a library in Typescript. We call it abstract.js. If you want to play around with this, this is in production today. Uh we already have clients using this. Go to docs.bicconomy.io. Get in touch with me. I am ox shaman. This is not zero x. This is ox. Uh on telegram and on Twitter, I am ox_shaman. And uh yeah, I have to mention uh some of our core technical contributors who made this happen. Uh and yeah, this is the the end of my presentation. And I hope I was on time.

That was perfect. Thank you so much. Any quick questions for Misov? I had a quick question. Um the first transaction like you said there's no gas. Like where did the gas come from? The user didn't have gas. How did you get it started? So you get it started here in this case. This was a token that supports ERC20 permit. Uh so you signed an off-chain message which permitted the orchestrator account to spend the funds from the EOA and then within that ERC20 permit message we actually inject the hash of the root Merkel tree so that at the same time you sign both the permission for tokens to be spent and

you approve all of the instructions. So this is kind of a let's call it a hack until we have ERC7715 fully available. So we can do it with like ERC20 permit tokens. If the token didn't support ERC20 permit, we can do it by actually appending the super transaction hash to the call data of a normal ERC20 approved call. Then you just need to have enough gas for like approve. You don't need the gas for the entire instruction set. Just for the approval of the token to the um to the orchestrator account. But even then, like some of our clients, they will like just preund that small amount of gas because it's a deterministic amount. You always just need for one approved call and and that's it. Okay. Thanks.

I have a quick one by the way. This is amazing. Congrats. Um my question is on the example you did with the view balance function, uh is it possible to also use the return value of for example a swap a non view function? Yes, you can inject any any anything. So basically you can call any function call or you can get the return value of any previous instruction. So this is now working in a sort of single instruction context. But if if you look in how we usually do it in in our in our examples, we will always say for example execute composable batch calls, there will always be multiple instructions. So for example approve then swap then approve

then deposit and in those you will always have like an argument uh that's that's that's done like this but then you can also in this instruction you can store the output of this instruction into transient storage and then use that transient storage as a as a as a parameter in the next uh next function call. Perfect. That makes sense. Thanks. And a follow-up question since you were mentioning transient storage. This assumes you are atomically executing all the instructions on the chain of execution, right? Yes. Single chain execution is atomic. So all the instructions on a single chain are batched into an atomic bundle. Uh but if you go across chains, then it becomes non-atomic. But we do have like a

cleanup system where you can define cleanup transactions in case any of these destination chain transactions fails. How do you handle this gracefully and and fall back? But yes, to answer your question, everything on the same chain is atomic. Perfect. Thank you. Okay, great. Thanks again for the presentation. Yeah, cheers. Thank you for having me.

Absolutely. Um sorry maybe one quick question if I can still um what like what is the like um integration mode if you wanted to support uh like a new bridge or new chain is that something that like the BCON team has to do is that something that like people can do themselves like you can do it yourself. Basically the idea is that this just orchestrates call data, right? It just does multiple function calls across multiple chains composably. As long as a bridge can be triggered by calling an onchain function like a contract function call, you can integrate it yourself. You don't need to ask us for for integration.

Cool. And what about like a new chain like I guess like right like if I want to like I don't know like launch nomchain I want to have this part experience of nonchain like um can I do that myself as well? Do I have to talk to you guys about getting like your like I assume like you will have specific relayers that you'll run to make this happen or so we don't run relayers we have a network of relayers basically it's um it's a permissionless network you can you can join it uh by like behind the pathfinder. So there's now like a lot of like network architecture that we do there with the relayers. I purposefully kind of skipped that for for brevity. Uh but yeah, in principle it's permissionless as long as you like stake tokens because one thing that I

also didn't mention, you stake tokens to guarantee livveness of execution. So there's also a slashing mechanism. If you don't execute like what you promise to execute as a relayer like you will get slashed and it's all like censorship resistant and trustless and permissionless. But essentially you stake tokens and that enables you to join the network and then you can join on another chain that that you want to join like add another chain. And as far as the contracts go, they are open- source contracts that you can permissionlessly deploy um on on any chain. So they're just like similar to account abstraction contracts. They're they're you just need to deploy them on a chain to to add support. Cool. Thank you.

And a follow up on that question. Um is that network like um spec like a private network or is it like a um is there an ERC for for that network to participate as a real? Uh anyone can join as a relayer for the network. In principle, it's um I I kind of didn't want to, you know, I promise not to not to shill like any of the token stuff and stuff, but it's in principle, you have to just stake the the BCO token and and then you can join. It's a public network. It's a permissionless network in in principle.

Like we're still working on the fully permissionless aspect to be honest. We we kind of have like 10 major node operators now who are running these nodes. But the core idea that we outline in the light paper and the white paper is that we we really want like to have hundreds of node operators supporting thousands of chains. Because the interesting thing about this super transaction if if there is like one node that can execute on one chain but you have a super transaction that touches some chain that that node cannot execute. You can split a single super transaction to be executed across multiple nodes. So this means that in a future where we might have like 100, 500, a thousand Ethereum rollups, you would be able to always find a

combination of nodes that can execute your entire path, right? So that was also one of the big design uh decisions when we were building the protocol. Okay, thank you. Okay, great. Um well let's move on and yeah if any further discussion or questions uh yeah please message me on telegram or we can continue the conversation in the telegram group as well. Cool. Uh next up we have the Kohaku wallet which I will actually start off with sharing my screen here.

Second. Okay. Hopefully you all can see my screen. Cool. Okay. Okay. Well, I just want to take a couple of minutes here to give a quick overview around Kohaku, what Kohaku is, um what our goals are, um and just share a little bit briefly around yeah why we are excited um for this work and why we think this can be something valuable in terms of yeah uh helping accelerate uh innovation and just general uh UX improvements at the wallet

layer which is a critical layer for interop I think we all agree over the next 6 to 12 months in particular. Um so yes what is Kohaku? It's a prototype developed by the EF and the Wonderland team. Uh I yeah very big shout out and thanks to the Wonderland team who's doing a lot of the heavy lifting behind the scenes for the Kohaku wallet. Um and also yes big thank you uh and big shout out to the Amire team. Kohaku is a fork of Empire and Kohaku is Japanese for Amber. So that's the name. Um goals like I mentioned I think sort of prototype emerging standards for interop and

privacy. Uh and just general acceleration of UX improvements. Uh there are many um I yeah very confident very bullish on a lot of the improvements and innovation happening at the wallet layer over the next 6 or 12 months. But I think it's something that uh that we really can't overinvest in. Again, just such a a critical area for Ethereum. So excited to have this as just another effort to be collaborating closely uh collaborating closely with uh all the existing wallet teams on this as well. Um and yeah, just to emphasize this is a uh for test net and prototype purposes only. Um really quickly, some of the main features maybe I'll just go through the V1 here. Uh the V1 is integrating interoperable addresses aka

chain specific addresses 7828 7930. Uh also integrating the open intense framework and 7683 across to support crosschain sends. Uh and then the last big piece of the v1 feature here is universal balances uh universal balance views which is displaying uh yeah aggregating same asset balances across chain. So rather than having you know seven different flavors of ETH or six different flavors of USDC to the user sort of uh yeah abstracting that away uh and showing that as a single asset to the users. Um I'll drop a link to this and and drop a link to the road map so you can sort of um we can spend more time for anyone that wants to yeah dig more into the to the road map here. Um

I'll just share this really quickly. We have some screens here showing um yeah what chain specific addresses can look like. Uh here it is uh in the send screen using something like Alice at arbitrum and the open intense framework. Um here's yeah universal balance views and yeah another example of universal balances here. Um and I think actually we have Titi here from the Wonderland team who's going to yeah maybe spend a bit more time sharing some of the details and uh yeah going into these screens a bit more. TT whenever you're ready. Great. Uh let me share my screen as well. Give me one second.

Okay. Hope you can see. Perfect. I can't see. Okay. I was going to give you some updates on the interoperable addresses standards, but let me first go through a little bit more details on the wallet itself. So um as Josh mentioned we are working on having an SDK that is protocol and well diagnostic and we are um integrating it into Kohaku that is embirious fork as he mentioned as a as a prototype but the idea is to have an amazing developer experience to make it really easy for all wallets to to adopt all these features that really uh improve the user

experience. Um as the first uh version we are supporting um the standards of interoperable addresses both the the serialization and also the resolution because for I'm going to go into more details later with the interrop addresses standard stuff but um we are moving the GitHub chain list on chain and it's part of the resolution of the address which looks something like this an interrupt address. So our SDK already supports the resolution of this um right now through the GitHub list and then it's going to be moved into an onchain resolution and it's going to be extremely smooth for wallets to just

upgrade the dependency and have that ready uh on the end for for it. Um and then the other portion that it's supporting on the first version is the crossch instance and we are able to do that through the through supporting ERC7683 thanks to all the work from OAF. Um and the balance the universal balances right now is going to be a display that is going to look something like this as sh mentioned um integrating like aggregating all the flavors when you have if you don't have to care where you have it right now it's going to show you the the aggregated balance and on the next version that we are start working on you're going to be able to use this

um as a chain agnostic asset to to do crosschain transfer swaps and everything. And again, this is something we can do thanks to the OF because they are also working on supporting multiple inputs into when you open the intent. So it would have like this sort of multiple legs to be um resolved atomically uh on the solver side. Then uh if the user want to transfer I don't know like two E to Bob uh at mainet and Alice being our user has ETH in in arbitrum on base. Um, An is going to care only about the the total balance she has of ETH and then just triggers a transaction to send to

ETH to Bob without thinking about where the the asset is on which chain like um that will be fully abstracted to the users thanks to um the OF efforts on this um and the solvers that will support this. Um and then uh this is like mainly the the main improvement we can do on um on interop and crosschain um calls but on top of that we are also integrating privacy. So privacy it's a little tricky because you need to know a lot about CK and then you care about like what if I leak information what if somehow it's able like uh trustability.

Uh so we are thinking all that as um as a system of of the UX that we need to provide for the users to have uh privacy adopted. Um I will go like really quick through this because I think we don't have much time but of course feel free to reach out to us if you have any questions, suggestions, anything. Uh we're more than open to that. Uh the idea is to have the to have privacy natively into the wallet. So you don't have to download something uh like another app or interact with a different website to get a privacy on chain. Um this will be done uh inside the wallet thanks to our SDK that right now is going to support uh privacy pools as the

privacy protocol and um and yeah we're going to focus mainly on on this amazing developer experience. So you will be able to like uh select a private mode and you will have already your balance. There are some details and stuff like for instance you would need to um so if you transfer a specific amount that would be like leaking or allowing some traceabilities then we have some formula for even amounts to be deposit. there were other like um 7702 session key stuff that would allow an automatically um top up. So another thing privacy protocols have is like you

have this window um where it's checked that you are a good actor to then get your funds mixed with others. Um so here's what you can see here on the pending side because it's like being reviewed. It's not a KYC process. is a compliance process of chain of your like the let's say like and then a chain analysis of of of your of your address and then once you're into the pool you can withdraw privately and you can mix within within the anonymity set of all the of the volume that is inside of it but okay I don't want to get too much into the details but the thing is that there are many things to be considered when you're integrating privacy into a

wallet and we want to abstract all that to the user uh for instance like creating the CK proofs and stuff like for the user I refer to the wallets um that are going to be integrating all this and then the user will have this interface where they just use their private ETH and it's sent like to Alice in a private way like Alice cannot know what's Bob assume this this is Bob what's Bob address from this okay Um so this is like a brief overview of the work we're doing for the first uh two versions for interop and privacy uh to really improve the UX and then if we do

have time a little note I wanted to do and recap on the standards we're working on. Um so we have 7930 which is the binary format and 7828 which is the human readable format of these interop addresses that mainly look like this address chain. Um there's some there have been some concerns about compatibility with cip 10 and the um we have pushed um a document that goes into this details. You can check it out the athereum/l2 interup repo. Um but the TLDDR is that it is compatible. So that's good news.

And the other thing we're going to work on is to get L2. So through this um second level domain, we are going to register the chain list data that is that currently lives inside the GitHub repo of AF. It's going to move onchain for onchain resolution of having the the chain ID that corresponds for for that chain name. Um right now we are awaiting some upgrades that are going to happen on ENS uh about a new controller and stuff and we have already proposed the temperature check on the ENS with positive signals. So once the upgrade is done we are going to create the executable proposal and get else and

after that um the the chains inside the the curing git faber are going to be moved on chain and get regist reg registered for this onchain resolution of chain IDs. Um I think I went through that pretty quickly so feel free to let me know if you have any questions and I'm going to share all the links through the chat. Thanks so much, Titi. Any questions? Cool. And yeah, get in touch anyone that wants to chat more about this or get more involved. And yeah, thanks again to the Wonderland team. Hi Josh. Am I

quickly all right to ask a question? I'm not sure if there's any process or if you just ask away. No, go. Yeah, go for it. Um yeah, thanks for this tit. Um I'm an active participant in the ENS DAO. Um so I'm aware of this proposal. I was just curious as to in an ideal world what your timelines for getting um L2 E and this proposal um pushed through would be so that I can kind of um communicate that within the DAO. Oh yeah, within two weeks for instance.

Okay. I think that that might be optimistic. Um I know that kind of there's always um a certain amount of inertia within ENS. Um and obviously with ECC coming up that might be pushy, but um yeah, everyone's kind of very compelled to to move this along. So I will um feed that back. Thank you so much. Cool. Okay. Last up on the agenda, we have base rollups and shared sequencing and how they can best fit into the accelerate interop vision. Uh we have a

few uh based experts here joining us. So um yeah, really excited to have them share their own perspectives here. Uh and I think we will have uh starting off with Drew from the fabric team uh who can maybe yeah also just give a quick refresher on um yeah what are what are base rollups and and how they how they can fit into everything here and sort of the broader vision for this. So uh yeah Drew whenever you're ready. Awesome. yeah just the classic is my screen shared on the presentation. It's perfect. Yep. We see the the full screen. Okay. Or if you want to go into slideshow view or keep it like this, but

either way. Yeah, I'll do that. It's a little tougher. That work? Yep. That's um great to meet everyone and thanks for having us on. I do relist to these. I haven't joined any in the past, but yeah. Um just a quick intro on two efforts that I'm help driving. One is called Commit Boost and one is called Fabric. Um both are supported by 501c3 or nonprofit that is focused on mostly outer protocol infrastructure supporting Ethereum. Uh commit boost is a new sidecar that allows validators to do things like issue pre-MPS and fabric is both a coordination effort but also trying to get specs uh into place that um will

support base rollups and some unification around certain parts of the stack um because it makes sense to have it. Um, so that's a bit about that and uh, yeah, we have grants from across the Ethereum community, including some folks from folks on this call. So really appreciate that. Um, yeah, so this, you know, there's some debates around uh, interop and based roll-ups. Uh, Josh had this tweet, but I think in my mind, um, I don't know if Justin's on the call, but I think when based rolls was initially proposed, you know, it was supposed to solve kind of everything. There wasn't a lot of specifics around it. And this is great for memeing but maybe causes confusion or frustration from some. And I think for us at fabric we see base ropes as a

very unique uh application to solve a certain type of interop. And uh I don't know if everyone on this call believes in synchronous composability. I think everyone here kind of likes async a bit more. But this is you know base ropes may not fit within asynchronous composibility. It may not be the best solution. I think we're fully admitting that. Um but where it does make sense is when you want L1 L2 synchronous composability and we do think that base ropes is the best solution for that and it fits well within the context of that and throughout our journey we've somewhat learned and I'll talk a bit about this of maybe some middle ground between giving up fully your sequencing rights and implications that has for an L2 versus getting like towards being halfbased or what we call this thing called signal boost which I'll get into.

But Josh asked this question on Twitter the other day. Jason, who is the technical lead for fabric, uh couldn't join cuz he had an appointment that he just absolutely couldn't move. Um and you know, this is kind of his view is um the holy grail is L1 to L2 synchronous composability. And there are multiple solutions to get there. Uh we're obviously biased, but we think that to have that holy grail, particularly with the L1, you need a shared sequencer, which there are other solutions for that. uh but you need tight coordination with the L1 proposer and then you need to reorg with the L1 and the reason for the L1 proposer as most you know is they have the monopoly over the block uh in Ethereum and so that's you know somewhat of our view base rollups happens to fit

these three requirements um and a bit of a view on uh maybe like the intentbased ecosystem this is kind of a a bit of a jab but hopefully in a friendly way versus what we get with synchronous composability um to sort of say here you know I believe in we need this intense. We need the chain to act like one chain, but it really isn't one chain. It's a bunch of things strung together. And I'm not saying base develops isn't also strung together. Uh but at least with synchronous composibility, it forces you to be one chain. Um and you know, personally just a bit skeptical of all this liquidity uh provisioning things that have to happen.

And I come from Tradfi and just would encourage people to read the front of the Wall Street Journal in 2008 2009 when liquidity did dry up. But uh I know in the near term it's a great solution and maybe in the long term we can solve some of these things so it can become more robust. Um but with synchronous composability the advantages you get is um it's just a more general purpose solution. You don't need the liquidity requirements to go across roll-ups or between the L1 and L2 um excuse me across base rollups and between the L1 and L2. And then from a developer experience you know you really just have to deploy in one place um on the L1 or on a base rollup and anyone can access that. And so it's just you streamline for those developers.

Um, this is what a base rollup is. I know I just started without explaining it. Uh, for those who don't know, uh, hopefully most people on this call do, this is Justin Drake's definition. Um, I simply just think of it as data. You have what we call classic roll-ups. They're running their centralized sequencer. Um, get rid of that centralized sequencer and replace with an Ethereum validator or proposer. And that's somewhat a rough estimate of what a base rollup is. I think the other thing to just dispel and what worked a lot to do is base rollup's narrative has been pitched as somewhat of like a ETH value acrruel or you know Ethereum an Ethereum aligned thing to do and the

only reason you do it is to become aligned. Um as I've mentioned I think it actually is a unique thing that Ethereum can provide for the end users of Ethereum. uh it you know obviously will help with value cruelty theoretically u but it's more about what Ethereum can do for you not what you can do for Ethereum um and so that's one of the things we just operate under is you know what are the unique benefits of using Ethereum as your sequencer uh and what can that provide to the end user of Ethereum itself uh which in this case are world developers so here are five different pitches of why you'd want to become based and the benefits you get from using that um I kind mentioned this first one, but as a roll-up developer or you know a rollup

that becomes based, you don't have to focus so much on uh getting USDC on your chain, getting an oracle on your on your chain like chain link on there. You get to inherit a lot of the infrastructure that's already there and the liquidity on the L1 and other base rollups. So, it's pretty creative in the sense of as more roll-ups base roll-ups launch, you get to benefit from that. um you know not specifically unique to based roll-ups. It just is a little more natural because of the way uh the technology is built. Um you you only have to develop your app in one place. You launch it and everyone can access it. Um while there are some debates around liveless and censorship because of things like gateways and pre-MPS, um there is this general consensus that

we're trying to get towards a more permissionless full pipeline. And so yeah, there are liveless and censorship resistance benefits you do get from being uh based and then mitigate regulatory risk um if you're running centralized sequencer. Obviously the feds know who you are. It's a little harder to shut something down when it's on the L1 validators. And then we have thought a lot about customization of the sequencing. We think this is an underexplored area within the context of base rollups. Uh we have some research and posts coming about this. We thought about this in the context of commit boost a lot and how uh validators can uh sell sequencing uh rules to end users uh mainly in the forum pre-MPS but there's

a whole host of other ideas people can have and roll-ups could request uh all the way from you know order my block by by tip there's a whole host of things people look at but we're we're pushing on the research side of that. So, um, and then the other thing I think we hear a lot about and one thing Josh has highlighted is, uh, but when, and, um, hopefully I've given a good pitch on why you should become based or think about it. Um, to be honest, uh, you know, there are two base rollups out there, Tao and Faucet. Um, they're not, I think both the teams would say they're not in the end state. They're still working on things. And so, this is how we view the components required for a base rollup.

And the check mark means that you know there's a spec in place or it's already implemented and it's somewhat ready to go. Um there are changes required by certain teams to get there. The gray is you know there's been some work done but uh you know probably needs a little bit more. And then if there isn't a checkbox um it's still not ready. Um and so you know we'll share these slides afterwards. I'm not going to go through each one of these but a lot of work has been done and tested um to help us get to this place. And yeah, the base rollups that are launched, they're using probably some reference implementation of these um that we've we've worked on or other teams have done. Um there's been quite a few folks that have contributed to all this. Um or they're they're taking some shortcuts. That's

maybe how they got there already live in production. Um so yeah, we'll share these slides afterwards so you can take a look and then we have a link to find out more on somewhat each of these boxes. Um the other thing we realized is there is apprehension for existing L2s to give up their sequencing rights fully to the L1 proposer and there's a lot of reasons for this and we talked with existing L2s app developers as well as institutions um just trying to get a sense on what their appetite would be for something like a base rollup and the solution it provides and um one of the things we realized is is Is there a way to get synchronous composability with the L1

without giving up your sequencer? And this is where we came up with this concept of signal boost. And essentially what it is is you still run your centralized sequencer, but when you want synchronous composability with the L1, maybe there's a certain use case for that on your rollup, you can actually request that from the L1 proposer um through this proposal. So it's more or less like instead of giving up your sequencing, right? uh you're actually closely coordinating with the L1 proposer instead of just fully giving it up and so kind of on demand you can ask for the synchronous composability with the L1 you have to pay for it uh but you can get it and this has received quite a bit of uh reception from teams and even Tao uh has reference implementation now

around this and how they're thinking about it. So with that uh here's a link to the docs uh that we have at fabric. There's you know dozens of other teams uh working on base rollups that have contributed in certain ways to this that have repos as well. So it's not just us but I'll uh hopefully I didn't take up too much time and Josh thanks for having me and for everyone listening. Thanks so much Drew. Yeah and I I want to maybe give the mic over to uh either Bret or Donno if either of you want to jump in next. But yeah, the main thing that's on my mind and we don't have to spend time on this I guess question in particular, but it's just sort of and it's probably a hard one to to spend just a few minutes on, but around timelines and the actual sort

of like making the path a bit more legible um for what this looks like to act for end for getting these benefits u of base roll-ups which I think we all agree are real. Um how do we how do we but what is the actual sort of pragmatic path to uh providing uh this value to end users and what is this something that we think uh there is a legible path to making happen in the next 6 to 12 months is do we uh or is there more consensus that this is still a little bit further out and like what are the biggest blockers what are the biggest challenges to to making this happen and I'm not saying this like I just yeah genuinely want to sort of understand like what is the path here so yeah I don't know go ahead it's a little bit unknown. I

think like the the key blockers at least from my perspective, one is real time proving and that's to get the real synchronous composability in place. Otherwise, it's a little more async. So, we all know that that's progressing, but it's still not in a place that you know we're ready yet uh for that. And the the other thing we've been really focused on is the pre-MPS. And so, when you become a base rollup today, if you don't have pre-MPS, your confirmation time is bounded by the Ethereum slot time. And you know, Ethereum may speed up its slot times, but still like a six-second slot time isn't what you get on an L2 today.

And so there is a degregation of UX. So they have this concept called pre-MPS, which is similar to what you do when you swipe your credit card at Starbucks. You swipe it, you get your coffee, your money actually doesn't move for a few days, but Visa issues Starbucks a pre-MP saying, "Hey, the money will make it, so just give them their coffee." And in this instance, it's an L1 proposer providing that pre-MP. Um, we've been working on this for a while. There are teams actually live today. I can't go into details. I'm sure they'll announce things at ECC. Um for pre-MPS actually happening in mainet um not in size, but we at least on the fabric side, they're using the specs that we all collectively outlined called the constraints API uh mainly which uh is just an extension of the current PBS pipeline. Uh there's a

couple small API changes required. Uh we're trying to get our own sort of implementation in hoodie and testing done uh probably by the end of Q3 is what we're targeting. We need to change the relay. You have to change the builder. Um you have this thing called the gateway uh as well. But there are already pre-MPs happening on mainet and I expect that to take up into year end and that's probably the other sort of big unlock not only for the the blob cost perspective. We see this in Tao. I'm not going to go into all the details but also just yeah that improved UX that we have. Um, and then yeah, I mean it depends on the rollup optimism like they have to change their inbox contract.

We've we've outlined a spec of how to do that. Uh, but will they do that TBD, but then people can take this and sort of run with it and that would obviously have to be battle tested and and things like that. So yeah, I see some potential in the next 6 to 18 months I would say uh for us to see a way more of a robust um setup. And I know I just talked a bunch. One other thing I'll say is solutions like signal boost are a great stepping stone I think for someone like Tao or a new rollup um to use that or even optimism to adjust to to have more of a based rollup experience or synchronous composability that we're shooting for.

Got it. It doesn't require all these changes. Speaking of Tao, so I see we have uh Bre here. Do do you want to maybe jump in and share any thoughts that you have here? Yeah. Yeah, I guess. Uh so I guess like the single boosting is like for existing RO talicia. So I guess yeah I think I'm not sure like what the planning there is but I guess in the next couple of months we'll be working on that and then for Gwynet um kind like the kind like well the extreme end of like synchronous composibility um hopefully we will add we'll have something uh usable at the end of this year. Uh but for that to happen there's also like some other stuff like of course like the real time proving if you don't want to just have like TE proofs and it seems like yeah

well the ZK proving each day there's like a new Zikvm that is like real time proving so that looks pretty good to be happening like in the next uh couple of months so uh and then like yeah if you actually want to build like well the uni the full like unified Ethereum experience then I guess you also kind of have to convince like L1 builders or at least like gateways to kind of build L1 blocks and L2 blocks together. Um and so I think that's kind of like also kind of one of the challenges. Uh but I hopefully that will also kind like make sense for for those people to actually do it. Uh otherwise I think yeah uh if you just like want to if you create your own base rollups then you can make whatever standards you want. So I guess not not many problems there. If you

actually want to get like other rollups involved in your kind of like interrupt system then yeah I guess there's some some uh some standardization also necessary uh for like block sharing for uh for like proof aggregation for that kind of like stuff. Uh but yeah, hopefully yeah, I guess the path is kind of clear how we can get like well horizontal scalability for like L2s where everybody every L2 block can actually sell each L1 block and we can just aggregate proofs uh for all those base rollups as well. Um I guess that's that's the goal. But I guess hopefully at least this year we'll have kind like at least like one rollup system hopefully Tao Gwinet kind of like doing this on its own and then working from there.

Thanks Brick Donno. anything you want to add from the LTD side? Uh yeah so I don't think it makes sense for me to to repeat what uh Drew and Brex were were saying like I think we all agree on the on the benefits of B sequencer in terms of um you know credibly neutral share sequencer and um and that this is the only way to get synchronous composibility with one right so I see there are some like interesting questions in the chat so I want to provide a little bit of the other side um of the story So to me it's very surprising uh that there is no project live today that I know of that is that has a shared

sequencer. Um like there are a lot of projects with uh centralized sequencers and for them it would be very very easy to to do a share sequencer. Um one obvious example is um roll up as a service providers like conduit. um they service like 25 plus chains and for them it would be very easy to to just have a share sequencer between all of them but as far as I know none of them is working on it right so and like if you if you really think about it um or like me personally I cannot think of um very significant use cases um that uh emerge just out of

synchronicity Uh I feel like the most important property that you need is automity um as well and there are we know of you know big projects working on on providing automity uh before uh real improving uh or before you know faster than L1. So uh there are examples like the super chain, there is the layer, there is the elastic chain that they're building these very big uh difficult uh infrastructures um very complicated infrastructures to to provide autonomicity and what I what I wanted to say is that I want to invite um projects working on base sequencing to to look into into the

layer you know the the super chain and elastic chain specifically as a uh automicity providers. And there are some nuances in these solutions. Uh not all of them work in the same way. For example, the super chain allows to uh send messages uh well before proofs are generated. So it's very easy to do synchronous composibility between chains in the super chain. The problem is that uh all the chains in the superchain needs to be standard. The good news is that everyone can deploy their own custom cluster if they want to outside of the like official superchain one. Uh maybe someone can work on uh trying to to build a base roll up of the stack

cluster that is atomic. Um I know that the elastic chain will provide interropy um at the time the proof are generated but they have super fast prover so maybe that's um good enough and the layer I I I don't remember um but uh the the other cool thing that these projects provide is a shared bridge right so there have been a lot of discussion regarding shared bridges why we need shared bridges uh you don't want to uh move assets on one because it's expensive. So all these projects already provide short bridges for the layer and the elastic chain. They're already live.

The super chain will have one during the next April I think at the end of July also um like another another block that I see another block. Um, another block that I see is of course that uh base rollups are forced to uh publish transactions very often and is expensive. Uh, we've seen projects like we're trying to monitoring the livveness of these projects and we've seen uh some of them publishing transaction less often because transaction fees are super competitive between the altos and base rollup are

it's very difficult for base rollup to be competitive. So one thing that would help for sure is um if L1 was cheaper. So I also kind of invite people to to push for scaling L1 where possible. Um I think it's more beneficial to to scale it one for example than having six second as lot times because projects today you know they want to publish transactions um not very often because again it's super expensive and transaction fees are are very competitive and yeah that's all from oh yeah sorry another thing is you know all these projects are not credibly neutral of course like the super chain and elastic chain unfortunately I think it's impossible to build one that is credibly

neutral All of them will have some sort of governance. So until we have poop in a pink unfortunately, thanks Donna. Uh Victor, yeah my question basically is around the interplay between realtime proving and you know based rollups and uh you know a synchronous composability like this. So basically we have you know kind of surprisingly enough we have you know multiple ZKVMs now that can you know within the next like right now do real-time proving you know most of the time and then within a few months probably we'll be able to do it you know 99% of the time or more but kind we still have cases where we're going to

have proofs not get generated in time um for any variety of reasons you know just simple reliability reasons for instance um and basically I don't it's it's not clear to me what the like what how base roll up or also other solutions that that rely on real time proving react when a proof is not available on time. Um I mean I have thoughts I could jump in here. So if generally the way that real-time proving um is used in synchronous composability like in the way that for example that uh ag layer um intends to use it is that uh you build the block. So like you build first the

first part of block A, you generate a proof and then you actually pass this proof into block B. So if you didn't generate the proof in time, uh then presumably the proposer just like would act like they didn't build the block in time and that block would be skipped. I mean there's probably some other ways you could handle it, but that's how I generally see it happening. Yeah, that that's kind of my understanding as well. It's got to phase a little bit um unfortunate that that that kind of is the reaction especially because if you want shorter block times for example you know going from 12 seconds to 6 seconds to 2 seconds to you know even shorter levels of like um latency in terms of the interaction

times. You definitely have the case. You definitely have the have it become the case that you know two second real time proving is not really gonna like you know maybe we can do it but maybe but like at that point you know you're even like having achieving greater than 99% liability is going to be pretty hard. Yeah. I mean I will say technically um an alternate an alternative to requiring real-time proving is if the rollups have shared settlement so like they share the same settlement contract you can still enforce admissity that way um and you don't need real-time proving for it but uh that's just a really big ask for a lot of rollups to share a settlement contract um but I mean with things like ag layer for example that is essentially what they're doing um in a little bit of

a different way like a layer doesn't necessarily guarantee atomicity in their current design. Um, I don't know, just pointing it out for like technical correctness. Uh, we tech you don't technically need shared or real-time proofs if you have shared settlement. I appreciate that. Thank you. I maybe have like a quick question. um about based rollups. So um yes, it's like known that based roll-ups can be expensive because they have to post to

Ethereum very often. Um but like where are we I guess with like the rollup pre-confirmations where you the idea where you would have like a preconfir um for a based rollup uh that would essentially pre-confirm transactions for like five minutes and then they would submit those to the L1. Um I think that that was that used to be the design but I'm not sure where the status of that is. Yeah, Amad maybe you know. Yeah. So on the L2 preconfirmations we uh already it's live on Tao Heekla which is the uh the test net of Tao. Um we have uh three participants that uh that are uh that have developed L2 pre-MPS

site cars. uh nethermind chain bound and gara uh all three participants are uh pre-confing right now uh every two seconds uh for for for tao hicklan only posting once a batch is ready to post. So uh basically this increases like improves the UX for the user significantly uh where they can get like fast confirmations on their um on their transactions and at the same time reduces the cost because you can only submit like a a batch every couple of uh slots instead of having to submit a batch uh um or a block every uh every L1 slot or every two slots or whatever the

time. Uh, of course there are limitations to what can be aggregated because for example uh currently uh we are we have imple like the implementation for precoms is a whit listed uh pre-comers so that the the pre-comers are basically whitelisted agents um addresses and uh later on we're working on on uh making this permissionless list so actually the L1 validators can opt in to become pre-comers based on their slots and based on being able to force include um the the the the pre-confed batches. Um and this is uh this is uh this is coming like um uh like I think uh whitelisted

pre uh uh coming to Taiko mainet should be in like two or 3 months. Uh and uh the full uh permissionless solution should come to mainet um in Q1 Q2 of the next year. um hopefully sooner but uh I don't want to be too optimistic. Um yeah but uh solution has solutions are are there and things are looking better for base rollups in term of cost um and optimizing cost for for for posting.

Yeah. And also like looking at um a lot of the grievances that rollups have right now like for example the price of posting blobs or uh the the the cost of uh um ZK proofs for example. Um these all of these uh are being scaled up and sped up uh by the advancement of technology. You see the advancement of ZK proofs happening in in Twitter and all the news about all the speedups that success that ZISK that uh risk zero and other teams are working on OpenVM etc. I I can't mention them all but a lot of teams are working on these reducing the cost for posting uh ZK proofs uh and additionally the L1 uh core devs are

persistent on scaling up the blobs so that uh enough capacity is there for rollups actually in my opinion right now like if we go with the Fusaka pure das and the numbers that we're looking into I think there will be ample amount of blobs uh especially with the compression and aggregation that we have and blob sharing uh research that uh have been done uh there will be ample amount of blob space uh for for rollups to use on on del. So blobs costs of blobs on delus uh uh zk uh posting on del should be significantly lower um in the coming uh couple of uh months or or uh quarters.

Awesome. Thanks so much. Cool. Well, we are at time. Thanks all for the yeah good conversation on based and shared sequencing and we can uh yeah maybe continue the conversation in the telegram group. Cool. Thanks all for joining. See you next time.